Merge "Update DOC arch section for Beijing"

5 files changed, 405 insertions, 216 deletions

diff --git a/docs/guides/onap-developer/architecture/media/ONAP-closedloop.png b/docs/guides/onap-developer/architecture/media/ONAP-closedloop.png
index 401353af7..7d3a2cac8 100644
--- a/docs/guides/onap-developer/architecture/media/ONAP-closedloop.png
+++ b/docs/guides/onap-developer/architecture/media/ONAP-closedloop.png
diff --git a/docs/guides/onap-developer/architecture/media/ONAP-fncview.png b/docs/guides/onap-developer/architecture/media/ONAP-fncview.png
new file mode 100644
index 000000000..570629d07
--- /dev/null
+++ b/docs/guides/onap-developer/architecture/media/ONAP-fncview.png
diff --git a/docs/guides/onap-developer/architecture/media/ONAP-oom.png b/docs/guides/onap-developer/architecture/media/ONAP-oom.png
new file mode 100644
index 000000000..56bdac5d7
--- /dev/null
+++ b/docs/guides/onap-developer/architecture/media/ONAP-oom.png
diff --git a/docs/guides/onap-developer/architecture/media/ONAP-toplevel.png b/docs/guides/onap-developer/architecture/media/ONAP-toplevel.png
index f2373739c..62a9d47e1 100644
--- a/docs/guides/onap-developer/architecture/media/ONAP-toplevel.png
+++ b/docs/guides/onap-developer/architecture/media/ONAP-toplevel.png
diff --git a/docs/guides/onap-developer/architecture/onap-architecture.rst b/docs/guides/onap-developer/architecture/onap-architecture.rst
index 44c5f3a1b..f0d726762 100644
--- a/docs/guides/onap-developer/architecture/onap-architecture.rst
+++ b/docs/guides/onap-developer/architecture/onap-architecture.rst
@@ -1,18 +1,14 @@
-.. 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.
+.. Copyright 2017-2018 Huawei Technologies Co., Ltd.
 
-Introducing the ONAP Architecture (Beijing Release)
-=====================================================
+1. Introduction 
+================
 
-Introduction
--------------
-
-The ONAP project was formed in March, 2017 in response to a rising need
-for a common platform for telecommunication, cable, and cloud
-operators—and their solution providers—to deliver differentiated network
-services on demand, profitably and competitively, while leveraging
-existing investments.
+The ONAP project addresses a rising need for a common platform for
+telecommunication, cable, and cloud operators—and their solution
+providers—to deliver differentiated network services on demand,
+profitably and competitively, while leveraging existing investments.
 
 Prior to ONAP, operators of large networks have been challenged to keep
 up with the scale and cost of manual changes required to implement new
@@ -26,9 +22,9 @@ makes it difficult to monitor and guarantee service-level agreements
 
 ONAP is addressing these problems by developing global and massive scale
 (multi-site and multi-VIM) orchestration capabilities for both physical
-and virtual network elements. It facilitates service agility by
-providing a common set of REST northbound APIs that are open and
-interoperable, and by supporting YANG and TOSCA data models. ONAP’s
+and virtual network elements. It facilitates service agility by
+providing a common set of Northbound REST APIs that are open and
+interoperable, and by supporting YANG and TOSCA data models. 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, and even legacy
@@ -36,101 +32,189 @@ equipment. 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, while minimizing management
-fragmentation.
-
-The ONAP platform allows end customers and their network/cloud providers
-to collaboratively instantiate network elements and services in a
-dynamic, closed-loop process, with real-time response to actionable
+fragmentation. ONAP exists to instantiate and operate VNFs. Typical
+operator networks are expected to support multiple instances of hundreds
+of different types of VNFs. ONAP’s consolidated VNF requirements
+publication is a significant deliverable to enable commercial
+development of ONAP-compliant VNFs.
+
+The ONAP platform allows end user organizations and their network/cloud
+providers to collaboratively instantiate network elements and services
+in a dynamic, closed-loop process, with real-time response to actionable
 events. In order to design, engineer, plan, bill and assure these
-dynamic services, there are three (3) major requirements:
+dynamic services, there are three major requirements:
 
 -  A robust design framework that allows 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-loop
-   events needed for the elastic management of the service
+   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 automated
+   Controllers) that is recipe/policy-driven to provide automated
    instantiation of the service when needed and managing service demands
-   in an elastic manner
+   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.
+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
 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. This is in stark
-contrast to the traditional OSS/Management software platform
-architectures, which hardcoded service and technologies and required
-lengthy software development and integration cycles to incorporate
-changes.
+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 product/service independent capabilities for
 design, creation and lifecycle management, in accordance with the
 following foundational principles:
 
