Merge "Adding architecture document to docs in rst format"

6 files changed, 397 insertions, 0 deletions

diff --git a/docs/guides/onap-developer/architecture/media/ONAP-DTRT.png b/docs/guides/onap-developer/architecture/media/ONAP-DTRT.png
new file mode 100644
index 000000000..403c8d93e
--- /dev/null
+++ b/docs/guides/onap-developer/architecture/media/ONAP-DTRT.png
diff --git a/docs/guides/onap-developer/architecture/media/ONAP-closedloop.png b/docs/guides/onap-developer/architecture/media/ONAP-closedloop.png
new file mode 100644
index 000000000..401353af7
--- /dev/null
+++ b/docs/guides/onap-developer/architecture/media/ONAP-closedloop.png
diff --git a/docs/guides/onap-developer/architecture/media/ONAP-toplevel.png b/docs/guides/onap-developer/architecture/media/ONAP-toplevel.png
new file mode 100644
index 000000000..7b22ac264
--- /dev/null
+++ b/docs/guides/onap-developer/architecture/media/ONAP-toplevel.png
diff --git a/docs/guides/onap-developer/architecture/media/ONAP-vcpe.png b/docs/guides/onap-developer/architecture/media/ONAP-vcpe.png
new file mode 100644
index 000000000..02ff80f7c
--- /dev/null
+++ b/docs/guides/onap-developer/architecture/media/ONAP-vcpe.png
diff --git a/docs/guides/onap-developer/architecture/media/ONAP-volte.png b/docs/guides/onap-developer/architecture/media/ONAP-volte.png
new file mode 100644
index 000000000..bce590655
--- /dev/null
+++ b/docs/guides/onap-developer/architecture/media/ONAP-volte.png
diff --git a/docs/guides/onap-developer/architecture/onap-architecture.rst b/docs/guides/onap-developer/architecture/onap-architecture.rst
new file mode 100644
index 000000000..54ba6b728
--- /dev/null
+++ b/docs/guides/onap-developer/architecture/onap-architecture.rst
@@ -0,0 +1,397 @@
+.. 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 **
+-----------------
+
+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.
+
+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
+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 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).
+
+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
+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
+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
+events. In order to design, engineer, plan, bill and assure these
+dynamic services, there are three (3) 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
+
+-  An orchestration and control framework (Service Orchestrator and
+   Controllers) that is recipe/policy driven to provide automated
+   instantiation of the service when needed and managing service demands
+   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.
+
+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.
+
+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
+
+-  Carrier-grade scalability including horizontal scaling (linear
+       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
+
+-  The architecture shall enable sourcing best-in-class components
+
+-  Common capabilities are ‘developed’ once and ‘used’ many times
+
+-  Core capabilities shall support many diverse services
+
+-  The architecture shall support elastic scaling as needs grow or
+       shrink
+
+|image0|\ 
+
+**Figure 1:** ONAP Platform
+
+**ONAP Architecture**
+=====================
+
+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.
+
+|image1|\  **Figure 2:** ONAP Platform components (Amsterdam Release)
+
+1. **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
+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.
+
+The portal provides an SDK to enable multiple development teams to
+adhere to consistent UI development requirements by taking advantage of
+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.
+
+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.
+
+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.
+
+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
+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
+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.
+
+**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
+-----------
+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
+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). Also, the Virtual Function Controller (VF-C) provides an ETSI
+NFV compliant NFV-O function, and is responsible for life cycle
+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.
+
+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
+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 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.
+
+**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
+
+***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.
+
+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.
+
+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.
+
+|image2|
+
+\ **Figure 3:** ONAP Closed Loop Automation
+
+**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.
+
+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.
+
+**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:
+vCPE and VoLTE.
+
+\ **Virtual CPE Use Case**
+
+In this use case, many traditional network functions such as NAT,
+firewall, and parental controls are implemented as virtual network
+functions. These VNFs can either be deployed in the data center or at
+the customer edge (or both). Also, some network traffic will be tunneled
+(using MPLS VPN, VxLAN, etc.) to the data center, while other traffic
+can flow directly to the Internet. A vCPE infrastructure allows service
+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
+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.
+
+This use case traditionally requires fairly complicated orchestration
+and management, managing both the virtual environment and underlay
+connectivity between the customer and the service provider. ONAP
+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.
+
+**Voice over LTE (VoLTE) Use Case**
+
+The second use case developed with Amsterdam 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:
+
+-  Service onboarding
+
+-  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 6, demonstrates the use of the VF-C
+component and TOSCA-based data models to manage the virtualization
+infrastructure.
+
+|image4|
+
+**Figure 5. ONAP VoLTE Architecture**
+
+Read the VoLTE Use Case with ONAP whitepaper to learn more.
+
+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.
+
+.. |image0| image:: media/ONAP-DTRT.png
+   :width: 6in
+   :height: 2.6in
+.. |image1| image:: media/toplevel.png
+   :width: 6.5in
+   :height: 3.13548in
+.. |image2| image:: media/closedloop.jpeg
+   :width: 6in
+   :height: 2.6in
+.. |image3| image:: media/vcpe.png
+   :width: 6.5in
+   :height: 3.28271in
+.. |image4| image:: media/volte.png
+   :width: 6.5in
+   :height: 3.02431in