.. 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:
providers—to deliver differentiated network services on demand, profitably and
competitively, while leveraging existing investments.
-The challenge that ONAP meets is to help operators of telecommunication
-networks 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 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).
+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
(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 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. All this is achieved while minimizing management
-fragmentation.
+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
The ONAP architecture consists of a design time and run time functions, as well
as functions for managing ONAP itself.
-.. tip:: Use the interactive features of the below ONAP Architecture Overview.
+ 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-r9-istanbul-interactive-path.svg
+ :file: media/onap-architecture-overview-interactive-path.svg
**Figure 1: Interactive high-level view of the ONAP architecture with its
microservices-based platform components.**
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 conrol framework for an automated instantiation and configuration of
+ 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 close loop management for handling healing, scaling and
- update dynamically.
+ 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
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. To reduce
-the ONAP footprint, a first effort to use a shared database has been initiated
-with a Cassandra and mariadb-galera clusters.
+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 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.
+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:
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
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.
+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
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 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,
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 SOL 0007 ), 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).
+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
+implement Closed Control Loop Automation/Control and manage elastic
scalability.
To support and encourage a healthy VNF ecosystem, ONAP provides a set of VNF
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.
+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,
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
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.
+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
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), 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.
+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
-----------
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). The App-C and SDN-C also support
-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 an
-NFV MANO stack.
-
+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
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
+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.
Multi Cloud Adaptation
----------------------
Multi-VIM/Cloud provides and infrastructure adaptation layer for VIMs/Clouds
-and K8s clusters in exposing advanced hardware platform awareness and 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 to deploy the CNF on
-the Kubernetes clusters using Kubernetes API.
-
-Closed Control Loop Automation
-==============================
+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
+: 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 are
-moved through the loop of micro-services like Homes for event detection, Policy
+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 CLAMP is used to monitor the loops themselves. 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 onto 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
+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
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).
-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. The policy framework is extended to support additional policy decision
-capabilities with the introduction of adaptive policy execution.
+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.
-|image3|
+|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`.
-**Figure 3: ONAP Closed Control Loop Automation**
+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.
+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
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.
-In R8, Honolulu, the CPS is a stand-alone component, and its details in
+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
among ONAP components and explore a common model to improve the
interoperability of ONAP.
-ONAP supports various models detailed in
-:ref:`Modeling Documentation<onap-modeling-modelspec:master_index>`.
+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
developed in close cooperation with other standards and open source
organizations such as 3GPP, TM Forum, ETSI, and O-RAN Software Community.
-|image4|
+|image5|
-**Figure 4. End-to-end 5G Service**
+**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
ONAP supports complex orchestration and management of open source VNFs and both
virtual and underlay connectivity.
-|image5|
+|image7|
-**Figure 5. ONAP vCPE Architecture**
+**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.
It further shows how ONAP can orchestrate services across different locations
(e.g. Central Office, Core) and technology domains (e.g. Access, Edge).
-|image6|
+|image8|
-**Figure 6. ONAP BBS Architecture**
+**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.
blueprint also shows advanced functionality such as scaling and change
management.
-|image7|
+|image9|
-**Figure 7. ONAP VoLTE Architecture Open Network Automation Platform**
+**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.
want to provide a high-speed, flexible and intelligent service for high-value
customers, and an instant and flexible VPN service for SMB companies.
-|image8|
+|image10|
-**Figure 8. ONAP CCVPN Architecture**
+**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
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. 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).
+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.
solves the above problem. MDONS and CCVPN used together can solve the OTN
automation problem in a comprehensive manner.
-|image9|
+|image11|
+
+**Figure 11. ONAP MDONS Architecture**
-**Figure 9. 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
------------------
- E2E Network Slicing
- 5G OOF (ONAP Optimization Framework) SON (Self-Organized Network)
- CCVPN-Transport Slicing
-- MDONS (Multi-Domain Optical Network Service)
Functional requirements
-----------------------
:width: 800px
.. |image2| image:: media/ONAP-fncview.png
:width: 800px
-.. |image3| image:: media/ONAP-closedloop.png
+.. |image3| image:: media/ONAP-NetworkSlicingOptions.png
+ :width: 800px
+.. |image4| image:: media/ONAP-closedloop.png
+ :width: 800px
+.. |image5| image:: media/ONAP-5G.png
:width: 800px
-.. |image4| image:: media/ONAP-5G.png
+.. |image6| image:: media/ONAP-5GSuperBP-Integration.png
:width: 800px
-.. |image5| image:: media/ONAP-vcpe.png
+.. |image7| image:: media/ONAP-vcpe.png
:width: 800px
-.. |image6| image:: media/ONAP-bbs.png
+.. |image8| image:: media/ONAP-bbs.png
:width: 800px
-.. |image7| image:: media/ONAP-volte.png
+.. |image9| image:: media/ONAP-volte.png
:width: 800px
-.. |image8| image:: media/ONAP-ccvpn.png
+.. |image10| image:: media/ONAP-ccvpn.png
:width: 800px
-.. |image9| image:: media/ONAP-mdons.png
+.. |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