+++ /dev/null
-.. 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
-
-.. _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 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
-=====================
-
-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.
-
-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.
-
-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.
-
-|image4|
-
-**Figure 4: ONAP Closed Control Loop Automation**
-
-Virtual Function Controller (VFC)
----------------------------------
-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)
------------------------------------
-DMaaP provides data movement service such as message routing and data routing.
-
-Use Case UI (UUI)
------------------
-UUI provides the capability to instantiate the blueprint User Cases and
-visualize the state.
-
-CLI
----
-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` project is :strong:`unmaintained`.
-
-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.
-
-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.
-
-ONAP supports various models detailed in the Modeling documentation.
-
-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 platform 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.
-
-|image5|
-
-**Figure 5. 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
-thre major projects: ONAP, Anuket (K8S NFVI), and Magma (LTE/5GC).
-
-|image6|
-
-**Figure 6. 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 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:
-: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
- - 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
Code Review / doc.git / blobdiff