diff options
Diffstat (limited to 'docs/ecosystem/architecture/index.rst')
| -rw-r--r-- | docs/ecosystem/architecture/index.rst | 1180 |
1 files changed, 1180 insertions, 0 deletions
diff --git a/docs/ecosystem/architecture/index.rst b/docs/ecosystem/architecture/index.rst new file mode 100644 index 000000000..f9439dee6 --- /dev/null +++ b/docs/ecosystem/architecture/index.rst @@ -0,0 +1,1180 @@ +.. This work is licensed under a Creative Commons Attribution +.. 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017-2018 Huawei Technologies Co., Ltd. +.. Copyright 2019 ONAP Contributors +.. Copyright 2020 ONAP Contributors +.. Copyright 2021 ONAP Contributors +.. Copyright 2022 ONAP Contributors +.. Copyright 2023 ONAP Contributors +.. Copyright 2024 ONAP Contributors + +.. _ONAP-architecture: + +Architecture +============ +ONAP is no longer a platform, rather it provides various network automation +functions, and security reference configuration in LFN. + +ONAP provides network automation functions for orchestration, management, and +automation of network and edge computing services for network operators, cloud +providers, and enterprises. Real-time, policy-driven orchestration and +automation of physical, virtual, and cloud native network functions enables +rapid automation of new services and complete lifecycle management critical for +5G and next-generation networks, with Intent-based automation and genAI/ML. + +The ONAP project addresses the need for automation functions for +telecommunication, cable, and cloud service providers—and their solution +providers—to deliver differentiated network services on demand, profitably and +competitively, while leveraging existing investments. + +The challenge that ONAP meets is to help network operators keep up with the +scale and cost of manual changes required to implement new service offerings, +from installing new data center equipment to, in some cases, upgrading +on-premises customer equipment. Many are seeking to exploit SDN and NFV to +improve service velocity, simplify equipment interoperability and integration, +and to reduce overall CapEx and OpEx costs. In addition, the current, highly +fragmented management landscape makes it difficult to monitor and guarantee +service-level agreements (SLAs). + +ONAP is addressing these challenges by developing global and massive scale +(multi-site and multi-VIM) automation capabilities for physical, virtual, and +cloud native network elements. It facilitates service agility by supporting +data models for rapid service and resource deployment and providing a common +set of northbound REST APIs that are open and interoperable, and by supporting +model-driven interfaces to the networks. ONAP’s modular and layered nature +improves interoperability and simplifies integration, allowing it to support +1) multiple VNF environments by integrating with multiple VIMs, VNFMs, SDN +Controllers, as well as legacy equipment (PNF) and 2) Cloud Native environments +by integrating Kubernetes, CNFMs and other controllers. The Service Design & +Creation (SDC) project also offers seamless orchestration of CNFs. ONAP’s +consolidated xNF requirements publication enables commercial development of +ONAP-compliant xNFs. This approach allows network and cloud operators to +optimize their physical, virtual and cloud native infrastructure for cost and +performance; at the same time, ONAP’s use of standard models reduces +integration and deployment costs of heterogeneous equipment. All this is +achieved while minimizing management fragmentation. + +The ONAP allows end-user organizations and their network/cloud providers to +collaboratively instantiate network elements and services in a rapid and +dynamic way, together with supporting a closed control loop process that +supports real-time response to actionable events. In order to design, engineer, +plan, bill and assure these dynamic services, there are three major +requirements: + +- A robust design framework that allows the specification of the service in all + aspects – modeling the resources and relationships that make up the service, + specifying the policy rules that guide the service behavior, specifying the + applications, analytics and closed control loop events needed for the elastic + management of the service +- An orchestration and control framework (Service Orchestrator and Controllers) + that is recipe/ policy-driven to provide an automated instantiation of the + service when needed and managing service demands in an elastic manner +- An analytic framework that closely monitors the service behavior during the + service lifecycle based on the specified design, analytics and policies to + enable response as required from the control framework, to deal with + situations ranging from those that require healing to those that require + scaling of the resources to elastically adjust to demand variations. + +To achieve this, ONAP decouples the details of specific services and supporting +technologies from the common information models, core orchestration components, +and generic management engines (for discovery, provisioning, assurance etc.). + +Furthermore, it marries the speed and style of a DevOps/NetOps approach with +the formal models and processes operators require to introduce new services and +technologies. It leverages cloud-native technologies including Kubernetes to +manage and rapidly deploy the ONAP and related components. This is in +stark contrast to traditional OSS/Management software architectures, +which hardcoded services and technologies, and required lengthy software +development and integration cycles to incorporate changes. + +The ONAP enables service/resource independent capabilities for design, +creation and lifecycle management, in accordance with the following +foundational principles: + +- Ability to dynamically introduce full service lifecycle orchestration + (design, provisioning and operation) and service API for new services and + technologies without the need for new software releases or without + affecting operations for the existing services +- Scalability and distribution to support a large number of services and large + networks +- Metadata-driven and policy-driven architecture to ensure flexible and + automated ways in which capabilities are used and delivered +- The architecture shall enable sourcing best-in-class components +- Common capabilities are ‘developed’ once and ‘used’ many times +- Core capabilities shall support many diverse services and infrastructures + +Further, ONAP comes with a functional architecture with component definitions +and interfaces, which provides a force of industry alignment in addition to +the open source code. + +Architecture Overview +--------------------- + +The ONAP architecture consists of a design time and run time functions, as well +as functions for managing ONAP itself. + + Note: Use the interactive features of the below ONAP Architecture Overview. + Click to enlarge it. Then hover with your mouse over an element in the + figure for a short description. Click the element to get forwarded to a more + detailed description. + +.. image:: media/onap-architecture-overview-interactive-path.svg + :width: 800 + +**Figure 1: Interactive high-level view of the ONAP architecture with its +microservices-based components. Click to enlarge and discover.** + +The figure below provides a simplified functional view of the architecture, +which highlights the role of a few key components: + +#. ONAP Design time environment provides onboarding services and resources + into ONAP and designing required services. +#. External API provides northbound interoperability for the ONAP. +#. ONAP Runtime environment provides a model- and policy-driven orchestration + and control framework for an automated instantiation and configuration of + services and resources. Multi-VIM/Cloud provides cloud interoperability for + the ONAP workloads. Analytic framework that closely monitors the service + behavior handles closed control loop management for handling healing, + scaling and update dynamically. +#. OOM provides the ability to manage cloud-native installation and deployments + to Kubernetes-managed cloud environments. +#. ONAP Shared Services provides shared capabilities for ONAP modules. The ONAP + Optimization Framework (OOF) provides a declarative, policy-driven approach + for creating and running optimization applications like Homing/Placement, + and Change Management Scheduling Optimization. The Security Framework uses + open-source security patterns and tools, such as Istio, Ingress Gateway, + oauth2-proxy, and Keycloak. This Security Framework makes ONAP secure + external and inter-component communications, authentication and + authorization. + Logging Framework (reference implementation PoC) supports open-source- and + standard-based logging. It separates application log generation from log + collection/aggregation/persistence/visualization/analysis; i.e., ONAP + applications handle log generation only and the Logging Framework stack will + handle the rest. As a result, operators can leverage/extend their own + logging stacks. +#. ONAP shared utilities provide utilities for the support of the ONAP + components. + +Microservice BUS (MSB) is obsolete from Montreal release. Its function has +been replaced by Istio Service Mesh, Ingress and IdAM (Keycloak) for secure +internal and external communications and security authentication and +authorization. + +Information Model and framework utilities continue to evolve to harmonize +the topology, workflow, and policy models from a number of SDOs including +ETSI NFV MANO, ETSI/3GPP, O-RAN, TM Forum SID, ONF Core, OASIS TOSCA, IETF, +and MEF. + +|image2| + +**Figure 2. Functional view of the ONAP architecture** + +Introduction of ONAP Streamlining evolution +------------------------------------------- +Rationale +^^^^^^^^^ +Previously, ONAP as a platform had shown e2e network automation to the +industry. Operators, vendors and enterprises have learned how service/network +automation (modeling, orchestration, policy-based closed loop, optimization, +etc.) works on VM and Cloud-native environments for VNF, PNF, CNF, NS, +Network/RAN slicing and e2e service thru ONAP. +In ONAP, there are numerous valuable use cases, that leverage and coordinate +clusters of ONAP component functions (e.g., SDC, SO, A&AI, DCAE, SDNC, SDNR, +CPS, CDS...) to achieve objectives, such as: + +- E2E Service +- Network Slicing +- RAN Slicing +- Closed Loop +- ETSI-based NS & VNF orchestration +- Helm-based CNF orchestration +- ASD-based (including Helm) CNF orchestration + +Now, the operators, vendors and enterprises want to select and apply ONAP +functions to their portfolio. No one needs to take ONAP as a whole. + +Goal +^^^^ +The goal is to continue to support the current ONAP use cases efficiently for +use in commercial production environments and portfolio. We expect the industry +wants to pick and choose desired ONAP component functions, swap some of the +ONAP functions, and integrate those functions into their portfolio seamlessly, +without bringing in a whole ONAP platform. +ONAP Streamlining, which drives individual components and clusters of +components guided by use cases, will enable the flexible and dynamic function +adoption by the industry + +ONAP Streamlining Transformation +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Thru ONAP Streamlining, ONAP is no longer a platform, rather it provides +various network automation functions, and security reference configuration in +LFN. ONAP enables individual ONAP function build, and component deployment +thru CD. It will build use cases for repository-based E2E service, NS, CNF and +CNA onboarding, and CD-based ONAP component triggering mechanism with +abstracted interfaces for choreography. It will boost standard-based abstracted +interfaces with declarative APIs, i.e., each component will be autonomous and +invoked from any level of network automation, by leveraging CD mechanisms, such +as GitOps and CD readiness. + +ONAP will become more intent-based and declarative, and bring in genAI/ML, +conforming to standards such as 3GPP, TMForum, ETSI, IETF, O-RAN, etc. For +example, UUI user intent support and AI-based natural language translation, on +top of that, applying coming 3GPP and TMForum models and APIs. Also, it will +delegate resource-level orchestration to functions from the external community, +such as O-RAN SC and Nephio. + +For security, ONAP continues to support the Service Mesh, Ingress, OAuth2, +IdAM-based authentication and authorization, and considers sidecar-less +solutions for NF security. + +|image3| + +**Figure 3. ONAP Streamlining evolution** + +ONAP Component Design Requirements +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +- ONAP components should be designed not only for ONAP but also non-ONAP + consumption. +- ONAP component dependencies and couplings to other ONAP components should + not be in an ONAP-specific way. +- Making each ONAP component should be 'stand-alone', so potential users can + take a single component, without getting involved in the whole of ONAP. +- ONAP component interactions should be based on standards and extensible to + facilitate integration with other systems, especially for non-ONAP. +- ONAP component Helm charts in OOM should be re-written to build/deploy a + component individually. +- ONAP Security mechanisms should be industry standard/de facto-based to + integrate with vendor/operator security and logging. +- Timelines and cadence of the ONAP release should be flexible for + accommodating different release strategies. + +ONAP Component Design, Build & Deployment +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +ONAP components are independently deployable pieces of software, built out of +one more microservices: +- Modular +- Autonomous +- Extensible and substitutional + +ONAP Network Automation processes will manage more intent-based operations +using AI/ML. +- Manage use and other intents and translations +- Study on TMForum and 3GPP intent models and APIs + +ONAP components conform to the standards and de facto specifications to enable +plug- and-play and pick-and-choose facilitation. + +ONAP repository-based SW management enables smaller imperative actions that +can be triggered by different events in the orchestration and SW LCM flow. +Events can trigger different types of deployment automation jobs or chains of +automation jobs (pipelines). + +In Jenkins ONAP OOM build scripts will be used for ONAP component builds and +will store built ONAP components into the Artifact Repository (e.g., Nexus). +This can be changed. CD (e.g., ArgoCD, Flux, others) will be used to +pick-and-choose ONAP components. + +|image4| + +**Figure 4. ONAP Streamlining Component Build and Deployment** + +For more details of ONAP streamlining, see the ONAP Streamlining - The Process +page, https://wiki.onap.org/display/DW/ONAP+Streamlining+-+The+Process + +Microservices Support +--------------------- +As a cloud-native application that consists of numerous services, ONAP requires +sophisticated initial deployment as well as post- deployment management. + +ONAP is no longer a platform, rather it provides network automation functions, +and security reference configuration in LFN. + +Thru ONAP Streamlining evolution, the ONAP deployment methodology has been +enhanced, allowing individual ONAP components can be picked up through a chosen +CD (Continuous Deployment) tool. This enhancement should be flexible enough to +suit the different scenarios and purposes for various operator environments. +Users may also want to select a portion of the ONAP components to integrate +into their own systems. For more details of ONAP Streamlining evolution, see +the ONAP Streamlining evolution session. + +The provided ONAP functions are highly reliable, scalable, extensible, secure +and easy to manage. To achieve all these goals, ONAP is designed as a +microservices-based system, with all components released as Docker containers +following best practice building rules to optimize their image size. Numerous +optimizations such as shared databases and the use of standardized lightweight +container operating systems reduce the overall ONAP footprint. + +In the spirit of leveraging the microservice capabilities, further steps +towards increased modularity have been taken. Service Orchestrator (SO) and the +controllers have increased its level of modularity, by following Microservices. + +ONAP Operations Manager (OOM) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The ONAP Operations Manager (OOM) is responsible for orchestrating the +end-to-end lifecycle management and monitoring of ONAP components. OOM uses +Kubernetes with IPv4 and IPv6 support to provide CPU efficiency and ONAP +component deployment. In addition, OOM helps enhance ONAP maturity by providing +scalability and resiliency enhancements to the components it manages. + +OOM is the lifecycle manager of the ONAP and uses the Kubernetes +container management system and Consul to provide the following functionality: + +#. Deployment - with built-in component dependency management (including + multiple clusters, federated deployments across sites, and anti-affinity + rules) +#. Configuration - unified configuration across all ONAP components +#. Monitoring - real-time health monitoring feeding to a Consul GUI and + Kubernetes +#. Restart - failed ONAP components are restarted automatically +#. Clustering and Scaling - cluster ONAP services to enable seamless scaling +#. Upgrade - change out containers or configuration with little or no service + impact +#. Deletion - clean up individual containers or entire deployments + +OOM supports a wide variety of cloud infrastructures to suit your individual +requirements. + +OOM provides Service Mesh-based mTLS (mutual TLS) between ONAP components to +secure component communications, by leveraging Istio. + +In addition to Service Mesh-based mTLS, OOM also provides inter-component +authentication and authorization, by leveraging Istio Authorizaiton Policy. +For external secure communication, authentication (including SSO) and +authorization, OOM configures Ingress, oauth2-proxy, IAM (realized by +KeyCloak) and IdP. + +As the result, Unmaintained AAF functionalities are obsolete and substituted +by Istio-based Service Mesh and Ingress, as of Montreal release. + +|image5| + +**Figure 5. Security Framework component architecture** + +For OOM enhancements for ONAP Streamlining evolution, see the ONAP Streamlining +evolution section. + +Microservices Bus (MSB) +^^^^^^^^^^^^^^^^^^^^^^^ + +.. warning:: The ONAP :strong:`MSB` project is :strong:`deprecated`. + As of Release 13 'Montreal' the component is no longer part of the + ONAP deployment. + +Microservices Bus (MSB) used to support service registration/ discovery, +external API gateway, internal API gateway, client software development +kit (SDK), and Swagger SDK. When integrating with OOM, MSB used to have +a Kube2MSB registrar which can grasp services information from k8s metafile +and automatically register the services for ONAP components. + +In London release, ONAP Security Framework components provide secure +communication capabilities. This approach is a more Kubernetes-native approach. +As a result, MSB functions has been replaced by the Security Framework, and MSB +becomes an optional component. + +Portal-NG +--------- +ONAP had a portal project but this project was terminated and archived. +Portal-NG is a new component and fills the gap. It provides a state of the art +web-based GUI that services as the first discovery point for the ONAP, its +existing web applications and functions. +Onboard users with an adaptive GUI following a "grow as you go" approach +covering "playful discovery" up to expert mode. Wherever possible hide +complexity of network automation by guiding the user. +The Portal-NG supports new ONAP Security framework for user administration, +authentication and authorization. For more details, see the Portal-NG section. + +Design Time Components +---------------------- +The design time components are a comprehensive development environment with +tools, techniques, and repositories for defining/ describing resources, +services, and products. + +The design time components facilitate reuse of models, further improving +efficiency as more and more models become available. Resources, services, +products, and their management and control functions can all be modeled using a +common set of specifications and policies (e.g., rule sets) for controlling +behavior and process execution. Process specifications automatically sequence +instantiation, delivery and lifecycle management for resources, services, +products and the ONAP components themselves. Certain process specifications +(i.e., ‘recipes’) and policies are geographically distributed to optimize +performance and maximize autonomous behavior in federated cloud environments. + +Service Design and Creation (SDC) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Service Design and Creation (SDC) provides tools, techniques, and repositories +to define/simulate/certify system assets as well as their associated processes +and policies. Each asset is categorized into one of four asset groups: Resource +, Services, Products, or Offers. SDC supports the onboarding of Network +Services packages (ETSI SOL007 with ETSI SOL001), ONAP proprietary CNF packages +(embedding Helm Chart), ASD-based CNF packages (ETSI SOL004 and embedding Helm +Chart), VNF packages (Heat or ETSI SOL004) and PNF packages (ETSI SOL004). SDC +also includes some capabilities to model 5G network slicing using the standard +properties (Slice Profile, Service Template). + +Since Kohn-R11 release, SDC supports the onboarding of another CNF-Modeling +package, Application Service Description (ASD) package. ASD is a deployment +descriptor for cloud native applications/functions. It minimizes information +needed for the CNF orchestrator, by referencing most resource descriptions to +the cloud native artifacts (e.g., Helm Chart). Its CSAR package adheres to +ETSI SOL004. + +The SDC environment supports diverse users via common services and utilities. +Using the design studio, product and service designers onboard/extend/retire +resources, services and products. Operations, Engineers, Customer Experience +Managers, and Security Experts create workflows, policies and methods to +implement Closed Control Loop Automation/Control and manage elastic +scalability. + +Vendors can integrate these tools in their CI/CD environments to package VNFs +and upload them to the validation engine. Once tested, the VNFs can be onboarded +through SDC. ONAP supports onboarding of CNFs and PNFs as well. + +The Policy Creation component deals with policies; these are rules, conditions, +requirements, constraints, attributes, or needs that must be provided, +maintained, and/or enforced. At a lower level, Policy involves machine-readable +rules enabling actions to be taken based on triggers or requests. Policies +often consider specific conditions in effect (both in terms of triggering +specific policies when conditions are met, and in selecting specific outcomes +of the evaluated policies appropriate to the conditions). + +Policy allows rapid modification through easily updating rules, thus updating +technical behaviors of components in which those policies are used, without +requiring rewrites of their software code. Policy permits simpler +management / control of complex mechanisms via abstraction. + +VNF SDK +^^^^^^^ + +.. warning:: The ONAP :strong: 'VNF SDK' project is :strong:'deprecated'. + +VNF SDK provides the functionality to create VNF/PNF packages, test VNF +packages and VNF ONAP compliance and store VNF/PNF packages and upload to/from +a marketplace. + +VVP +^^^ + +.. warning:: The ONAP :strong: 'VVP' project is :strong:'deprecated'. + +VVP provides validation for the VNF Heat package. + +Runtime Components +------------------ +The runtime execution components execute the rules and policies and other +models distributed by the design and creation environment. + +This allows for the distribution of models and policy among various ONAP +modules such as the Service Orchestrator (SO), Controllers, Data Collection, +Analytics and Events (DCAE), Active and Available Inventory (A&AI). These +components use common services that support security (access control, +secure communication), logging and configuration data. + +Orchestration +^^^^^^^^^^^^^ +The Service Orchestrator (SO) component executes the specified processes by +automating sequences of activities, tasks, rules and policies needed for +on-demand creation, modification or removal of network, application or +infrastructure services and resources, this includes VNFs, CNFs and PNFs, +by conforming to industry standards such as ETSI, TMF, 3GPP. +The SO provides orchestration at a very high level, with an end-to-end view +of the infrastructure, network, and applications. Examples of this include +BroadBand Service (BBS) and Cross Domain and Cross Layer VPN (CCVPN). +The SO is modular and hierarchical to handle services and multi-level +resources and Network Slicing, by leveraging pluggable adapters and delegating +orchestration operations to NFVO (SO NFVO, VFC), VNFM, CNF Manager, NSMF +(Network Slice Management Function), NSSMF (Network Slice Subnet Management +Function). + +Starting from the Guilin release, the SO provides CNF orchestration support +through integration of CNF adapter and other CNF managers in ONAP. SO: + +- Support for provisioning CNFs using an external K8S Manager +- Support the Helm-based orchestration +- Leverage the CNF Adapter to interact with the K8S Plugin in MultiCloud, or + leverage the CNF Manager to interact with the K8S to control CNFs (e.g., ASD) +- Bring in the advantage of the K8S orchestrator and +- Set stage for the Cloud Native scenarios + +In London, ONAP SO added ASD-based CNF orchestration support to simplify +CNF orchestration and to remove redundancies of CNF resource attributes and +orchestration process. + +- Support for onboarding of ASD-based CNF models and packages in runtime +- Support the SO sub-component 'SO CNFM' for ASD-dedicated CNF orchestration + to isolate ASD management from other SO components - separation of concerns +- Use of ASD for AS LCM, and use of associated Helm Charts for CNF deployment + to the selected external K8s Clusters +- Use of Helm Client to communicate with external K8S clusters for CNF + deployment +- Monitoring deployed K8S resources thru Kubernetes APIs + +3GPP (TS 28.801) defines three layer slice management function which include: + +- CSMF (Communication Service Management Function) +- NSMF (Network Slice Management Function) +- NSSMF (Network Slice Subnet Management Function) + +To realize the three layers, CSMF, NSMF and/or NSSMF are realized within ONAP, +or use the external CSMF, NSMF or NSSMF. For ONAP-based network slice +management, different choices can be made as follows. Among them, ONAP +orchestration currently supports options #1 and #4. + +|image6| + +**Figure 6: ONAP Network Slicing Support Options** + + +Virtual Infrastructure Deployment (VID) - obsolete +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. warning:: The ONAP :strong:`vid` project is :strong:`deprecated`. + As of Release 12 'London' the component is no longer part of the + ONAP deployment. + +The Virtual Infrastructure Deployment (VID) application enables users to +instantiate infrastructure services from SDC, along with their associated +components, and to execute change management operations such as scaling and +software upgrades to existing VNF instances. + +Policy-Driven Workload Optimization +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. warning:: The ONAP :strong:'OOF' project is :strong:'deprecated'. + +The ONAP Optimization Framework (OOF) provides a policy-driven and model-driven +framework for creating optimization applications for a broad range of use +cases. OOF Homing and Allocation Service (HAS) is a policy driven workload +optimization service that enables optimized placement of services across +multiple sites and multiple clouds, based on a wide variety of policy +constraints including capacity, location, other service capabilities and +constraints. + +ONAP Multi-VIM/Cloud (MC) and several other ONAP components such as Policy, SO, +A&AI etc. play an important role in enabling “Policy-driven Performance/ +Security-Aware Adaptive Workload Placement/ Scheduling” across cloud sites +through OOF-HAS. OOF-HAS uses cloud agnostic Intent capabilities, and real-time +capacity checks provided by ONAP MC to determine the optimal VIM/Cloud +instances, which can deliver the required performance SLAs, for workload +(VNF, etc.) placement and scheduling (Homing). Operators now realize the true +value of virtualization through fine grained optimization of cloud resources +while delivering performance and security SLAs. + +Controllers +^^^^^^^^^^^ +Controllers are applications which are coupled with cloud and network services +and execute the configuration, real-time policies, and control the state of +distributed components and services. Rather than using a single monolithic +control layer, operators may choose to use multiple distinct controller types +that manage resources in the execution environment corresponding to their +assigned controlled domain such as cloud computing resources (SDN-C). +The Virtual Function Controller (VF-C) and SO NFVO provide an ETSI NFV +compliant NFVO function that is responsible for lifecycle management of +virtual services and the associated physical COTS server infrastructure. VF-C +provides a generic VNFM capability, and both VF-C and SO NFVO integrate with +external VNFMs and VIMs as part of an NFV MANO stack. + +.. warning:: The ONAP :strong:`appc` project is :strong:`deprecated`. + As of Release 12 'London' the component is no longer part of the + ONAP deployment. +.. warning:: The ONAP :strong:'VF-C' project is :strong:'deprecated'. + +ONAP used to have two application level configuration and lifecycle management +modules called SDN-C and App-C. App-C is no longer part of ONAP deployment. +SDN-C provides controller services (application level configuration using +NetConf, Chef, Ansible, RestConf, etc.) and lifecycle management functions +(e.g., stop, resume, health check, etc.). +SDN-C uses common code from CCSDK repo, and it uses CDS only for onboarding and +configuration / LCM flow design. +SDN-C has been used for Layer1-7 network elements. ONAP Controller configures +and maintains the health of L1-7 Network Function (VNF, PNF, CNF) and network +services throughout their lifecycle: + +- Configures Network Functions (VNF/PNF) +- Provides programmable network application management: + + - Behavior patterns programmed via models and policies + - Standards based models & protocols for multi-vendor implementation + - Extensible SB adapters such as Netconf, Ansible, Rest API, etc. + - Operation control, version management, software updates, etc. +- Local source of truth + - Manages inventory within its scope + - Manages and stores state of NFs + - Supports Configuration Audits + +Controller Design Studio (CDS) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The Controller Design Studio (CDS) community in ONAP has contributed a +framework to automate the resolution of resources for instantiation and any +config provisioning operation, such as day0, day1 or day2 configuration. The +essential function of CDS is to create and populate a controller blueprint, +create a configuration file from this Controller blueprint, and associate at +design time this configuration file (configlet) to a PNF/VNF/CNF during the +design phase. CDS removes dependence on code releases and the delays they cause +and puts the control of services into the hands of the service providers. Users +can change a model and its parameters with great flexibility to fetch data from +external systems (e.g., IPAM) that is required in real deployments. This makes +service providers more responsive to their customers and able to deliver +products that more closely match the needs of those customers. + +Inventory +^^^^^^^^^ +Active and Available Inventory (A&AI) provides real-time views of a system’s +resources, services, products and their relationships with each other, and also +retains a historical view. The views provided by A&AI relate data managed by +multiple ONAP instances, Business Support Systems (BSS), Operation Support +Systems (OSS), and network applications to form a “top to bottom” view ranging +from the products end users buy, to the resources that form the raw material +for creating the products. A&AI not only forms a registry of products, +services, and resources, it also maintains up-to-date views of the +relationships between these inventory items. + +To deliver the promised dynamism of SDN/NFV, A&AI is updated in real time by +the controllers as they make changes in the network environment. A&AI is +metadata-driven, allowing new inventory types to be added dynamically and +quickly via SDC catalog definitions, eliminating the need for lengthy +development cycles. + +Multi Cloud Adaptation +^^^^^^^^^^^^^^^^^^^^^^ +Multi-VIM/Cloud provides and infrastructure adaptation layer for VIMs/Clouds +and K8s clusters in exposing advanced cloud agnostic intent capabilities, +besides standard capabilities, which are used by OOF and other components +for enhanced cloud selection and SO/VF-C for cloud agnostic workload +deployment. The K8s plugin is in charge of deploying CNFs on the Kubernetes +clusters using Kubernetes APIs. + +Data Collection Analytics and Events (DCAE) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +DCAE provides the capability to collect events, and host analytics applications +(DCAE Services). It gathers performance, usage, and configuration data from +the managed environment. Data is fed to various analytic applications, and if +anomalies or significant events are detected, the results trigger appropriate +actions, such as publishing to other ONAP components such as Policy, SO, or +Controllers. + +- Collect, ingest, transform and store data as necessary for analysis +- Provide a framework for development of analytics + +Policy Framework +^^^^^^^^^^^^^^^^ +The Policy framework is a comprehensive policy design, deployment, +and execution environment. The Policy Framework is the decision making +comopnent in an ONAP system. It allows to specify, deploy, and execute +the governance of the features and functions in ONAP system, support +the closed loop, orchestration, or more traditional open loop use case +implementations. + +Since the Istanbul release, the CLAMP is officially integrated into the +Policy component. CLAMP's functional role to provision Policy has been +enhanced to support provisioning of policies outside of the context of +a Control Loop and therefore act as a Policy UI. For CLAMP details, see +the Policy - CLAMP section. + +It supports multiple policy engines and can distribute policies through policy +design capabilities in SDC, simplifying the design process. + +Closed Control Loop Automation Management Platform in Policy (Policy - CLAMP) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. warning:: The ONAP :strong:`CLAMP` function is now part of :strong:`Policy`. + +Closed loop control is provided by cooperation among a number of design-time +and run-time elements. The Runtime loop starts with data collectors from Data +Collection, Analytics and Events (DCAE). ONAP includes the following collectors +: VES (VNF Event Streaming) for events, HV-VES for high-volume events, SNMP +for SNMP traps, File Collector to receive files, and RESTCONF Collector to +collect the notifications. After data collection/verification phase, data move +through the loop of micro-services like Homes for event detection, Policy +for determining actions, and finally, controllers and orchestrators to +implement actions. The Policy framework is also used to monitor the loops +themselves and manage their lifecycle. DCAE also includes a number of +specialized micro-services to support some use-cases such as the Slice Analysis +or SON-Handler. Some dedicated event processor modules transform collected data +(SNMP, 3GPP XML, RESTCONF) to VES format and push the various data into data +lake. CLAMP, Policy and DCAE all have design time aspects to support the +creation of the loops. + +We refer to this automation pattern as “Closed Control loop automation” in that +it provides the necessary automation to proactively respond to network and +service conditions without human intervention. A high-level schematic of the +“Closed control loop automation” and the various phases within the service +lifecycle using the automation is depicted in Figure 4. + +Closed control loop control is provided by Data Collection, Analytics and +Events (DCAE) and one or more of the other ONAP runtime components. +Collectively, they provide FCAPS (Fault Configuration Accounting Performance +Security) functionality. DCAE collects performance, usage, and configuration +data; provides computation of analytics; aids in troubleshooting; and publishes +events, data and analytics (e.g., to policy, orchestration, and the data lake). +Another component, Holmes, connects to DCAE and provides alarm correlation +for ONAP, new data collection capabilities with High Volume VES, and bulk +performance management support. + +Working with the Policy Framework (and embedded CLAMP), these components +detect problems in the network and identify the appropriate remediation. +In some cases, the action will be automatic, and they will notify the +Service Orchestrator or one of the controllers to take action. +In other cases, as configured by the operator, they will raise an alarm +but require human intervention before executing the change. The policy +framework is extended to support additional policy decision capabilities +with the introduction of adaptive policy execution. + +Starting with the Honolulu-R8 and concluding in the Istanbul-R9 release, the +CLAMP component was successfully integrated into the Policy component initially +as a PoC in the Honolulu-R8 release and then as a fully integrated component +within the Policy component in Istanbul-R9 release. +CLAMP's functional role to provision Policy has been enhanced to support +provisioning of policies outside of the context of a Control Loop and therefore +act as a Policy UI. In the Istanbul release the CLAMP integration was +officially released. + +|image7| + +**Figure 7: ONAP Closed Control Loop Automation** + +Virtual Function Controller (VFC) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + .. warning:: The ONAP :strong:'VFC' project is :strong:'deprecated'. + +VFC provides the NFVO capability to manage the lifecycle of network service and +VNFs, by conforming to ETSI NFV specification. + +Data Movement as a Platform (DMaaP) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + .. warning:: The ONAP :strong:'DMaaP MR' project is :strong:'deprecated'. + +DMaaP provides data movement services that transports and process data from +any source to any target. Its message routing is deprecated in New Delhi release +and replaced by Strimzi and Kafka. The data routing is still part of New +Delhi release, but it will be deprecated in Oslo release. + +Use Case UI (UUI) +^^^^^^^^^^^^^^^^^ +UUI provides the capability to instantiate the blueprint User Cases and +visualize the state. UUI is an application portal which provides the ability +to manage ONAP service instances. It allows customers to create/delete/update +service instances, as well as monitoring, alarms and performance of +these instances. + +The component supports the following functionalities: +- Customer Management +- Package Management (including IBN packages) +- Service Management (including CCVPN, 5G Slicing, Intent-based automation) +- Network Topology + +UUI contains the following sub-components: +- UUI GUI +- UUI Server +- UUI NLP Server (since Istanbul release) +- UUI INTENT ANALYSIS server (since Kohn release) + +See UUI Component Architecture, + +|image8| + +**Figure 8. UUI Component Architecture** + +CLI +^^^ + +.. warning:: The ONAP :strong:'CLI' project is :strong:'deprecated'. + +ONAP CLI provides a command line interface for access to ONAP. + +External APIs +^^^^^^^^^^^^^ + +.. warning:: The ONAP :strong:`externalapi` project is :strong:`unmaintained`. + +External APIs provide services to expose the capability of ONAP. + +Shared Services +--------------- + +.. warning:: The ONAP :strong:'Logging Framework' project is a reference + implementation PoC. + +ONAP provides a set of operational services for all ONAP components including +activity logging, reporting, common data layer, configuration, persistence, +access control, secret and credential management, resiliency, and software +lifecycle management. + +ONAP Shared Services provide shared capabilities for ONAP modules. These +services handle access management and security enforcement, data backup, +configuration persistence, restoration and recovery. They support standardized +VNF interfaces and guidelines. + +Optimization Framework (OOF) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. warning:: The ONAP :strong:'OOF' project is :strong:'deprecated'. + +OOF provides a declarative, policy-driven approach for creating and running +optimization applications like Homing/Placement, and Change Management +Scheduling Optimization. + +Security Framework +^^^^^^^^^^^^^^^^^^ +The Security Framework uses open-source security patterns and tools, such as +Istio, Ingress Gateway, oauth2-proxy, and KeyCloak. This Security Framework +provides secure external and inter-component communications, authentication, +and authorization. + +For more details, see the Figure 5. + +Logging Framework (PoC) +^^^^^^^^^^^^^^^^^^^^^^^ + +.. warning:: The ONAP :strong:`Logging Framework` project is a reference + implementation :strong:`PoC`. + +Logging Framework supports open-source and standard-based logging. It separates +the application log generation from the log collection/aggregation/persistence/ +visualization/analysis; i.e., ONAP applications handle log generation only, and +the Logging Framework stack will handle the rest. As a result, operators can +leverage/extend their own logging stacks. + +Configuration Persistence Service (CPS) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The Configuration Persistence Service (CPS) provides storage for real-time +run-time configuration and operational parameters that need to be used by ONAP. +Several services ranging from SDN-C, DCAE and the network slicing use case +utilize CPS for these purposes. In Montreal release, a CPS sub-component CPS- +Temporal is removed because its function is no longer needed. +Its details in :ref:`CPS - Configuration Persistence Service<onap-cps:architecture>`. + +ONAP Modeling +------------- + +.. warning:: The ONAP :strong:'ONAP Modeling' project is :strong:'deprecated'. + +ONAP provides models to assist with service design, the development of ONAP +service components, and with the improvement of standards interoperability. +Models are an essential part for the design time and runtime framework +development. The ONAP modeling project leverages the experience of member +companies, standard organizations and other open source projects to produce +models which are simple, extensible, and reusable. The goal is to fulfill the +requirements of various use cases, guide the development and bring consistency +among ONAP components and explore a common model to improve the +interoperability of ONAP. + +ONAP supports various models detailed in the Modeling documentation. + +A new CNF modeling descriptor, Application Service Description (ASD), has been +added to ONAP since the Kohn release. It is to simplify CNF modeling and +orchestration by delegating resource modeling to Kubernetes-based resource +descriptors (e.g., Helm Chart). + +The modeling project includes the ETSI catalog component, which provides the +parser functionalities, as well as additional package management +functionalities. + +Industry Alignment +------------------ +ONAP support and collaboration with other standards and open source communities +is evident in the architecture. + +- MEF and TMF interfaces are used in the External APIs +- In addition to the ETSI-NFV defined VNFD and NSD models mentioned above, ONAP + supports the NFVO interfaces (SOL005 between the SO and VFC, SOL003 from + either the SO or VFC to an external VNFM). +- Further collaboration includes 5G/ORAN & 3GPP Harmonization, Acumos DCAE + Integration, and CNCF Telecom User Group (TUG). + +Read this whitepaper for more information: +`The Progress of ONAP: Harmonizing Open Source and Standards <https://www.onap.org/wp-content/uploads/sites/20/2019/04/ONAP_HarmonizingOpenSourceStandards_032719.pdf>`_ + +ONAP Blueprints +--------------- +ONAP can support an unlimited number of use cases, within reason. However, to +provide concrete examples of how to use ONAP to solve real-world problems, the +community has created a set of blueprints. In addition to helping users rapidly +adopt the ONAP through end-to-end solutions, these blueprints also +help the community prioritize their work. + +5G Blueprint +^^^^^^^^^^^^ +The 5G blueprint is a multi-release effort, with five key initiatives around +end-to-end service orchestration, network slicing, PNF/VNF lifecycle management +, PNF integration, and network optimization. The combination of eMBB that +promises peak data rates of 20 Mbps, uRLLC that guarantees sub-millisecond +response times, MMTC that can support 0.92 devices per sq. ft., and network +slicing brings with it some unique requirements. First ONAP needs to manage the +lifecycle of a network slice from initial creation/activation all the way to +deactivation/termination. Next, ONAP needs to optimize the network around real +time and bulk analytics, place VNFs on the correct edge cloud, scale and heal +services, and provide edge automation. ONAP also provides self organizing +network (SON) services such as physical cell ID allocation for new RAN sites. +These requirements have led to the five above-listed initiatives and have been +developed in close cooperation with other standards and open source +organizations such as 3GPP, TM Forum, ETSI, and O-RAN Software Community. + +|image9| + +**Figure 9. End-to-end 5G Service** + +Read the `5G Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_5G_062519.pdf>`_ +to learn more. + +A related activity outside of ONAP is called the 5G Super Blueprint where +multiple Linux Foundation projects are collaborating to demonstrate an +end-to-end 5G network. In the short-term, this blueprint will showcase +three major projects: ONAP, Anuket (K8S NFVI), and Magma (LTE/5GC). + +|image10| + +**Figure 10. 5G Super Blueprint Initial Integration Activity** + +In the long-term, the 5G Super Blueprint will integrate O-RAN-SC and LF Edge +projects as well. + +Residential Connectivity Blueprints +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Two ONAP blueprints (vCPE and BBS) address the residential connectivity use +case. + +Virtual CPE (vCPE) +"""""""""""""""""" +Currently, services offered to a subscriber are restricted to what is designed +into the broadband residential gateway. In the blueprint, the customer has a +slimmed down physical CPE (pCPE) attached to a traditional broadband network +such as DSL, DOCSIS, or PON (Figure 6). A tunnel is established to a data +center hosting various VNFs providing a much larger set of services to the +subscriber at a significantly lower cost to the operator. In this blueprint, +ONAP supports complex orchestration and management of open source VNFs and both +virtual and underlay connectivity. + +|image11| + +**Figure 11. ONAP vCPE Architecture** + +Read the `Residential vCPE Use Case with ONAP blueprint <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_vCPE_112918FNL.pdf>`_ +to learn more. + +Broadband Service (BBS) +""""""""""""""""""""""" +This blueprint provides multi-gigabit residential internet connectivity +services based on PON (Passive Optical Network) access technology. A key +element of this blueprint is to show automatic re-registration of an ONT +(Optical Network Terminal) once the subscriber moves (nomadic ONT) as well as +service subscription plan changes. This blueprint uses ONAP for the design, +deployment, lifecycle management, and service assurance of broadband services. +It further shows how ONAP can orchestrate services across different locations +(e.g. Central Office, Core) and technology domains (e.g. Access, Edge). + +|image12| + +**Figure 12. ONAP BBS Architecture** + +Read the `Residential Connectivity Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_BBS_062519.pdf>`_ +to learn more. + +Voice over LTE (VoLTE) Blueprint +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +This blueprint uses ONAP to orchestrate a Voice over LTE service. The VoLTE +blueprint incorporates commercial VNFs to create and manage the underlying +vEPC and vIMS services by interworking with vendor-specific components, +including VNFMs, EMSs, VIMs and SDN controllers, across Edge Data Centers and +a Core Data Center. ONAP supports the VoLTE use case with several key +components: SO, VF-C, SDN-C, and Multi-VIM/ Cloud. In this blueprint, SO is +responsible for VoLTE end-to-end service orchestration working in collaboration +with VF-C and SDN-C. SDN-C establishes network connectivity, then the VF-C +component completes the Network Services and VNF lifecycle management +(including service initiation, termination and manual scaling) and FCAPS +(fault, configuration, accounting, performance, security) management. This +blueprint also shows advanced functionality such as scaling and change +management. + +|image13| + +**Figure 13. ONAP VoLTE Architecture Open Network Automation** + +Read the `VoLTE Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_VoLTE_112918FNL.pdf>`_ +to learn more. + +Optical Transport Networking (OTN) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Two ONAP blueprints (CCVPN and MDONS) address the OTN use case. CCVPN addresses +Layers 2 and 3, while MDONS addresses Layers 0 and 1. + +CCVPN (Cross Domain and Cross Layer VPN) Blueprint +"""""""""""""""""""""""""""""""""""""""""""""""""" +CSPs, such as CMCC and Vodafone, see a strong demand for high-bandwidth, flat, +high-speed OTN (Optical Transport Networks) across carrier networks. They also +want to provide a high-speed, flexible and intelligent service for high-value +customers, and an instant and flexible VPN service for SMB companies. + +|image14| + +**Figure 14. ONAP CCVPN Architecture** + +The CCVPN (Cross Domain and Cross Layer VPN) blueprint is a combination of SOTN +(Super high-speed Optical Transport Network) and ONAP, which takes advantage of +the orchestration ability of ONAP, to realize a unified management and +scheduling of resources and services. It achieves cross-domain orchestration +and ONAP peering across service providers. In this blueprint, SO is responsible +for CCVPN end-to-end service orchestration working in collaboration with VF-C +and SDN-C. SDN-C establishes network connectivity, then the VF-C component +completes the Network Services and VNF lifecycle management. ONAP peering +across CSPs uses an east-west API which is being aligned with the MEF Interlude +API. CCVPN, in conjunction with the IBN use case, offers intent based cloud +leased line service. The key innovations in this use case are physical network +discovery and modeling, cross-domain orchestration across multiple physical +networks, cross operator end-to-end service provisioning, close-loop reroute +for cross-domain service, dynamic changes (branch sites, VNFs) and intelligent +service optimization (including AI/ML). + +Read the `CCVPN Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_CCVPN_062519.pdf>`_ +to learn more. + +MDONS (Multi-Domain Optical Network Service) Blueprint +"""""""""""""""""""""""""""""""""""""""""""""""""""""" +While CCVPN addresses the automation of networking layers 2 and 3, it does not +address layers 0 and 1. Automating these layers is equally important because +providing an end-to-end service to their customers often requires a manual and +complex negotiation between CSPs that includes both the business arrangement +and the actual service design and activation. CSPs may also be structured such +that they operate multiple networks independently and require similar +transactions among their own networks and business units in order to provide an +end-to-end service. The MDONS blueprint created by AT&T, Orange, and Fujitsu +solves the above problem. MDONS and CCVPN used together can solve the OTN +automation problem in a comprehensive manner. + +|image15| + +**Figure 15. ONAP MDONS Architecture** + +Intent Based Network (IBN) Use Case +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Intent technology can reduce the complexity of management without getting into +the intricate details of the underlying network infrastructure and contribute +to efficient network management. This use case performs a valuable business +function that can further reduce the operating expenses (OPEX) of network +management by shifting the paradigm from complex procedural operations to +declarative intent-driven operations. + +|image16| + +**Figure 16. ONAP Intent-Based Networking Use Case** + +3GPP 28.812, Intent driven Management Service (Intent driven MnS), defines +some key concepts that are used by this initiative. The Intent Based Networking +(IBN) use case includes the development of an intent decision making. This use +case has initially been shown for a smart warehouse, where the intent is to +increase the output volume of automated guided vehicles (AVG) and the network +simply scales in response. The intent UI is implemented in UUI and the +components of the intent framework interact with many components of ONAP +including SO, A&AI, Policy, DCAE and CDS. + +vFW/vDNS Blueprint +^^^^^^^^^^^^^^^^^^ +The virtual firewall, virtual DNS blueprint is a basic demo to verify that ONAP +has been correctly installed and to get a basic introduction to ONAP. The +blueprint consists of 5 VNFs: vFW, vPacketGenerator, vDataSink, vDNS and +vLoadBalancer. The blueprint exercises most aspects of ONAP, showing VNF +onboarding, network service creation, service deployment and closed-loop +automation. The key components involved are SDC, CLAMP, SO, APP-C, DCAE and +Policy. In the recent releases, the vFW blueprint has been demonstrated by +using a mix of a CNF and VNF and entirely using CNFs. + +Verified end to end tests +------------------------- +Use cases +^^^^^^^^^ +Various use cases have been tested for the Release. Use case examples are +listed below. See detailed information on use cases, functional requirements, +and automated use cases can be found here: +:doc:`Verified Use Cases<onap-integration:docs_usecases_release>`. + +- E2E Network Slicing +- 5G OOF (ONAP Optimization Framework) SON (Self-Organized Network) +- CCVPN-Transport Slicing + +Functional requirements +^^^^^^^^^^^^^^^^^^^^^^^ +Various functional requirements have been tested for the Release. Detailed +information can be found in the +:doc:`Verified Use Cases<onap-integration:docs_usecases_release>`. + +- xNF Integration + + - ONAP CNF orchestration - Enhancements + - ONAP ASD-based CNF orchestration + - PNF PreOnboarding + - PNF Plug & Play + +- Lifecycle Management + + - Policy Based Filtering + - Bulk PM / PM Data Control Extension + - Support xNF Software Upgrade in association to schema updates + - Configuration & Persistency Service + +- Security + + - CMPv2 Enhancements + +- Standard alignment + + - ETSI-Alignment for Guilin + - ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES + - Extend ORAN A1 Adapter and add A1 Policy Management + +- NFV testing Automation + + - Support for Test Result Auto Analysis & Certification + - Support for Test Task Auto Execution + - Support for Test Environment Auto Deploy + - Support for Test Topology Auto Design + +Conclusion +---------- +The ONAP provides a comprehensive functions for real-time, policy- +driven orchestration and automation of physical and virtual network functions +that will enable software, network, IT and cloud providers and developers to +rapidly automate new services and support complete lifecycle management. + +By unifying member resources, ONAP will accelerate the development of a vibrant +ecosystem around a globally shared architecture and implementation for network +automation —with an open standards focus— faster than any one product could on +its own. + +Resources +--------- +See the Resources page on `ONAP.org <https://www.onap.org/resources>`_ + +.. |image1| image:: media/ONAP-architecture.png + :width: 800px +.. |image2| image:: media/ONAP-fncview.png + :width: 800px +.. |image3| image:: media/ONAP-Streamlining-Build-Deployment.png + :width: 800px +.. |image4| image:: media/ONAP-Streamlining-Build-Deployment.png + :width: 800px +.. |image5| image:: media/ONAP-securityFramework.png + :width: 800px +.. |image6| image:: media/ONAP-NetworkSlicingOptions.png + :width: 800px +.. |image7| image:: media/ONAP-closedloop.png + :width: 800px +.. |image8| image:: media/UUI-Component-Architecture.png + :width: 800px +.. |image9| image:: media/ONAP-5G.png + :width: 800px +.. |image10| image:: media/ONAP-5GSuperBP-Integration.png + :width: 800px +.. |image11| image:: media/ONAP-vcpe.png + :width: 800px +.. |image12| image:: media/ONAP-bbs.png + :width: 800px +.. |image13| image:: media/ONAP-volte.png + :width: 800px +.. |image14| image:: media/ONAP-ccvpn.png + :width: 800px +.. |image15| image:: media/ONAP-mdons.png + :width: 800px +.. |image16| image:: media/ONAP-IntentBasedNetworking.png + :width: 800px |