-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. 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.
-
-1. Introduction
-================
-
-The ONAP project addresses a rising need for a common platform for
-telecommunication, cable, and cloud operators—and their solution
-providers—to deliver differentiated network services on demand,
-profitably and competitively, while leveraging existing investments.
-
-Prior to ONAP, operators of large networks have been challenged to 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 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 problems by developing global and massive scale
-(multi-site and multi-VIM) orchestration capabilities for both physical
-and virtual network elements. It facilitates service agility by
-providing a common set of Northbound REST APIs that are open and
-interoperable, and by supporting YANG and TOSCA data models. ONAP’s
-modular and layered nature improves interoperability and simplifies
-integration, allowing it to support multiple VNF environments by
-integrating with multiple VIMs, VNFMs, SDN Controllers, and even legacy
-equipment. This approach allows network and cloud operators to optimize
-their physical and virtual infrastructure for cost and performance; at
-the same time, ONAP’s use of standard models reduces integration and
-deployment costs of heterogeneous equipment, while minimizing management
-fragmentation. ONAP exists to instantiate and operate VNFs. Typical
-operator networks are expected to support multiple instances of hundreds
-of different types of VNFs. ONAP’s consolidated VNF requirements
-publication is a significant deliverable to enable commercial
-development of ONAP-compliant VNFs.
-
-The ONAP platform allows end user organizations and their network/cloud
-providers to collaboratively instantiate network elements and services
-in a dynamic, closed-loop process, with 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 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-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 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
-technologies from the common information models, core orchestration
-platform 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 platform and related components. This is in stark
-contrast to traditional OSS/Management software platform architectures,
+.. Copyright 2019 ONAP Contributors
+.. Copyright 2020 ONAP Contributors
+.. Copyright 2021 ONAP Contributors
+
+.. _ONAP-architecture:
+
+Introduction
+============
+ONAP is a comprehensive platform 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.
+
+The ONAP project addresses the rising need for a common automation platform 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). These challenges are still very real now as
+ONAP creates its eighth release.
+
+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
+multiple VNF environments by integrating with multiple VIMs, VNFMs, SDN
+Controllers, as well as legacy equipment (PNF). 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 platform 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 platform,
+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 platform and related components. This is in
+stark contrast to traditional OSS/Management software platform architectures,
which hardcoded services and technologies, and required lengthy software
development and integration cycles to incorporate changes.
-The ONAP Platform enables product/service independent capabilities for
-design, creation and lifecycle management, in accordance with the
-following foundational principles:
+The ONAP Platform 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 platform 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
+=====================
-- Ability to dynamically introduce full service lifecycle orchestration
- (design, provisioning and operation) and service API for new services
- & technologies without the need for new platform software releases or
- without affecting operations for the existing services
+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.
+ 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.
+
+.. raw:: html
+ :file: media/onap-architecture-overview-interactive-path.svg
+
+**Figure 1: Interactive high-level view of the ONAP architecture with its
+microservices-based platform components.**
+
+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 Platform.
+#. 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. ONAP shared utilities provide
+ utilities for the support of the ONAP components.
+
+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**
+
+Microservices Support
+=====================
+As a cloud-native application that consists of numerous services, ONAP requires
+sophisticated initial deployment as well as post- deployment management.
+
+The ONAP deployment methodology needs to 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. And the platform needs to be highly reliable, scalable, 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.
+
+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 platform
+deployment. In addition, OOM helps enhance ONAP platform maturity by providing
+scalability and resiliency enhancements to the components it manages.
+
+OOM is the lifecycle manager of the ONAP platform 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.
+
+Starting with the Istanbul-R9, as a PoC, OOM provides Service Mesh-based
+mTLS (mutual TLS) between ONAP components to secure component communications,
+by leveraging Istio. The goal is to substitute (unmaintained) AAF
+functionalities.
+
+Microservices Bus (MSB)
+-----------------------
+Microservices Bus (MSB) provides fundamental microservices support including
+service registration/ discovery, external API gateway, internal API gateway,
+client software development kit (SDK), and Swagger SDK. When integrating with
+OOM, MSB has a Kube2MSB registrar which can grasp services information from k8s
+metafile and automatically register the services for ONAP components.
+
+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.
+
+Portal
+======
+
+.. warning:: The ONAP :strong:`portal` project is :strong:`unmaintained`.
+
+ONAP delivers a single, consistent user experience to both design time and
+runtime environments, based on the user’s role. Role changes are configured
+within a single ONAP instance.
+
+This user experience is managed by the ONAP Portal, which provides access to
+design, analytics and operational control/administration functions via a
+shared, role-based menu or dashboard. The portal architecture provides
+web-based capabilities such as application onboarding and management,
+centralized access management through the Authentication and Authorization
+Framework (AAF), and dashboards, as well as hosted application widgets.
+
+The portal provides an SDK to enable multiple development teams to adhere to
+consistent UI development requirements by taking advantage of built-in
+capabilities (Services/ API/ UI controls), tools and technologies. ONAP also
+provides a Command Line Interface (CLI) for operators who require it (e.g., to
+integrate with their scripting environment). ONAP SDKs enable operations/
+security, third parties (e.g., vendors and consultants), and other experts to
+continually define/redefine new collection, analytics, and policies (including
+recipes for corrective/remedial action) using the ONAP Design Framework Portal.
+
+Design Time Framework
+=====================
+The design time framework is a comprehensive development environment with
+tools, techniques, and repositories for defining/ describing resources,
+services, and products.
-- Carrier-grade scalability including horizontal scaling (linear
- scale-out) and distribution to support large number of services and
- large networks
+The design time framework facilitates 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 platform components themselves. Certain process
+specifications (i.e., ‘recipes’) and policies are geographically distributed to
+optimize performance and maximize autonomous behavior in federated cloud
+environments.
-- Metadata-driven and policy-driven architecture to ensure flexible and
- automated ways in which capabilities are used and delivered
+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), CNF packages (Helm),
+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).
+
+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.
+
+To support and encourage a healthy VNF ecosystem, ONAP provides a set of VNF
+packaging and validation tools in the VNF Supplier API and Software Development
+Kit (VNF SDK) and VNF Validation Program (VVP) components. 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. In addition, the testing capability of VNFSDK is being utilized at the LFN
+Compliance Verification Program to work towards ensuring a highly consistent
+approach to VNF verification. 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
+-------
+VND 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
+---
+VVP provides validation for the VNF Heat package.
+
+Runtime Framework
+=================
+The runtime execution framework executes 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 access control.
+
+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.
+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 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
+- Bring in the advantage of the K8S orchestrator and
+- Set stage for the Cloud Native scenarios
+
+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.
+
+|image3|
+
+**Figure 3: ONAP Network Slicing Support Options**
+
+
+Virtual Infrastructure Deployment (VID)
+---------------------------------------
+
+.. warning:: The ONAP :strong:`vid` project is :strong:`unmaintained`.
+
+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
+-----------------------------------
+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, platform capabilities, and other
+service specific 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 NFV-O 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:`unmaintained`.
+
+ONAP has two application level configuration and lifecycle management modules
+called SDN-C and App-C. Both provide similar services (application level
+configuration using NetConf, Chef, Ansible, RestConf, etc.) and lifecycle
+management functions (e.g., stop, resume, health check, etc.).
+They share common code from CCSDK repo. However, there are some differences
+between these two modules (SDN-C uses CDS only for onboarding and
+configuration / LCM flow design, whereas App-C uses CDT for the LCM functions
+for self service to provide artifacts storing in App-C Database).
+SDN-C has been used mainly for Layer1-3 network elements and App-C is
+being used for Layer4-7 network functions. This is a very loose
+distinction and we expect that over time we will get better alignment and
+have common repository for controller code supporting application level
+configuration and lifecycle management of all network elements (physical or
+virtual, layer 1-7). Because of these overlaps, we have documented SDN-C and
+App-C together. ONAP Controller Family (SDN-C / App-C) 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 platform:
+
+ - 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.
+
+Policy Framework
+----------------
+The Policy framework provides policy based decision making capability and
+supports multiple policy engines and can distribute policies through policy
+design capabilities in SDC, simplifying the design process.
+
+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)
+
+Closed Control Loop Automation Management Platform (CLAMP)
+----------------------------------------------------------
+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 3.
+
+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.
-- The architecture shall enable sourcing best-in-class components
+|image4|
-- Common capabilities are ‘developed’ once and ‘used’ many times
+**Figure 4: ONAP Closed Control Loop Automation**
-- Core capabilities shall support many diverse services and
- infrastructures
+Virtual Function Controller (VFC)
+---------------------------------
+VFC provides the NFVO capability to manage the lifecycle of network service and
+VNFs, by conforming to ETSI NFV specification.
-- The architecture shall support elastic scaling as needs grow or
- shrink
+Data Movement as a Platform (DMaaP)
+-----------------------------------
+DMaaP provides data movement service such as message routing and data routing.
-**Figure 1: ONAP Platform**
+Use Case UI (UUI)
+-----------------
+UUI provides the capability to instantiate the blueprint User Cases and
+visualize the state.
-|image0|
+CLI
+---
+ONAP CLI provides a command line interface for access to ONAP.
-2. ONAP Architecture
-=====================
+External APIs
+-------------
-The platform provides the common functions (e.g., data collection,
-control loops, metadata recipe creation, policy/recipe distribution,
-etc.) necessary to construct specific behaviors. To create a service or
-operational capability, it is necessary to develop
-service/operations-specific service definitions, data collection,
-analytics, and policies (including recipes for corrective/remedial
-action) using the ONAP Design Framework Portal. Figure 2 provides a
-high-level view of the ONAP architecture and microservices-based
-platform components, including all ONAP projects.
-
-**Figure 2: ONAP Platform components with projects (Beijing Release)**
-
-|image1|
-
-In Figure 3 below, we provide a functional view of the architecture,
-which highlights the role of key new components:
-
-1. The Beijing release standardizes and improves northbound
- interoperability for the ONAP Platform using the **External API**
- component (1)
-
-2. **OOM** provides the ability to manage cloud-native installation and
- deployments to Kubernetes-managed cloud environments.
-
-3. ONAP Common Services now manage more complex and optimized
- topologies\ **. MUSIC** allows ONAP to scale to multi-site
- environments to support global scale infrastructure requirements. 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.
-
-4. **Information Model and framework utilities** have evolved to
- harmonize the topology, workflow, and policy models from a number of
- SDOs including ETSI NFV MANO, TM Forum SID, ONF Core, OASIS TOSCA,
- IETF and MEF.
-
-|image2| Figure 3. Functional view of the ONAP architecture
-
-3. Microservices Support
-========================
-
-As a cloud-native application that consists of numerous services, ONAP
-requires sophisticated initial deployment as well as post-deployment
-management. It needs to be highly reliable, scalable, secure and easy to
-manage. Also, the ONAP deployment needs to be flexible to suit the
-different scenarios and purposes for various operator environments.
-Users may also want to select part of the ONAP components to integrate
-into their own systems. To achieve all these goals, ONAP is designed as
-a microservices based system, with all components released as Docker
-containers.
-
-The ONAP Operations Manager
-(`OOM <https://wiki.onap.org/display/DW/ONAP+Operations+Manager+Project>`__)
-is responsible for orchestrating the end-to-end lifecycle management and
-monitoring of ONAP components. OOM uses Kubernetes to provide CPU
-efficiency and platform deployment. In addition, OOM helps enhance ONAP
-platform maturity by providing scalability and resiliency enhancements
-to the components it manages.
-
-OOM is the lifecycle manager of the ONAP platform and uses the
-Kubernetes container management system and Consul to provide the
-following functionality:
-
-1. **Deployment** - with built-in component dependency management
- (including multiple clusters, federated deployments across sites, and
- anti-affinity rules)
-
-2. |image3|\ **Configuration -** unified configuration across all ONAP
- components
-
-3. **Monitoring** - real-time health monitoring feeding to a Consul GUI
- and Kubernetes
-
-4. **Restart** - failed ONAP components are restarted automatically
-
-5. **Clustering and Scaling** - cluster ONAP services to enable seamless
- scaling
-
-6. **Upgrade** - change-out containers or configuration with little or
- no service impact
-
-7. **Deletion** - cleanup individual containers or entire deployments
-
-OOM supports a wide variety of cloud infrastructures to suit your
-individual requirements.
-
-The Microservices Bus (MSB) component project provides some fundamental
-microservices support such as service registration/discovery, external
-API gateway, internal API gateway, client software development kit
-(SDK), and Swagger SDK to help ONAP projects evolve towards the
-microservice direction. MSB is integrated with OOM to provide
-transparent service registration for ONAP microservices, it also
-supports OpenStack(Heat) and bare metal deployment.
-
-4. Portal
-==========
+.. warning:: The ONAP :strong:`externalapi` project is :strong:`unmaintained`.
-ONAP delivers a single, consistent user experience to both design-time
-and run-time environments, based on the user’s role. Role changes are
-are configured within a single ONAP instance instance.
-
-This user experience is managed by the ONAP Portal, which provides
-access to design, analytics and operational control/administration
-functions via a shared, role-based menu or dashboard. The portal
-architecture provides web-based capabilities such as application
-onboarding and management, centralized access management, and
-dashboards, as well as hosted application widgets.
-
-The portal provides an SDK to enable multiple development teams to
-adhere to consistent UI development requirements by taking advantage of
-built-in capabilities (Services/ API/ UI controls), tools and
-technologies. ONAP also provides a Command Line Interface (CLI) for
-operators who require it (e.g., to integrate with their scripting
-environment). ONAP SDKs enable operations/security, third parties (e.g.,
-vendors and consultants), and other experts to continually
-define/redefine new collection, analytics, and policies (including
-recipes for corrective/remedial action) using the ONAP Design Framework
-Portal.
-
-5. Design-time Framework
-=========================
+External APIs provide services to expose the capability of ONAP.
-The design-time framework is a comprehensive development environment
-with tools, techniques, and repositories for defining/ describing
-resources, services, and products.
+Shared Services
+===============
-The design time framework facilitates 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
-platform components themselves. Certain process specifications (i.e.,
-‘recipes’) and policies are geographically distributed to optimize
-performance and maximize autonomous behavior in federated cloud
-environments.
+.. warning:: The ONAP :strong:`logging` project is :strong:`unmaintained`.
-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.
-
-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 Loop
-Automation/Control and manage elastic scalability.
-
-To support and encourage a healthy VNF ecosystem, ONAP provides a set of
-VNF packaging and validation tools in the VNF Supplier API and Software
-Development Kit (VNF SDK) and VNF Validation Program (VVP) components.
-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.
-
-The Policy Creation component deals with polices; 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.
-
-The Closed Loop Automation Management Platform (CLAMP) provides a
-platform for designing and managing control loops. CLAMP is used to
-design a closed loop, configure it with specific parameters for a
-particular network service, then deploy and decommission it. Once
-deployed, a user can also update the loop with new parameters during
-runtime, as well as suspend and restart it.
-
-6. Runtime Framework
-=====================
+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.
-The runtime execution framework executes the rules and policies
-distributed by the design and creation environment.
-
-This allows for the distribution of policy enforcement and templates
-among various ONAP modules such as the Service Orchestrator (SO),
-Controllers, Data Collection, Analytics and Events (DCAE), Active and
-Available Inventory (A&AI), and a Security Framework. These components
-use common services that support logging, access control, and data
-management. A new component, Multi-Site State Coordination (MUSIC),
-allows the platform to register and manage state across multi-site
-deployments. The External API provides access for third-party frameworks
-such as MEF, TM Forum and potentially others, to facilitate interactions
-between operator BSS and relevant ONAP components.
-
-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. The SO provides orchestration
-at a very high level, with an end-to-end view of the infrastructure,
-network, and applications.
-
-The External API Northbound Interface component provides a
-standards-based interface between the BSS and and various ONAP
-components, including Service Orchestrator, A&AI and SDC, providing an
-abstracted view of the platform. This type of abstraction allows service
-providers to use their existing BSS/OSS environment and minimize
-lengthy, high-cost integration with underlying infrastructure. The
-Beijing release is the first of a series of enhancements in support of
-SDO collaborations, which are expected to support inter-operator
-exchanges and other use cases defined by associated standards bodies
-such as MEF, TM Forum and others.
-
-Policy-driven Workload Optimization
------------------------------------
+These services provide access management and security enforcement, data backup,
+configuration persistence, restoration and recovery. They support standardized
+VNF interfaces and guidelines.
+
+Operating in a virtualized environment introduces new security challenges and
+opportunities. ONAP provides increased security by embedding access controls in
+each ONAP platform component, augmented by analytics and policy components
+specifically designed for the detection and mitigation of security violations.
+
+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. Its details in
+:ref:`CPS - Configuration Persistence Service<onap-cps:architecture>`.
+
+ONAP Modeling
+=============
+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.
-In the Beijing Release, ONAP Optimization Framework (OOF) provides a
-policy-driven and model-driven framework for creating optimization
-applications for a broad range of use cases. OOF-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, platform
-capabilities, and other service specific constraints.
-
-In the Beijing Release, 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
-Hardware Platform Awareness (HPA) 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). The key operator benefit is realizing the true
-value of virtualization through fine grained optimization of cloud
-resources while delivering the performance/security SLAs. For the
-Beijing release, this feature is available for the vCPE use case.
-
-Controllers
-------------
+ONAP supports various models detailed in the Modeling documentation.
-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 (network configuration (SDN-C) and application
-(App-C). Also, the Virtual Function Controller (VF-C) provides an ETSI
-NFV compliant NFV-O function, that is responsible for lifecycle
-management of virtual services and the associated physical COTS server
-infrastructure. VF-C provides a generic VNFM capability but also
-integrates with external VNFMs and VIMs as part of a NFV MANO stack.
-
-In the Beijing release, the new Multisite State Coordination (MUSIC)
-project records and manages state of the Portal and ONAP Optimization
-Framework to ensure consistency, redundancy and high availability across
-geographically distributed ONAP deployments.
-
-Inventory
-----------
-
-Active and Available Inventory (A&AI) provides real-time views of a
-system’s resources, services, products and their relationships with each
-other. 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.
-
-7. Closed-Loop Automation
-==========================
-
-The following sections describe the ONAP frameworks designed to address
-major operator requirements. The key pattern that these frameworks help
-automate is:
-
-**Design -> Create -> Collect -> Analyze -> Detect -> Publish ->
-Respond.**
-
-We refer to this automation pattern as “closed-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-loop automation” and the various phases within
-the service lifecycle using the automation is depicted in Figure 3.
-
-Closed-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, which depicts
-the topological relation between different alarms raising either from
-different layers of VNFs or from different VNF entities that are
-distributed all over the network.
-
-Working with the Policy Framework and 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 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.
-
-**Figure 5: ONAP Closed Loop Automation**
+The modeling project includes the ETSI catalog component, which provides the
+parser functionalities, as well as additional package management
+functionalities.
-|image4|
+Industry Alignment
+==================
+ONAP support and collaboration with other standards and open source communities
+is evident in the architecture.
-8. Common Services
-===================
+- 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).
-ONAP provides common operational services for all ONAP components
-including activity logging, reporting, common data layer, access
-control, secret and credential management, resiliency, and software
-lifecycle management.
+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>`_
-These services provide access management and security enforcement, data
-backup, restoration and recovery. They support standardized VNF
-interfaces and guidelines.
+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 platform through end-to-end solutions, these blueprints also
+help the community prioritize their work.
-Operating in a virtualized environment introduces new security
-challenges and opportunities. ONAP provides increased security by
-embedding access controls in each ONAP platform component, augmented by
-analytics and policy components specifically designed for the detection
-and mitigation of security violations.
+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.
-9. ONAP Modeling
-================
+|image5|
-Adopting the model-driven approach, ONAP provides models to assist the
-service design, development of various ONAP components and improve the
-interoperability of ONAP.
+**Figure 5. End-to-end 5G Service**
-Models are essential part for the design time and run time 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.
-
-In the Bejing Release, ONAP supports the following Models:
-
-- A VNF Information Model based on ETSI NFV IFA011 v.2.4.1 with
- appropriate modifications aligned with ONAP requirements;
-
-- A VNF Descriptor Model based on TOSCA implementation based on the IM
- and follow the same model definitions in ETSI NFV SOL001 v 0.6.0.
-
-- VNF Package format based on ETSI NFV SOL004 specification.
-
-These models enable ONAP to interoperate with implementations based on
-standard, and improve the industry collaboration. Service models,
-multi-VIM models and other models will be explored and defined in the
-Casablanca and future releases.
-
-10. ONAP Use Cases
-===================
-
-The ONAP project tests blueprints for real-world use cases to enable
-rapid adoption of the platform. With the first release of ONAP
-(“Amsterdam”), we introduced two blueprints: vCPE and VoLTE. Subsequent
-releases test additional functionality and/or new blueprints.
-
-Virtual CPE Use Case
----------------------
-
-In this use case, many traditional network functions such as NAT,
-firewall, and parental controls are implemented as virtual network
-functions. These VNFs can either be deployed in the data center or at
-the customer edge (or both). Also, some network traffic will be tunneled
-(using MPLS VPN, VxLAN, etc.) to the data center, while other traffic
-can flow directly to the Internet. A vCPE infrastructure allows service
-providers to offer new value-added services to their customers with less
-dependency on the underlying hardware.
-
-In this use case, the customer has a physical CPE (pCPE) attached to a
-traditional broadband network such as DSL (Figure 1). On top of this
-service, a tunnel is established to a data center hosting various VNFs.
-In addition, depending on the capabilities of the pCPE, some functions
-can be deployed on the customer site.
-
-This use case traditionally requires fairly complicated orchestration
-and management, managing both the virtual environment and underlay
-connectivity between the customer and the service provider. ONAP
-supports such a use case with two key components – SDN-C, which manages
-connectivity services, and APP-C, which manages virtualization services.
-In this case, ONAP provides a common service orchestration layer for the
-end-to-end service. It uses the SDN-C component to establish network
-connectivity. Similarly, ONAP uses the APP-C component to manage the VNF
-lifecycle. Deploying ONAP in this fashion simplifies and greatly
-accelerates the task of trialing and launching new value-added services.
-
-In the Beijing Release, the vCPE use case supports Policy-driven
-Workload Optimization, which is supported by OOF, Multi-VIM/Cloud,
-Policy, SO, A&AI and other ONAP components.
-
-**Figure 6. ONAP vCPE Architecture**
+Read the `5G Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_5G_062519.pdf>`_
+to learn more.
-|image5|
+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
+thre major projects: ONAP, Anuket (K8S NFVI), and Magma (LTE/5GC).
+
+|image6|
+
+**Figure 6. 5G Super Blueprint Initial Integration Activity**
-Read the Residential vCPE Use Case with ONAP whitepaper to learn more.
+In the long-term, the 5G Super Blueprint will integrate O-RAN-SC and LF Edge
+projects as well.
-Voice over LTE (VoLTE) Use Case
+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 5). 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.
+
+|image7|
+
+**Figure 7. 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).
+
+|image8|
+
+**Figure 8. 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.
+
+|image9|
+
+**Figure 9. ONAP VoLTE Architecture Open Network Automation Platform**
+
+Read the `VoLTE Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_VoLTE_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.
+
+|image10|
+
+**Figure 10. 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.
+
+|image11|
+
+**Figure 11. 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
+
+|image12|
+
+**Figure 12. 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:
+:ref:`Verified Use Cases<onap-integration:docs_usecases_release>`.
-The second blueprint developed for ONAP is Voice over LTE. This
-blueprint demonstrates how
a Mobile Service Provider (SP) could deploy
-VoLTE services based on SDN/NFV. This 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 Date
-Center.
+- E2E Network Slicing
+- 5G OOF (ONAP Optimization Framework) SON (Self-Organized Network)
+- CCVPN-Transport Slicing
-|image6|
+Functional requirements
+-----------------------
+Various functional requirements have been tested for the Release. Detailed
+information can be found in the
+:ref:`Verified Use Cases<onap-integration:docs_usecases_release>`.
+
+- xNF Integration
-**Figure 7. ONAP VoLTE Architecture**
-
-ONAP supports the VoLTE use case with several key components: SO, VF-C,
-SDN-C, and Multi-VIM/ Cloud. In this use case, SO is responsible for
-VoLTE end-to-end service orchestration. It collaborates with VF-C and
-SDN-C to deploy the VoLTE service. ONAP uses the SDN-C component to
-establish network connectivity, then the VF-C component completes the
-Network Services and VNF lifecycle management (including service
-initiation, termination and manual scaling which is composed of VNFs
-based on the unified VNFD model) and FCAPS (fault, configuration,
-accounting, performance, security) management. VF-C can also integrate
-with commercial VIMs in the Edge and Core datacenters via abstract
-interfaces provided by Multi-VIM/Cloud.
-
-Using ONAP to manage the complete lifecycle of the VoLTE use case brings
-increased agility, CAPEX and OPEX reductions, and increased
-infrastructure efficiency to Communication Service Providers (CSPs). In
-addition, the usage of commercial software in this blueprint offers CSPs
-an efficient path to rapid production.
-
-Read the VoLTE Use Case with ONAP whitepaper to learn more.
-
-Conclusion
-===========
-
-The ONAP platform provides a comprehensive platform 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 of VNFs around a globally shared architecture and
-implementation for network automation–with an open standards focus–
-faster than any one product could on its own.
-
-
-.. |image0| image:: media/ONAP-DTRT.png
- :width: 6in
- :height: 2.6in
-.. |image1| image:: media/ONAP-toplevel.png
- :width: 6.5in
- :height: 3.13548in
-.. |image2| image:: media/fncview.png
- :width: 6.5in
- :height: 3.409in
-.. |image3| image:: media/oom.png
- :width: 2.28472in
- :height: 2.30625in
-.. |image4| image:: media/closedloop.jpeg
- :width: 6in
- :height: 2.6in
-.. |image5| image:: media/ONAP-vcpe.png
- :width: 6.5in
- :height: 3.28271in
-.. |image6| image:: media/ONAP-volte.png
- :width: 6.5in
- :height: 3.02431in
+ - ONAP CNF orchestration - Enhancements
+ - 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 Automatic Platform
+
+ - 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 platform provides a comprehensive platform 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-NetworkSlicingOptions.png
+ :width: 800px
+.. |image4| image:: media/ONAP-closedloop.png
+ :width: 800px
+.. |image5| image:: media/ONAP-5G.png
+ :width: 800px
+.. |image6| image:: media/ONAP-5GSuperBP-Integration.png
+ :width: 800px
+.. |image7| image:: media/ONAP-vcpe.png
+ :width: 800px
+.. |image8| image:: media/ONAP-bbs.png
+ :width: 800px
+.. |image9| image:: media/ONAP-volte.png
+ :width: 800px
+.. |image10| image:: media/ONAP-ccvpn.png
+ :width: 800px
+.. |image11| image:: media/ONAP-mdons.png
+ :width: 800px
+.. |image12| image:: media/ONAP-IntentBasedNetworking.png
+ :width: 800px
\ No newline at end of file
Code Review / doc.git / blobdiff