--  Ability to dynamically introduce full service life-cycle
-   orchestration (design, provisioning and operation) and service API
-   for new services & technologies without the need for new platform
-   software releases or without affecting operations for the existing
-   services
+-  Ability to dynamically introduce full service lifecycle orchestration
+   (design, provisioning and operation) and service API for new services
+   & technologies without the need for new platform software releases or
+   without affecting operations for the existing 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
+-  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
+-  The architecture shall enable sourcing best-in-class components 

 
--  Common capabilities are ‘developed’ once and ‘used’ many times
+-  Common capabilities are ‘developed’ once and ‘used’ many times 

 
--  Core capabilities shall support many diverse services
+-  Core capabilities shall support many diverse services and
+   infrastructures

 
 -  The architecture shall support elastic scaling as needs grow or
-   shrink
+   shrink 

+
+**Figure 1: ONAP Platform** 

+
+|image0|
+
+2. ONAP Architecture 
+=====================
+
+The platform provides the common functions (e.g., data collection,
+control loops, metadata recipe creation, policy/recipe distribution,
+etc.) necessary to construct specific behaviors. To create a service or
+operational capability, it is necessary to develop
+service/operations-specific service definitions, data collection,
+analytics, and policies (including recipes for corrective/remedial
+action) using the ONAP Design Framework Portal. Figure 2 provides a
+high-level view of the ONAP architecture and microservices-based
+platform components, including all ONAP projects.
+
+**Figure 2: ONAP Platform components with projects (Beijing Release)**
+
+|image1|
+
+In Figure 3 below, we provide a functional view of the architecture,
+which highlights the role of key new components:
+
+1. The Beijing release standardizes and improves northbound
+   interoperability for the ONAP Platform using the **External API**
+   component (1)
+
+2. **OOM** provides the ability to manage cloud-native installation and
+   deployments to Kubernetes-managed cloud environments.
+
+3. ONAP Common Services now manage more complex and optimized
+   topologies\ **. MUSIC** allows ONAP to scale to multi-site
+   environments to support global scale infrastructure requirements. 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.
 
-|image0|\
+4. **Information Model and framework utilities** have evolved to
+   harmonize the topology, workflow, and policy models from a number of
+   SDOs including ETSI NFV MANO, TM Forum SID, ONF Core, OASIS TOSCA,
+   IETF and MEF.
 
-**Figure 1:** ONAP Platform
+|image2| Figure 3. Functional view of the ONAP architecture
 
-ONAP Architecture
------------------
+3. Microservices Support
+========================
 
-Figure 2 provides a high-level view of the ONAP architecture and
-microservices-based platform components. The platform provides the
-common functions (e.g., data collection, control loops, meta-data recipe
-creation, policy/recipe distribution, etc.) necessary to construct
-specific behaviors. To create a service or operational capability, it is
-necessary to develop service/operations-specific collection, analytics,
-and policies (including recipes for corrective/remedial action) using
-the ONAP Design Framework Portal.
+As a cloud-native application that consists of numerous services, ONAP
+requires sophisticated initial deployment as well as post-deployment
+management. It needs to be highly reliable, scalable, secure and easy to
+manage. Also, the ONAP deployment needs to be flexible to suit the
+different scenarios and purposes for various operator environments.
+Users may also want to select part of the ONAP components to integrate
+into their own systems. To achieve all these goals, ONAP is designed as
+a microservices based system, with all components released as Docker
+containers.
 
-|image1|\
+The ONAP Operations Manager
+(`OOM <https://wiki.onap.org/display/DW/ONAP+Operations+Manager+Project>`__)
+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.
 
-**Figure 2:** ONAP Platform components (Beijing Release)
+OOM is the lifecycle manager of the ONAP platform and uses the
+Kubernetes container management system and Consul to provide the
+following functionality:
 
-Portal
-++++++
+1. **Deployment** - with built-in component dependency management
+   (including multiple clusters, federated deployments across sites, and
+   anti-affinity rules)
 
