-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright 2017 Huawei Technologies Co., Ltd.
-**Introducing the ONAP Architecture (Amsterdam Release)**
-=========================================================
-**Introduction **
------------------
+Introducing the ONAP Architecture (Amsterdam Release)
+=====================================================
+
+Introduction
+-------------
The ONAP project was formed in March, 2017 in response to a rising need
for a common platform for telecommunication, cable, and cloud
services
- Carrier-grade scalability including horizontal scaling (linear
- scale-out) and distribution to support large number of services
- and large networks
+ scale-out) and distribution to support large number of services
+ and large networks
- Metadata-driven and policy-driven architecture to ensure flexible
- ways in which capabilities are used and delivered
+ ways in which capabilities are used and delivered
- The architecture shall enable sourcing best-in-class components
- Core capabilities shall support many diverse services
- The architecture shall support elastic scaling as needs grow or
- shrink
+ shrink
|image0|\
**Figure 1:** ONAP Platform
-**ONAP Architecture**
-=====================
+ONAP Architecture
+-----------------
Figure 2 provides a high-level view of the ONAP architecture and
microservices-based platform components. The platform provides the
and policies (including recipes for corrective/remedial action) using
the ONAP Design Framework Portal.
-|image1|\ **Figure 2:** ONAP Platform components (Amsterdam Release)
+|image1|\
+
+**Figure 2:** ONAP Platform components (Amsterdam Release)
-1. **Portal**
+Portal
+++++++
ONAP delivers a single, consistent user experience to both design time
and run time environments, based on the user’s role; role changes to be
new collection, analytics, and policies (including recipes for
corrective/remedial action) using the ONAP Design Framework Portal.
-**Design time Framework**
-=========================
+Design time Framework
++++++++++++++++++++++
The design time framework is a comprehensive development environment
with tools, techniques, and repositories for defining/describing
can also update the loop with new parameters during runtime, as well as
suspend and restart it.
-**Runtime Framework**
-=====================
+Runtime Framework
++++++++++++++++++
The runtime execution framework executes the rules and policies
distributed by the design and creation environment. This allows us to
logging, access control, and data management.
Orchestration
--------------
++++++++++++++
+
The Service Orchestrator (SO) component executes the
specified processes and automates sequences of activities, tasks, rules
and policies needed for on-demand creation, modification or removal of
the infrastructure, network, and applications.
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
with external VNFMs and VIMs as part of a NFV MANO stack.
Inventory
----------
++++++++++
+
Active and Available Inventory (A&AI) provides real-time views of a
system’s resources, services, products and their relationships with each
other. The views provided by A&AI relate data managed by multiple ONAP
and quickly via SDC catalog definitions, eliminating the need for
lengthy development cycles.
-**Closed-Loop Automation**
-==========================
+Closed-Loop Automation
+----------------------
The following sections describe the ONAP frameworks designed to address
these major requirements. The key pattern that these frameworks help
-automate is
+automate is:
-***Design -> Create -> Collect -> Analyze -> Detect -> Publish ->
-Respond.***
+**Design -> Create -> Collect -> Analyze -> Detect -> Publish ->
+Respond**
We refer to this automation pattern as “closed-loop automation” in that
it provides the necessary automation to proactively respond to network
and service conditions without human intervention. A high-level
schematic of the “closed-loop automation” and the various phases within
-the service lifecycle using the automation is depicted in Figure 4.
+the service lifecycle using the automation is depicted in Figure 3.
Closed-loop control is provided by Data Collection, Analytics and Events
(DCAE) and other ONAP components. Collectively, they provide FCAPS
\ **Figure 3:** ONAP Closed Loop Automation
-**Common Services**
-===================
+Common Services
+---------------
ONAP provides common operational services for all ONAP components
including activity logging, reporting, common data layer, access
in each ONAP platform component, augmented by analytics and policy components
specifically designed for the detection and mitigation of security violations.
-**Amsterdam Use Cases**
-=======================
+Amsterdam Use Cases
+-------------------
The ONAP project uses real-world use cases to help focus our releases.
For the first release of ONAP (“Amsterdam”), we introduce two use cases:
dependency on the underlying hardware.
In this use case, the customer has a physical CPE (pCPE) attached to a
-traditional broadband network such as DSL (Figure 1). On top of this
+traditional broadband network such as DSL (Figure 4). On top of this
service, a tunnel is established to a data center hosting various VNFs.
In addition, depending on the capabilities of the pCPE, some functions
can be deployed on the customer site.
with legacy systems and physical function to establish VPN connectivity
in a brown field deployment.
-The VoLTE use case, shown in Figure 6, demonstrates the use of the VF-C
+The VoLTE use case, shown in Figure 5, demonstrates the use of the VF-C
component and TOSCA-based data models to manage the virtualization
infrastructure.
.. |image0| image:: media/ONAP-DTRT.png
:width: 6in
:height: 2.6in
-.. |image1| image:: media/toplevel.png
+.. |image1| image:: media/ONAP-toplevel.png
:width: 6.5in
:height: 3.13548in
-.. |image2| image:: media/closedloop.jpeg
+.. |image2| image:: media/ONAP-closedloop.png
:width: 6in
:height: 2.6in
-.. |image3| image:: media/vcpe.png
+.. |image3| image:: media/ONAP-vcpe.png
:width: 6.5in
:height: 3.28271in
-.. |image4| image:: media/volte.png
+.. |image4| image:: media/ONAP-volte.png
:width: 6.5in
:height: 3.02431in
Code Review / doc.git / blobdiff