summaryrefslogtreecommitdiffstats
path: root/docs/guides
diff options
context:
space:
mode:
authorPawel Pawlak <Pawel.Pawlak3@orange.com>2017-11-13 14:14:03 +0100
committerPawel Pawlak <Pawel.Pawlak3@orange.com>2017-11-13 14:22:00 +0100
commit644d806209b652dd037ff27498629bfa9f9ca63c (patch)
treeea93a570b59c3de502588a5ca03d617f2a44c2ed /docs/guides
parenta1de27914176282d103620472e09c113d085d9c5 (diff)
Fix figure numbering
Corrected numbering of figiures in text and some minor editorial issues Issue-ID: DOC-151 Change-Id: I60f89d3d11fbe6dd33f9b871a3c70aa8ba7f6de9 Signed-off-by: Pawel Pawlak <Pawel.Pawlak3@orange.com>
Diffstat (limited to 'docs/guides')
-rw-r--r--docs/guides/onap-developer/architecture/onap-architecture.rst26
1 files changed, 14 insertions, 12 deletions
diff --git a/docs/guides/onap-developer/architecture/onap-architecture.rst b/docs/guides/onap-developer/architecture/onap-architecture.rst
index 903303fef..95b91b2d9 100644
--- a/docs/guides/onap-developer/architecture/onap-architecture.rst
+++ b/docs/guides/onap-developer/architecture/onap-architecture.rst
@@ -1,4 +1,4 @@
-.. 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.
@@ -84,11 +84,11 @@ following foundational principles:
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
@@ -97,7 +97,7 @@ following foundational principles:
- Core capabilities shall support many diverse services
- The architecture shall support elastic scaling as needs grow or
- shrink
+ shrink
|image0|\
@@ -115,7 +115,9 @@ necessary to develop service/operations-specific collection, analytics,
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)
Portal
++++++
@@ -257,16 +259,16 @@ 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
@@ -322,7 +324,7 @@ providers to offer new value-added services to their customers with less
dependency on the underlying hardware.
In this use case, the customer has a physical CPE (pCPE) attached to a
-traditional broadband network such as DSL (Figure 1). On top of this
+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.
@@ -368,7 +370,7 @@ To connect the different data centers, ONAP will also have to interface
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.