-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
-configured within the single ecosystem. 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, and dashboards, as well as hosted application
-widgets.
+2. |image3|\ **Configuration -** unified configuration across all ONAP
+   components
+
+3. **Monitoring** - real-time health monitoring feeding to a Consul GUI
+   and Kubernetes
+
+4. **Restart** - failed ONAP components are restarted automatically
+
+5. **Clustering and Scaling** - cluster ONAP services to enable seamless
+   scaling 
+
+6. **Upgrade** - change-out containers or configuration with little or
+   no service impact
+
+7. **Deletion** - cleanup individual containers or entire deployments
+
+OOM supports a wide variety of cloud infrastructures to suit your
+individual requirements.
+
+The Microservices Bus (MSB) component project provides some fundamental
+microservices support such as service registration/discovery, external
+API gateway, internal API gateway, client software development kit
+(SDK), and Swagger SDK to help ONAP projects evolve towards the
+microservice direction. MSB is integrated with OOM to provide
+transparent service registration for ONAP microservices, it also
+supports OpenStack(Heat) and bare metal deployment.
+
+4. Portal 
+==========
+
+ONAP delivers a single, consistent user experience to both design-time
+and run-time environments, based on the user’s role. Role changes are
+are configured within a single ONAP instance 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, 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
@@ -138,89 +222,132 @@ 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/refine
-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
-re-use of models, further improving efficiency as more and more models
-become available. Resources, services and products 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.
+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.
+
+5. 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) 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 (4) asset groups: Resource, Services, Products, or Offers.
+four asset groups: Resource, Services, Products, or Offers.
 
 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 Loop Automation and
-manage elastic scalability.
+workflows, policies and methods to implement Closed 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) component. 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 the future, ONAP plans to develop a VNF logo program to indicate to
-users which VNFs have gone through formal ONAP validation testing.
-
-The Policy Creation component deals with polices; these are conditions,
-requirements, constraints, attributes, or needs that must be provided,
-maintained, and/or enforced. At a lower level, Policy involves
+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.
+
+The Policy Creation component deals with polices; 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 updates 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
+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.
 
 The Closed Loop Automation Management Platform (CLAMP) provides a
-platform for designing and managing control loops. It is used to design
-a closed loop, configure it with specific parameters for a particular
-network service, then deploy and decommission it. Once deployed, a user
-can also update the loop with new parameters during runtime, as well as
-suspend and restart it.
+platform for designing and managing control loops. CLAMP is used to
+design a closed loop, configure it with specific parameters for a
+particular network service, then deploy and decommission it. Once
+deployed, a user can also update the loop with new parameters during
+runtime, as well as suspend and restart it.
 
-Runtime Framework
-+++++++++++++++++
+6. Runtime Framework 
+=====================
 
 The runtime execution framework executes the rules and policies
-distributed by the design and creation environment. This allows us to
-distribute policy enforcement and templates among various ONAP modules
-such as the Service Orchestrator (SO), Controllers, Data Collection,
-Analytics and Events (DCAE), Active and Available Inventory (A&AI), and
-a Security Framework. These components use common services that support
-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
-network, application or infrastructure services and resources. The SO
-provides orchestration at a very high level, with an end to end view of
-the infrastructure, network, and applications.
-
-Controllers
-+++++++++++
+distributed by the design and creation environment.
+
+This allows for the distribution of policy enforcement and templates
+among various ONAP modules such as the Service Orchestrator (SO),
+Controllers, Data Collection, Analytics and Events (DCAE), Active and
+Available Inventory (A&AI), and a Security Framework. These components
+use common services that support logging, access control, and data
+management. A new component, Multi-Site State Coordination (MUSIC),
+allows the platform to register and manage state across multi-site
+deployments. The External API provides access for third-party frameworks
+such as MEF, TM Forum and potentially others, to facilitate interactions
+between operator BSS and relevant ONAP components.
+
+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. The SO provides orchestration
+at a very high level, with an end-to-end view of the infrastructure,
+network, and applications.
+
+The External API Northbound Interface component provides a
+standards-based interface between the BSS and and various ONAP
+components, including Service Orchestrator, A&AI and SDC, providing an
+abstracted view of the platform. This type of abstraction allows service
+providers to use their existing BSS/OSS environment and minimize
+lengthy, high-cost integration with underlying infrastructure. The
+Beijing release is the first of a series of enhancements in support of
+SDO collaborations, which are expected to support inter-operator
+exchanges and other use cases defined by associated standards bodies
+such as MEF, TM Forum and others.
+
+Policy-driven Workload Optimization
+-----------------------------------
+
+In the Beijing Release, ONAP Optimization Framework (OOF) provides a
+policy-driven and model-driven framework for creating optimization
+applications for a broad range of use cases. OOF-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. 
+
+In the Beijing Release, 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) 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). The key operator benefit is realizing the true
+value of virtualization through fine grained optimization of cloud
+resources while delivering the performance/security SLAs. For the
+Beijing release, this feature is available for the vCPE use case.
+
+Controllers 
+------------
 
 Controllers are applications which are coupled with cloud and network
 services and execute the configuration, real-time policies, and control
