...
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,
crate 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 Function in Policy (Policy - 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 45. 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.
|image5|**Figure 5: ONAP Closed Control Loop Automation**
Virtual Function Shared Services =============== ONAPController (VFC)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
VFC provides athe setNFVO ofcapability operationalto servicesmanage forthe alllifecycle ONAPof componentsnetwork includingservice securityand
VNFs, activityby logging,conforming reporting,to commonETSI data layer, access control, secret and credential management, resiliency, and software lifecycle management. 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. 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 the following Models: - A VNF Descriptor Information Model based on ETSI NFV IFA011 v.2.5.1 with appropriate modifications aligned with ONAP requirements - A PNF Descriptor Information Model based on ETSI NFV IFA014 v2.5.1 - A VNF Descriptor TOSCA based Data Model based on IM and ETSI NFV SOL001 v 2.5.1 has been implemented by SDC and supported by vCPE use case. - VNF Package format leveraging the ETSI NFV SOL004 specification and supported by VNF SDK project - A VNF instance model based on ETSI NFV IFA specification and A&AI implementation
- A new CNF modeling descriptor, Application Service Descriptor (ASD), has been
introduced to simplify CNF modeling and orchestration, and to reduce redundancies
between orchestration and Kubernetes-based resource descriptors - A Network Service Descriptor (NSD) has been realized by the VFC and SO-NFVO
(using the modeling project parsing capabilities) - These models enable ONAP to interoperate with implementations based on standards and improve industry collaboration. - Root model which presents the relationship between different models - Business and Interaction model based on TMF specifications - VES model based on VES 7.x specification The Model Utilities in the ONAP Shared Utilities provides ETSI catalog capabilities,
including ETSI NFV model and package (SOL001, SOL004, SOL007) parser and ETSI
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/SO-NFVO, SOL003 from either the SO (thru SOL003 Adapter) or VFC to an external VNFM).
- Application Service Descriptor (ASD) v1.0 specification for the CNF is approved, and
ASD specification is promoted as the O-RAN standard. Read this white paper for more information: The Progress of ONAP: Harmonizing Open Source and Standards. 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. With the ONAP Dublin release, we introduced a new blueprint in the area of residential connectivity: Broadband Service. Prior blueprints were vCPE, VoLTE, vFW/vDNS, 5G, and CCVPN. 5G and CCVPN underwent feature enhancements during the Dublin release. 5G Blueprint ------------ The 5G blueprint 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 Framework' project is a reference
implementation PoC.
ONAP provides a set of operational services for all ONAP components including activity logging, reporting, common data layer, configuration, persistence,
access control, secret and credential management, resiliency, and software
lifecycle management.
ONAP Shared Services provide shared capabilities for ONAP modules. These
services provide access management and security enforcement, data backup,
configuration persistence, restoration and recovery. They support standardized
VFN interfaces and guidelines.
Optimization Framework (OOF)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Optimization Framework (OOF) provides a declarative, policy-driven approach
for creating and running optimization applications like Homing/Placement,
and Change Management Scheduling Optimization.
Security Framework
^^^^^^^^^^^^^^^^^^
The Security Framework uses open-source security patterns and tools, such as
Istio, Ingress Gateway, oauth2-proxy, and Keycloak. This Security Framework
provides secure external and inter-component communications, authentication,
and authorization.
Logging Framework (PoC)
^^^^^^^^^^^^^^^^^^^^^^^
.. warning:: The ONAP :strong:'Logging Framework' project is a reference
implementation PoC.
Logging Framework supports open-source- and standard-based logging. It separates
the application log generation from the log collection/aggregation/persistence/
visualization/analysis; i.e., ONAP applications handle log generation only, and
the Logging Framework stack will handle the rest. As a result, operators can
leverage/extend their own logging stacks.
Configuration Persistence Service (CPS)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The Configuration Persistence Service (CPS) provides storage for real-time
run-time configuration and operational parameters that need to be used by ONAP.
Several services ranging from SDN-C, DCAE and the network slicing use case
utilize CPS for these purposes. 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. A new CNF modeling descriptor, Application Service Description (ASD), has been
added to ONAP since the Kohn release. It is to simplify CNF modeling and
orchestration by delegating resource modeling to Kubernetes-based resource
descriptors (e.g., Helm Chart).
The modeling project includes the ETSI catalog component, which provides the
parser functionalities, as well as additional package management
functionalities.
Industry Alignment ------------------ ONAP support and collaboration with other standards and open-source communities is evident in the architecture. - MEF and TMF interfaces are used in the External APIs - In addition to the ETSI-NFV defined VNFD and NSD models mentioned above, ONAP supports the NFVO interfaces (SOL005 between the SO and VFC/SO-NFVO, SOL003 from either the SO (thru SOL003 Adapter) or VFC to an external VNFM).
- Application Service Descriptor (ASD) v1.0 specification for the CNF is approved, and
ASD specification is promoted as the O-RAN standard. Read this white paper 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 three key initiatives around PNF integrationend-to-end service orchestration, network optimization slicing, PNF/VNF lifecycle management,
PNF integration, and network slicingoptimization. The combination of eMBB that
promises peak data rates of 20 Mbps, uRLLC that guarantees sub-millisecond
response times and MMTC that can support 0.92 devices per sq. ft., and network
slicing brings with it some unique requirements. First, ONAP needs to optimizemanage the networklifecycle aroundof reala time 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. Next, ONAP needs to handle end-to-end network slicing. ONAP also provides self organizing
network (SON) services such as physical cell ID allocation for new RAN sites.
These requirements have led to the threefive above-listed initiatives. Betweenand thehave Casablancabeen
developed andin Dublinclose releases,cooperation thewith 5Gother blueprintstandards incorporatesand PNFopen integration,source edge
organizations automation, real-time and bulk analytics, homing (VNF placement), scaling and modeling work that will support end-to-end network slicing in future releases. |image4|**Figure 4. Disaggregated Hybrid RANsuch as 3GPP, TM Forum, ETSI, and O-RAN Software Community.
|image6|
**Figure 6. 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 Residentialof ConnectivityONAP 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. |image5|**Figure 5. ONAP vCPE Architecture** Read the Residential vCPE Use Case with ONAP blueprint 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, is called the 5G Super Blueprint where
multiple Linux Foundation projects are collaborating to demonstrate an
end-to-end 5G network. In the short-term, this blueprint will showcase
three major projects: ONAP, Anuket (K8S NFVI), and Magma (LTE/5GC).
|image 7|
** Figure 7. 5G Super Blueprint Initial Integration Activity**
In the long-term, the 5G Super Blueprint will integrate O-RAN-SC and LF Edge
projects as well.
Residential Connectivity Blueprints ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Two ONAP blueprints (vCPE and BBS) address the residential connectivity use case. Virtual CPE (vCPE) """""""""""""""""" Currently, services offered to a subscriber are restricted to what is designed
into the broadband residential gateway. In the blueprint, the customer has a
slimmed down physical CPE (pCPE) attached to a traditional broadband network
such as DSL, DOCSIS, or PON (Figure 6). A tunnel is established to a data
center hosting various VNFs providing a much larger set of services to the subscriber at a significantly lower cost to the operator. In this blueprint, ONAP supports complex orchestration and management of open source VNFs and both virtual and underlay connectivity. |image8| **Figure 8. 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>'- 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). |image6image9|**Figure 69. 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. |image7image10|**Figure 710. ONAP VoLTE Architecture Open Network Automation Platform** Read the 'VoLTE Blueprint to learn more. 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. |image8|
**Figure 8. 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 resource 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 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 and close-loop reroute for cross-domain service. The Dublin release added support for dynamic changes (branch sites, VNFs) and intelligent service optimization. To provide an extension work, many enhancement functions have been added into CCVPN blueprint in Dublin release. Multi-sites VPN service, service change and close-loop bandwidth adjustment will be realized in Dublin release, other functions, like AI Apps, SFC and E-LAN service will be supported in the next few releases. Read the CCVPN Blueprint to learn more. 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 Dublin release, the vFW blueprint has been demonstrated by using a mix of a CNF and VNF. Conclusion ==========<https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_VoLTE_112918FNF.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. |image11| **Figure 11. 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 resource 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 and 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.
|image12|
**Figure 12. 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.
|image 13|
**Figure 13. 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 release, 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>'.
- xNF Integration
- ONAP CNF orchestration - Enhancements
- ONAP ASD-based CNF orchestration
- PNF PreOnboarding
- PNF Plug & Play
- Lifecycle Management
- Policy Based Filtering
- Bulk PM / PM Data Control Extension
- Support xNF Software Upgrade in association to schema updates
- Configuration & Persistency Service
- Security
- CMPv2 Enhancements
- Standard alignment
- ETSI-Alignment for Guilin
- ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES
- Extend ORAN A1 Adapter and add A1 Policy Management
- NFV testing 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 ========= Watch videos about---------
See the majorResources platform componentspage on `YouTube'ONAP.org <https://www.youtube.com/channel/UCmzybjwmY1te0FHxLFY-Uog>`_ and `Youku <https://i.youku.com/i/UNTI4MjA5MDg5Ng==?spm=a2h1n.8251843.0.0>`_. Read about how ONAP can be deployed using containers. .. |image1.onap.org/resources>'-
.. |image1| image:: media/ONAP-architecture.png :width: 800px .. |image2| image:: media/ONAP-fncview.png :width: 800px
.. |image3| image:: media/ONAP-securityFramework.png
:width: 800px
.. |image4| image:: media/ONAP-NetworkSlicingOptions.png
:width: 800px .. |image5| image:: media/ONAP-toplevelclosedloop.png :width: 800px .. |image6| image:: 6.5inmedia/ONAP-5G.png :heightwidth: 3800px
.13548in .. |image2image7| image:: media/ONAP-5GSuperBP-fncviewIntegration.png
:width: 6.5in :height: 3.409in .. |image3800px
.. |image8| image:: media/ONAP-closedloopvcpe.png :width: 6in :height: 2.6in800px .. |image4image9| image:: media/ONAP-5Gbbs.png :width: 6in :height: 2.6in 800px .. |image5image10| image:: media/ONAP-vcpevolte.png :width: 6.5in :height: 3.28271in800px .. |image6image11| image:: media/ONAP-bbsccvpn.png :width: 6.5in :height: 3.02431in 800px
.. |image7image12| image:: media/ONAP-voltemdons.png
:width: 6.5in :height: 3.02431in 800px
.. |image8image13| image:: media/ONAP-ccvpnIntentBasedNetworking.png
:width: 6.5in800px