@@ -230,13 +357,18 @@ 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). Also, the Virtual Function Controller (VF-C) provides an ETSI
-NFV compliant NFV-O function, and is responsible for life cycle
+NFV compliant NFV-O function, that is responsible for lifecycle
 management of virtual services and the associated physical COTS server
-infrastructure. While it provides a generic VNFM, it also integrates
-with external VNFMs and VIMs as part of a NFV MANO stack.
+infrastructure. VF-C provides a generic VNFM capability but also
+integrates with external VNFMs and VIMs as part of a NFV MANO stack.
+
+In the Beijing release, the new Multisite State Coordination (MUSIC)
+project records and manages state of the Portal and ONAP Optimization
+Framework to ensure consistency, redundancy and high availability across
+geographically distributed ONAP deployments.
 
-Inventory
-+++++++++
+Inventory 
+----------
 
 Active and Available Inventory (A&AI) provides real-time views of a
 system’s resources, services, products and their relationships with each
@@ -248,21 +380,21 @@ 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 promised dynamism of SDN/NFV, A&AI is updated in real time by
-the controllers as they make changes in the Domain 2 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.
+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.
 
-Closed-Loop Automation
-----------------------
+7. Closed-Loop Automation 
+==========================
 
 The following sections describe the ONAP frameworks designed to address
-these major requirements. The key pattern that these frameworks help
+major operator requirements. The key pattern that these frameworks help
 automate is:
 
 **Design -> Create -> Collect -> Analyze -> Detect -> Publish ->
-Respond**
+Respond.**
 
 We refer to this automation pattern as “closed-loop automation” in that
 it provides the necessary automation to proactively respond to network
@@ -271,13 +403,16 @@ schematic of the “closed-loop automation” and the various phases within
 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
-(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.
+(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, which depicts
+the topological relation between different alarms raising either from
+different layers of VNFs or from different VNF entities that are
+distributed all over the network.
 
 Working with the Policy Framework and CLAMP, these components detect
 problems in the network and identify the appropriate remediation. In
@@ -286,33 +421,68 @@ 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.
 
-|image2|
+**Figure 5: ONAP Closed Loop Automation**
 
-\ **Figure 3:** ONAP Closed Loop Automation
+|image4|
 
-Common Services
----------------
+8. Common Services 
+===================
 
 ONAP provides common operational services for all ONAP components
 including activity logging, reporting, common data layer, access
-control, resiliency, and software lifecycle management. These services
-provide access management and security enforcement, data backup,
-restoration and recovery. They support standardized VNF interfaces and
-guidelines.
+control, secret and credential management, resiliency, and software
+lifecycle management.
+
+These services provide access management and security enforcement, data
+backup, 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.
+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.
 
-Beijing Use Cases
--------------------
+9. ONAP Modeling
+================
 
-The ONAP project uses real-world use cases to help focus our releases.
-For the first release of ONAP (“Beijing”), we introduce two use cases:
-vCPE and VoLTE.
+Adopting the model-driven approach, ONAP provides models to assist the
+service design, development of various ONAP components and improve the
+interoperability of ONAP.
 
-\ **Virtual CPE Use Case**
+Models are essential part for the design time and run time 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.
+
+In the Bejing Release, ONAP supports the following Models:
+
+-  A VNF Information Model based on ETSI NFV IFA011 v.2.4.1 with
+   appropriate modifications aligned with ONAP requirements;
+
+-  A VNF Descriptor Model based on TOSCA implementation based on the IM
+   and follow the same model definitions in ETSI NFV SOL001 v 0.6.0.
+
+-  VNF Package format based on ETSI NFV SOL004 specification.
+
+These models enable ONAP to interoperate with implementations based on
+standard, and improve the industry collaboration. Service models,
+multi-VIM models and other models will be explored and defined in the
+Casablanca and future releases.
+
+10. ONAP Use Cases 
+===================
+
+The ONAP project tests blueprints for real-world use cases to enable
+rapid adoption of the platform. With the first release of ONAP
+(“Amsterdam”), we introduced two blueprints: vCPE and VoLTE. Subsequent
+releases test additional functionality and/or new blueprints.
+
+Virtual CPE Use Case 
+---------------------
 
 In this use case, many traditional network functions such as NAT,
 firewall, and parental controls are implemented as virtual network
@@ -324,7 +494,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 4). On top of this
+traditional broadband network such as DSL (Figure 1). 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.
@@ -336,56 +506,69 @@ supports such a use case with two key components – SDN-C, which manages
 connectivity services, and APP-C, which manages virtualization services.
 In this case, ONAP provides a common service orchestration layer for the
 end-to-end service. It uses the SDN-C component to establish network
-connectivity. Similarly, ONAP uses the APP-C component to manage the
-virtualization infrastructure. Deploying ONAP in this fashion simplifies
-and greatly accelerates the task of trialing and launching new
-value-added services.
-
-|image3|
-
-**Figure 4. ONAP vCPE Architecture**
-
-Read the Residential vCPE Use Case with ONAP whitepaper to learn more.
+connectivity. Similarly, ONAP uses the APP-C component to manage the VNF
+lifecycle. Deploying ONAP in this fashion simplifies and greatly
+accelerates the task of trialing and launching new value-added services.
 
-**Voice over LTE (VoLTE) Use Case**
+In the Beijing Release, the vCPE use case supports Policy-driven
+Workload Optimization, which is supported by OOF, Multi-VIM/Cloud,
+Policy, SO, A&AI and other ONAP components.
 
-The second use case developed with Beijing is Voice over LTE. This use
-case demonstrates how a Mobile Service Provider (SP) could deploy VoLTE
-services based on SDN/NFV.  The SP is able to onboard the service via
-ONAP. Specific sub-use cases are:
+**Figure 6. ONAP vCPE Architecture**
 
--  Service onboarding
+|image5|
 
--  Service configuration 
-
--  Service termination
-
--  Auto-scaling based on fault and/or performance
-
--  Fault detection & correlation, and auto-healing
-
--  Data correlation and analytics to support all sub use cases
-
-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 5, demonstrates the use of the VF-C
-component and TOSCA-based data models to manage the virtualization
-infrastructure.
-
-|image4|
+Read the Residential vCPE Use Case with ONAP whitepaper to learn more.
 
-**Figure 5. ONAP VoLTE Architecture**
+Voice over LTE (VoLTE) Use Case 
+--------------------------------
+
+The second blueprint developed for ONAP is Voice over LTE. This
+blueprint demonstrates how
a Mobile Service Provider (SP) could deploy
+VoLTE services based on SDN/NFV. This 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 Date
+Center.
+
+|image6|
+
+**Figure 7. ONAP VoLTE Architecture**
+
+ONAP supports the VoLTE use case with several key components: SO, VF-C,
+SDN-C, and Multi-VIM/ Cloud. In this use case, SO is responsible for
+VoLTE end-to-end service orchestration. It collaborates with VF-C and
+SDN-C to deploy the VoLTE service. ONAP uses the SDN-C component to
+establish network connectivity, then the VF-C component completes the
+Network Services and VNF lifecycle management (including service
+initiation, termination and manual scaling which is composed of VNFs
+based on the unified VNFD model) and FCAPS (fault, configuration,
+accounting, performance, security) management. VF-C can also integrate
+with commercial VIMs in the Edge and Core datacenters via abstract
+interfaces provided by Multi-VIM/Cloud.
+
+Using ONAP to manage the complete lifecycle of the VoLTE use case brings
+increased agility, CAPEX and OPEX reductions, and increased
+infrastructure efficiency to Communication Service Providers (CSPs). In
+addition, the usage of commercial software in this blueprint offers CSPs
+an efficient path to rapid production.
 
 Read the VoLTE Use Case with ONAP whitepaper to learn more.
 
-Conclusion
-----------
+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.
 
-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 of VNFs around a globally shared architecture and
+implementation for network automation–with an open standards focus–
+faster than any one product could on its own.
 
-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.
 
 .. |image0| image:: media/ONAP-DTRT.png
    :width: 6in
@@ -393,12 +576,18 @@ By unifying member resources, ONAP will accelerate the development of a vibrant
 .. |image1| image:: media/ONAP-toplevel.png
    :width: 6.5in
    :height: 3.13548in
-.. |image2| image:: media/ONAP-closedloop.png
+.. |image2| image:: media/fncview.png
+   :width: 6.5in
+   :height: 3.409in
+.. |image3| image:: media/oom.png
+   :width: 2.28472in
+   :height: 2.30625in
+.. |image4| image:: media/closedloop.jpeg
    :width: 6in
    :height: 2.6in
-.. |image3| image:: media/ONAP-vcpe.png
+.. |image5| image:: media/ONAP-vcpe.png
    :width: 6.5in
    :height: 3.28271in
-.. |image4| image:: media/ONAP-volte.png
+.. |image6| image:: media/ONAP-volte.png
    :width: 6.5in
    :height: 3.02431in