Merge "Improve security section of release notes"
diff --git a/docs/guides/onap-developer/apiref/index.rst b/docs/guides/onap-developer/apiref/index.rst
index 178425b..4c01405 100644
--- a/docs/guides/onap-developer/apiref/index.rst
+++ b/docs/guides/onap-developer/apiref/index.rst
@@ -48,7 +48,7 @@
:titlesonly:
AAF - Application Authorization Framework <../../../submodules/aaf/sms.git/docs/api.rst>
- AAI - Active and Available Inventory <../../../submodules/aai/aai-common.git/docs/AAI REST API Documentation/AAIRESTAPI_AMSTERDAM.rst>
+ AAI - Active and Available Inventory <../../../submodules/aai/aai-common.git/docs/AAI REST API Documentation/AAIRESTAPI.rst>
AAI ESR - AAI External System Register <../../../submodules/aai/esr-server.git/docs/offeredapis.rst>
DMAAP DBC - Data Management as a Platform (Data Bus Controller) <../../../submodules/dmaap/dbcapi.git/docs/api.rst>
DMAAP DR - Data Management as a Platform (Data Router) <../../../submodules/dmaap/datarouter.git/docs/index.rst>
diff --git a/docs/guides/onap-developer/architecture/media/ONAP-toplevel.png b/docs/guides/onap-developer/architecture/media/ONAP-toplevel.png
index 62a9d47..1c144fc 100644
--- a/docs/guides/onap-developer/architecture/media/ONAP-toplevel.png
+++ b/docs/guides/onap-developer/architecture/media/ONAP-toplevel.png
Binary files differ
diff --git a/docs/guides/onap-developer/architecture/onap-architecture.rst b/docs/guides/onap-developer/architecture/onap-architecture.rst
index 35156b2..ca0399a 100644
--- a/docs/guides/onap-developer/architecture/onap-architecture.rst
+++ b/docs/guides/onap-developer/architecture/onap-architecture.rst
@@ -2,66 +2,68 @@
.. 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright 2017-2018 Huawei Technologies Co., Ltd.
+.. Copyright 2019 ONAP Contributors
.. _ONAP-architecture:
-1. Introduction
-===============
+Introduction
+============
-The ONAP project addresses the rising need for a common automation platform
-for telecommunication, cable, and cloud service providers—and their solution
+The ONAP project addresses the rising need for a common automation platform for
+telecommunication, cable, and cloud service providers—and their solution
providers—to deliver differentiated network services on demand, profitably and
competitively, while leveraging existing investments.
-Prior to ONAP, operators of telecommunication 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). These challenges are still very real
-now as ONAP creates its third release.
+The challenge that ONAP meets is to help operators of telecommunication
+networks 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 to 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). These
+challenges are still very real now as ONAP creates its fourth release.
ONAP is addressing these challenges by developing global and massive scale
(multi-site and multi-VIM) automation capabilities for both physical and
virtual network elements. It facilitates service agility by supporting data
-models for rapid service and resource deployment, and providing a common set of
-Northbound REST APIs that are open and interoperable, and by supporting model
-driven interfaces to the networks. 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. ONAP’s consolidated VNF requirements publication will
-enable commercial development of ONAP-compliant VNFs. 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.
+models for rapid service and resource deployment and providing a common set of
+northbound REST APIs that are open and interoperable, and by supporting
+model-driven interfaces to the networks. 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, as well as legacy equipment (PNF). ONAP’s consolidated xNF
+requirements publication enables commercial development of ONAP-compliant xNFs.
+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. All this is achieved while minimizing management
+fragmentation.
-The ONAP platform allows end user organizations and their network/cloud
+The ONAP platform allows end-user organizations and their network/cloud
providers to collaboratively instantiate network elements and services in a
-dynamic, closed control loop process, with real-time response to actionable
-events. In order to design, engineer, plan, bill and assure these dynamic
-services, there are three major requirements:
+rapid and dynamic way, together with supporting a closed control loop process
+that supports real-time response to actionable events. In order to design,
+engineer, plan, bill and assure these 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 control loop events needed for the
- elastic management of the service.
+- A robust design framework that allows the 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 control 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 orchestration and control framework (Service Orchestrator and Controllers
+ ) that is recipe/ policy-driven to provide an 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.
+- 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
+To achieve this, ONAP decouples the details of specific services and supporting
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
@@ -72,72 +74,76 @@
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,
+The ONAP Platform enables service/resource independent capabilities for design,
creation and lifecycle management, in accordance with the following
foundational principles:
-- Ability to dynamically introduce full service lifecycle orchestration
- (design, provisioning and operation) and service API for new services and
- 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 and
- automated 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 and infrastructures
-- The architecture shall support elastic scaling as needs grow or shrink
+- Ability to dynamically introduce full service lifecycle orchestration (design
+ ,provisioning and operation) and service API for new services and
+ 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 a large number of services and large networks
+- 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
+- Common capabilities are ‘developed’ once and ‘used’ many times
+- Core capabilities shall support many diverse services and infrastructures
-2. ONAP Architecture
-====================
+Further, ONAP comes with a functional architecture with component definitions
+and interfaces, which provides a force of industry alignment in addition to
+the open source code.
-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.
+ONAP Architecture
+=================
+The platform provides common functions such as data collection, control loops,
+meta-data recipe creation, and policy/recipe distribution that are 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
+To create a service or operational capability ONAP supports service/
+operations-specific service definitions, data collection, analytics, and
+policies (including recipes for corrective/remedial action) using the ONAP
Design Framework Portal.
-Figure 1 provides a high-level view of the ONAP architecture and
+Figure 1 provides a high-level view of the ONAP architecture with its
microservices-based platform components.
|image1|
-**Figure 1: ONAP Platform architecture (Casablanca Release)**
+**Figure 1: ONAP Platform Architecture (Dublin Release)**
Figure 2 below, provides a simplified functional view of the architecture,
which highlights the role of a few key components:
-1. Design time environment for onboarding services and resources into ONAP and
+#. Design time environment for onboarding services and resources into ONAP and
designing required services.
-2. External API provides northbound interoperability for the ONAP Platform and
+#. External API provides northbound interoperability for the ONAP Platform and
Multi-VIM/Cloud provides cloud interoperability for the ONAP workloads.
-3. OOM provides the ability to manage cloud-native installation and deployments
- to Kubernetes-managed cloud environments.
-4. ONAP Common Services manages complex and optimized topologies. MUSIC allows
- ONAP to scale to multi-site environments to support global scale
+#. OOM provides the ability to manage cloud-native installation and
+ deployments to Kubernetes-managed cloud environments.
+#. ONAP Shared Services provides shared capabilities for ONAP modules. 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.
-5. Information Model and framework utilities continue to evolve to harmonize
+ Optimization. Logging provides centralized logging capabilities, Audit
+ (POMBA) provides capabilities to understand orchestration actions.
+#. ONAP shared utilities provide utilities for the support of the ONAP
+ components.
+#. Information Model and framework utilities continue to evolve 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.
+ ETSI NFV MANO, TM Forum SID, ONF Core, OASIS TOSCA, IETF, and MEF.
|image2|
**Figure 2. Functional view of the ONAP architecture**
-The Casablanca release has a number of important new features in the areas of
+The Dublin release has a number of important new features in the areas of
design time and runtime, ONAP installation, and S3P.
-Design time: The Service Design and Creation (SDC) project in ONAP has two new
-dashboards—DCAE design studio, SO Workflow Designer—to help designers, product
-managers, TechOps, and VNF owners create artifacts in one unified design
-palette.
+Design time: Dublin has evolved the controller design studio, as part of the
+controller framework, which enables a model driven approach for how an ONAP
+controller controls the network resources.
Runtime: Service Orchestration (SO) and controllers have new functionality to
support physical network functions (PNFs), reboot, traffic migration, expanded
@@ -148,65 +154,60 @@
automation and 5G use cases. With support for ETSI NFV-SOL003, the introduction
of an ETSI compliant VNFM is simplified.
-In the area of monitoring, analytics, and service assurance, ONAP has early
-support for the Linux Foundation PNDA project in DCAE as a compliment to CDAP.
-Next, the data collection framework can now collect real-time messages through
-a high-volume collector, handle PNFs, and support SNMP and bulk performance
-management data files. The Policy project supports a new policy engine as well
-as the new Casablanca blueprints and can distribute policies through policy
-design capabilities in SDC, simplifying the design process. Next, the Holmes
-alarm correlation engine features a new GUI and provides richer functionality
-through scripting, again simplifying how rapidly alarm correlation rules can be
-developed.
+To facilitate VNF vendor integration, ONAP introduced some mapper components
+that translate specific events (SNMP traps, telemetry, 3 GPP PM) towards ONAP
+VES standardized events.
-Moreover, there are new features in A&AI to support audit capabilities by
-providing historical data. ONAP northbound API continues to align better with
-TMForum (around ServiceOrder) and MEF APIs (around Legato and Interlude APIs)
-to simplify integration with OSS/BSS. The VID and UUI operations GUI projects
-can support a larger range of lifecycle management actions through a simple
-point and click interface allowing operators to perform more tasks with ease.
-Furthermore, The CLAMP project offers a new dashboard to view DMaaP and other
-events during design and runtime to ease the debugging of control-loop
-automation. ONAP has experimentally introduced ISTIO in certain components to
-progress the introduction of Service Mesh.
+The Policy project supports multiple policy engines and can distribute policies
+through policy design capabilities in SDC, simplifying the design process.
+Next, the Holmes alarm correlation engine continues to support a GUI
+functionality via scripting to simplify how rapidly alarm correlation rules can
+be developed.
+
+ONAP northbound API continues to align better with TM Forum APIs (Service
+Catalog, Service Inventory, Service Order and Hub API) and MEF APIs (around
+Legato and Interlude APIs) to simplify integration with OSS/BSS. The VID and
+UUI operations GUI projects can support a larger range of lifecycle management
+actions through a simple point and click interface allowing operators to
+perform more tasks with ease. Furthermore, The CLAMP project supports a
+dashboard to view DMaaP and other events during design and runtime to ease the
+debugging of control-loop automation. ONAP has experimentally introduced ISTIO
+in certain components to progress the introduction of Service Mesh.
ONAP installation: The ONAP Operations Manager (OOM) continues to make progress
in streamlining ONAP installation by using Kubernetes (Docker and Helm Chart
-technologies). In Casablanca, OOM supports pluggable persistent storage
-including GlusterFS, providing users with more storage options. In a multi-node
-deployment, OOM allows more control on the placement of services based on
-available resources or node selectors. Finally, OOM now supports backup/restore
-of an entire k8s deployment thus introducing data protection.
+technologies). OOM supports pluggable persistent storage including GlusterFS,
+providing users with more storage options. In a multi-node deployment, OOM
+allows more control on the placement of services based on available resources
+or node selectors. Finally, OOM now supports backup/restore of an entire k8s
+deployment thus introducing data protection.
-Casablanca has introduced the controller design studio, as part of the
-controller framework, which enables a model driven approach for how an ONAP
-controller controls the network resources.
+Deployability: Dublin continued the 7 Dimensions momentum (Stability, Security,
+Scalability, Performance; and Resilience, Manageability, and Usability) from
+the prior to the Beijing release. A new logging project initiative called Post
+Orchestration Model Based Audit (POMBA), can check for deviations between
+design and ops environments thus increasing network service reliability.
+Numerous other projects ranging from Logging, SO, VF-C, A&AI, Portal, Policy,
+CLAMP and MSB have a number of improvements in the areas of performance,
+availability, logging, move to a cloud-native architecture, authentication,
+stability, security, and code quality. Finally, versions of OpenDaylight and
+Kafka that are integrated into ONAP were upgraded to the Oxygen and v0.11
+releases providing new capabilities such as P4 and data routing respectively.
-Deployability: Casablanca continued the 7 Dimensions momentum (Stability,
-Security, Scalability, Performance; and Resilience, Manageability, and
-Usability) from the prior to the Beijing release. A new logging project
-initiative called Post Orchestration Model Based Audit (POMBA), can check for
-deviations between design and ops environments thus increasing network service
-reliability. Numerous other projects ranging from Logging, SO, VF-C, A&AI,
-Portal, Policy, CLAMP and MSB have a number of improvements in the areas of
-performance, availability, logging, move to a cloud native architecture,
-authentication, stability, security, and code quality. Finally, versions of
-OpenDaylight and Kafka that are integrated in ONAP were upgraded to the Oxygen
-and v0.11 releases providing new capabilities such as P4 and data routing
-respectively.
-
-3. Microservices Support
-========================
-
+Microservices Support
+=====================
As a cloud-native application that consists of numerous services, ONAP requires
-sophisticated initial deployment as well as post-deployment management.
+sophisticated initial deployment as well as post- deployment management.
The ONAP deployment methodology needs to be flexible enough to suit the
different scenarios and purposes for various operator environments. Users may
also want to select a portion of the ONAP components to integrate into their
own systems. And the platform needs to be highly reliable, scalable, secure and
easy to manage. To achieve all these goals, ONAP is designed as a
-microservices-based system, with all components released as Docker containers.
+microservices-based system, with all components released as Docker containers
+following best practice building rules to optimize their image size. To reduce
+the ONAP footprint, a first effort to use shared data base have been initiated
+with a Cassandra and mariadb-galera clusters.
The ONAP Operations Manager (OOM) is responsible for orchestrating the
end-to-end lifecycle management and monitoring of ONAP components. OOM uses
@@ -217,31 +218,33 @@
OOM is the lifecycle manager of the ONAP platform and uses the Kubernetes
container management system and Consul to provide the following functionality:
-1. Deployment - with built-in component dependency management (including
+#. Deployment - with built-in component dependency management (including
multiple clusters, federated deployments across sites, and anti-affinity
rules)
-2. Configuration - unified configuration across all ONAP components
-3. Monitoring - real-time health monitoring feeding to a Consul GUI and
+#. Configuration - unified configuration across all ONAP components
+#. 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
+#. Restart - failed ONAP components are restarted automatically
+#. Clustering and Scaling - cluster ONAP services to enable seamless scaling
+#. Upgrade - change out containers or configuration with little or no service
impact
-7. Deletion - clean up individual containers or entire deployments
+#. Deletion - clean up individual containers or entire deployments
OOM supports a wide variety of cloud infrastructures to suit your individual
requirements.
Microservices Bus (MSB) provides fundamental microservices supports including
-service registration/discovery, external API gateway, internal API gateway,
-client software development kit (SDK), and Swagger SDK. MSB supports both
-OpenStack (Heat) and bare metal deployment. When integrating with OOM, MSB has
-a Kube2MSB registrar which can grasp services information from k8s metafile and
-automatically register the services for ONAP components.
+service registration/ discovery, external API gateway, internal API gateway,
+client software development kit (SDK), and Swagger SDK. When integrating with
+OOM, MSB has a Kube2MSB registrar which can grasp services information from k8s
+metafile and automatically register the services for ONAP components.
-4. Portal
-=========
+In the spirit of leveraging the microservice capabilities, further steps
+towards increased modularity have been taken in the Dublin release. Service
+Orchestrator (SO) and the controllers have increased its level of modularity.
+Portal
+======
ONAP delivers a single, consistent user experience to both design time and
runtime environments, based on the user’s role. Role changes are configured
within a single ONAP instance.
@@ -251,7 +254,7 @@
shared, role-based menu or dashboard. The portal architecture provides
web-based capabilities such as application onboarding and management,
centralized access management through the Authentication and Authorization
-Framework, and dashboards, as well as hosted application widgets.
+Framework (AAF), 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
@@ -263,41 +266,45 @@
(including recipes for corrective/remedial action) using the ONAP Design
Framework Portal.
-5. Design-time Framework
-========================
-
+Design Time Framework
+=====================
The design time framework is a comprehensive development environment with
-tools, techniques, and repositories for defining/describing resources,
+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 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.
+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 two asset groups: Resource
-or Services.
+and policies. Each asset is categorized into one of four asset groups:
+Resource, Services, Products, or Offers. SDC also supports TOSCA1.3 List type
+definition in Dublin release which provides the ability to design complicated
+service descriptor.
+
The SDC environment supports diverse users via common services and utilities.
Using the design studio, product and service designers onboard/extend/retire
-resources and services. Operations, Engineers, Customer Experience Managers,
-and Security Experts create workflows, policies and methods to implement Closed
-control Loop Automation/Control and manage elastic scalability.
+resources, services and products. Operations, Engineers, Customer Experience
+Managers, and Security Experts create workflows, policies and methods to
+implement Closed control 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) 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. In addition, the testing capability of VNFSDK is being utilized at the LFN
-Compliance Verification Program to work towards ensuring a highly consistent
-approach to VNF verification.
+SDC. In addition, the testing capability of VNFSDK is being utilized at the
+LFN Compliance Verification Program to work towards ensuring a highly
+consistent approach to VNF verification.
The Policy Creation component deals with policies; these are rules, conditions,
requirements, constraints, attributes, or needs that must be provided,
@@ -309,50 +316,43 @@
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.
+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
-managing control loops. CLAMP is used to manage a closed control 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.
-
-6. Runtime Framework
-====================
-
+Runtime Framework
+=================
The runtime execution framework executes the rules and policies 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, Multi-Site State Coordination (MUSIC), which allow 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. The logging services also includes event based
-analysis capabilities to support post orchestration consistency analysis.
+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, Multi-Site State Coordination (MUSIC), which
+allow 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. The logging services also includes
+event-based analysis capabilities to support post orchestration consistency
+analysis.
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.
+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 various ONAP components, including Service
-Orchestrator, A&AI, and SDC. This provides an abstracted view of the platform
-within the existing BSS/OSS environment without lengthy, high-cost
-infrastructure integration. The Beijing release was 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.
+ONAP External APIs, North Bound Interface (NBI) module, exposes ONAP
+capabilities to OSS/BSS by currently implementing TM Forum APIs. In the
+previous Release, Casablanca, External APIs was already providing a set of
+serviceOrder, serviceInventory, serviceCatalog and event publish/subscribe
+serviceOrder notification management. For Dublin, External APIs is for the
+first time officially involved in two approved ONAP blueprints. One is
+BroadBand Service (BBS), the second one is Cross Domain and Cross Layer VPN
+(CCVPN).
The Virtual Infrastructure Deployment (VID) application enables users to
instantiate infrastructure services from SDC, along with their associated
@@ -361,7 +361,6 @@
Policy-Driven Workload Optimization
-----------------------------------
-
The ONAP Optimization Framework (OOF) provides a policy-driven and model-driven
framework for creating optimization applications for a broad range of use
cases. OOF Homing and Allocation Service (HAS) is a policy driven workload
@@ -374,17 +373,15 @@
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),
-cloud agnostic intent capabilities and real-time capacity checks provided by
+cloud agnostic Intent capabilities, 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). Operators now realize the true value of virtualization through fine
grained optimization of cloud resources while delivering performance and
-security SLAs. For the Beijing release, this feature was available for the vCPE
-use case.
+security SLAs.
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
@@ -397,22 +394,17 @@
physical COTS server infrastructure. VF-C provides a generic VNFM capability
but also integrates with external VNFMs and VIMs as part of an NFV MANO stack.
-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
---------
-
Active and Available Inventory (A&AI) provides real-time views of a system’s
-resources, services, products and their relationships with each other, and in
-Casablanca it 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.
+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
@@ -422,24 +414,26 @@
Multi Cloud Adaptation
----------------------
-
Multi-VIM/Cloud provides and infrastructure adaptation layer for VIMs/Clouds
in exposing advanced hardware platform awareness and 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 cloud agnostic intent capabilities are newly introduced in the
-Casablanca release.
+deployment.
-7. Closed Control Loop Automation
-=================================
-
-Closed loop control is provided by cooperation among a number of design time
-and runtime elements. The Runtime loop starts with Data Collection, Analytics
-and Events (DCAE) and then moves through the loop of micro-services like Holmes
-for event detection, Policy for determining actions, and finally controllers
-and orchestrators to implement actions CLAMP is used to monitor the loops
-themselves. CLAMP, Policy and DCAE all have design time aspects to support the
-creation of the loops.
+Closed Control Loop Automation
+==============================
+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 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 are moved through
+the loop of micro-services like Homes for event detection, Policy for
+determining actions, and finally, controllers and orchestrators to implement
+actions CLAMP is used to monitor the loops themselves. DCAE also supports
+(Platform for Network Data Analytics) PNDA analytics capabilities. 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
@@ -454,9 +448,8 @@
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. In the Casablanca Release, DCAE evolved to support new analytics
-capabilities with PNDA (http://pnda.io/) as well as new data collection
-capabilities with High Volume VES and bulk performance management support.
+for ONAP, new data collection capabilities with High Volume VES, and bulk
+performance management support.
Working with the Policy Framework and CLAMP, these components detect problems
in the network and identify the appropriate remediation. In some cases, the
@@ -470,10 +463,9 @@
**Figure 3: ONAP Closed Control Loop Automation**
-8. Common Services
-==================
-
-ONAP provides common operational services for all ONAP components including
+Shared Services
+===============
+ONAP provides a set of operational services for all ONAP components including
activity logging, reporting, common data layer, access control, secret and
credential management, resiliency, and software lifecycle management.
@@ -482,17 +474,16 @@
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
+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.
-9. ONAP Modeling
-================
-
+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 essential part for the design time and runtime framework
+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
@@ -500,45 +491,64 @@
among ONAP components and explore a common model to improve the
interoperability of ONAP.
-In the Casablanca Release, ONAP supports the following Models:
+In the Dublin Release, ONAP supports the following Models:
-- A VNF Descriptor 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 leveraging the ETSI NFV SOL004 specification.
-- A Network Service Descriptor (NSD) has been realized by the VFC (using the
- modelling project parsing capabilities).
+- 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 Network Service Descriptor (NSD) has been realized by the VFC (using the
+ modelling project parsing capabilities)
+- These models enable ONAP to interoperate with implementations based on
+ standards and improve industry collaboration.
-These models enable ONAP to interoperate with implementations based on
-standards, and improve the industry collaboration.
+In Dublin release, in addition to the parser library, modeling project
+introduced generic parser which provide the Tosca parser restful APIs for other
+projects as a standalone service.
-10. ONAP Blueprints
-===================
+Industry Alignment
+==================
+ONAP support and collaboration with other standards and opensource communities
+is evident in the architecture.
-ONAP can support an unlimited number of use cases. 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 Casablanca release, we
-introduced two new blueprints: 5G and CCVPN. Prior blueprints, vCPE, VoLTE and
-vFW/vDNS have been ported to Casablanca as well.
+- 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, SOL003 from
+ either the SO or VFC to an external VNFM).
+
+Read this whitepaper 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 is a multi-release effort, with Casablanca introducing first
-set of capabilities around PNF integration, edge automation, real-time
-analytics, network slicing, data modeling, homing, scaling, and network
-optimization. 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. brings with it some unique requirements. First, ONAP
-needs to support network services that include PNFs in addition to VNFs. Next
-ONAP needs to support edge cloud onboarding as network services will no longer
-be restricted to just large datacenters but will proliferate a large number of
-distributed edge locations. Finally, ONAP needs to collect real-time
-performance data for analytics and policy driven closed-loop automation. These
-requirements have led to several initiatives within ONAP to holistically address
-the 5G blueprint.
+The 5G blueprint is a multi-release effort, with three key initiatives around
+PNF integration, network optimization, and network slicing. 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. brings with it some unique requirements. First, 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. These requirements have led to the three
+above-listed initiatives. Between the Casablanca and Dublin releases, the 5G
+blueprint incorporates PNF integration, edge 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|
@@ -546,22 +556,21 @@
Read the 5G Blueprint to learn more.
-Virtual CPE Blueprint
----------------------
+Residential Connectivity Blueprints
+-----------------------------------
+Two ONAP blueprints (vCPE and BBS) address the residential connectivity use
+case.
-This blueprint addresses a residential use case, where the services offered to
-a subscriber are currently restricted to what is designed into the broadband
-residential gateway. In this blueprint, the customer has a slimmed down
-physical CPE (pCPE), that only consists of bridging functionality, attached to
-a traditional broadband network such as DSL or DOCSIS (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.
-ONAP supports complex orchestration and management of both virtual and underlay
-connectivity with two key components–SDN-C, which manages connectivity service
-, and APP-C, which manages virtualization services. In this case, ONAP provides
-a common service orchestration layer for the end-to-end service. This blueprint
-shows advanced functionality such as scaling, change management , HPA and cloud
-agnostic intent.
+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|
@@ -569,29 +578,44 @@
Read the Residential vCPE Use Case with ONAP blueprint to learn more.
-Voice over LTE (VoLTE) Blueprint
---------------------------------
-
-This blueprint uses ONAP to orchestrate a Voice over LTE service. This
-blueprint demonstrates how a Mobile Service Provider (SP) could deploy VoLTE
-services based on SDN/NFV. 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.
+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).
|image6|
-**Figure 6. ONAP VoLTE Architecture Open Network Automation Platform**
+**Figure 6. ONAP BBS Architecture**
-Read the VoLTE with ONAP blueprint to learn more.
+Read the Residential Connectivity Blueprint 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.
+
+|image7|
+
+**Figure 7. ONAP VoLTE Architecture Open Network Automation Platform**
+
+Read the VoLTE Blueprint to learn more.
CCVPN (Cross Domain and Cross Layer VPN) Blueprint
--------------------------------------------------
@@ -600,67 +624,64 @@
want to provide a high-speed, flexible and intelligent service for high-value
customers, and an instant and flexible VPN service for SMB companies.
-|image7|
+|image8|
-**Figure 7. ONAP CCVPN Architecture**
+**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. ONAP supports the CCVPN use case with
-several key components: SO, VF-C, SDN-C, Policy, Holmes and DCAE. 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.
+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.
-Read the CCVPN with ONAP blueprint to learn more.
+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
+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.
+Policy. In the Dublin release, the vFW blueprint has been demonstrated by
+using a mix of a CNF and VNF.
-Read the vFW/vDNS with ONAP blueprint 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.
-BBS (Broadband Service) Blueprint
----------------------------------
+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.
-The Broadband Service blueprint uses ONAP for the design, provisioning, life-cycle management and
-assurance of fixed broadband access services. In a first step, BBS blueprint works with multi-Gigabit
-Internet Connectivity services based on PON (Passive Optical Network access technology, and relies
-on the orchestration and automation capabilities provided by the ONAP platform to support new
-scenarios, such as the Nomadic ONT (see Figure 8).
+Resources
+=========
+Watch videos about the major platform components on
+`YouTube <https://www.youtube.com/channel/UCmzybjwmY1te0FHxLFY-Uog>`_ and
+`Youku <https://i.youku.com/i/UNTI4MjA5MDg5Ng==?spm=a2h1n.8251843.0.0>`_.
-|image8|
-
-**Figure 8. ONAP BBS Nomadic ONT Architecture**
-
-This blueprint shows the extensibility of the ONAP platform in supporting the orchestration of
-services across different location (e.g., Central Office, Core) and technology domains (e.g.,
-Access, Edge).
-
-In a joint collaboration with BBF (Broadband Forum) members, BBS implements and tests some of the
-specifications defined in the architectural framework of CloudCO (Cloud Central Office), Technical
-Report TR-384, among others. CloudCO aims at re-architecting the broadband network using SDN and NFV
-technologies and a cloud-like infrastructure deployed at Central Offices.
-
-The definition of External API capabilities supporting this use case also relies on TM Forum
-OpenAPIs and MEF LSO.
-
-BBS uses the following ONAP key components: ExternalAPI, SDC, SO, SDN-C, APEX policy engine and
-DCAE.
+Read about how ONAP can be deployed using containers.
.. |image1| image:: media/ONAP-toplevel.png
:width: 6.5in
@@ -677,11 +698,11 @@
.. |image5| image:: media/ONAP-vcpe.png
:width: 6.5in
:height: 3.28271in
-.. |image6| image:: media/ONAP-volte.png
+.. |image6| image:: media/ONAP-bbs.png
:width: 6.5in
:height: 3.02431in
-.. |image7| image:: media/ONAP-ccvpn.png
+.. |image7| image:: media/ONAP-volte.png
:width: 6.5in
:height: 3.02431in
-.. |image8| image:: media/ONAP-bbs.png
+.. |image8| image:: media/ONAP-ccvpn.png
:width: 6.5in
diff --git a/docs/guides/onap-developer/developing/index.rst b/docs/guides/onap-developer/developing/index.rst
index 4920187..13b22f9 100644
--- a/docs/guides/onap-developer/developing/index.rst
+++ b/docs/guides/onap-developer/developing/index.rst
@@ -246,6 +246,7 @@
:maxdepth: 2
:titlesonly:
+ ../../../submodules/policy/parent.git/docs/index
../../../submodules/policy/engine.git/docs/index
../../../submodules/policy/apex-pdp.git/docs/index
../../../submodules/policy/distribution.git/docs/index
diff --git a/docs/guides/onap-developer/settingup/nodeports.csv b/docs/guides/onap-developer/settingup/nodeports.csv
index 2e294d2..2fb6a2c 100644
--- a/docs/guides/onap-developer/settingup/nodeports.csv
+++ b/docs/guides/onap-developer/settingup/nodeports.csv
@@ -2,27 +2,23 @@
30200,VID,vid,8443,8443
30201,SDNC,sdnc-portal,8843,8843
30202,SDNC,sdnc-8282,8181,8282
-30203,SDNC,dgbuilder3,3100,3000
+30203,SDNC,dgbuilder,3100,3000
30204,SDC,sdc-be,8443,8443
-30205,SDC,sdc-be2,8080,8080
+30205,SDC,sdc-be,8080,8080
30206,SDC,sdc-fe,8181,8181
-30207,SDC,sdc-fe2,9443,9443
-30208,SDNC,sdnc-8202,8181,8202
-30209,ROBOT,httpd,88,88
+30207,SDC,sdc-fe,9443,9443
+30208,SDNC,sdnc-8202,8101,8202
+30209,ROBOT,httpd,8702,8702
30210,AAI,aai-modelloader,8080,8080
30211,APPC,appc-9090,9191,9090
30212,PORTAL,portal-sdk,8080,8080
-30213,PORTAL,portal-app2,8005,8006
+30213,PORTAL,portal-app,8005,8006
30214,PORTAL,portal-app3,8009,8010
30215,PORTAL,portal-app,8080,8989
-30216,POLICY,brmsgw,9989,9989
-30217,POLICY,drools-6969,6969,6969
30218,POLICY,pap-9091,9091,9091
30219,POLICY,pap-8443,8443,8443
-30220,AAI,aai-sparky-be,9517,9517
-30221,POLICY,drools-9696,9696,9696
-30222,DCAE,xdcae-hv-ves-collector,6061,6061
-30223,DCAE,xdcae-datafile-collector,8100,8100
+30220,AAI,aai-sparky-be,8000,8000
+30222,DCAE,xport-t-6061,6061,6061
30224,SO,so-monitor-port,9091,9091
30225,PORTAL,portal-app4,8443,8443
30226,DMAAP,message-router-3905,3905,3905
@@ -31,34 +27,24 @@
30229,AAI,aai-modelloader-ssl,8443,8443
30230,APPC,appc-8282,8181,8282
30231,APPC,appc-1830,1830,1830
-30232,AAI,aai,8080,8080
30233,AAI,aai-ssl,8443,8443
30234,POMBA,pomba-kibana,5601,5601
-30235,DCAE,xdcae-ves-collector,8080,8080
-30236,POLICY,nexus,8081,8081
-30237,POLICY,policy-apex-pdp,12345,12345
+30235,DCAE,xport-t-8080,8080,8080
30238,VID,vid-http,8080,8080
30239,AAI,spike,9518,9518
30241,DMAAP,dmaap-bc,8080,8080
30242,DMAAP,dmaap-bc2,8443,8443
-30243,AAF,aaf-sms,10443,10443
-30244,AAF,aaf-sms-db,8200,8200
30246,SDNC,sdnc-8280,8080,8280
-30247,AAF,aaf-service,8100,8100
-30248,OOF,oof-osdf,8699,8698
+30248,OOF,oof-has-api,8699,8698
30249,POMBA,pomba-data-router,9502,9502
-30251,AAF,aaf-gui,8200,8200
-30252,SO,mariadb,3306,3306
30253,LOG,log-kibana,5601,5601
30254,LOG,log-es,9200,9200
30255,LOG,log-ls,5044,5044
30256,SDC,sdc-wfd-fe,8080,8080
30257,SDC,sdc-wfd-be,8080,8080
-30258,CLAMP,clamp2,8443,8443
+30258,CLAMP,clamp,8443,8443
30259,DMAAP,dmaap-dr-prov,8080,8080
-30260,CLI,cli8080,80,80
-30261,MULTICLOUD,multicloud-azure,9008,9008
-30262,DCAE,xdcae-datafile-collector,8433,8443
+30260,CLI,cli8080,8443,8080
30263,DCAE,dcae-fe,8183,8183
30264,DCAE,dcae-fe2,9444,9444
30265,DCAE,dcae-dt,8186,8186
@@ -68,33 +54,47 @@
30269,DMAAP,dmaap-dr-prov2,8443,8443
30270,CONSUL,consul-ui,8500,8500
30271,CLI,cli9090,8080,9090
-30274,EXTAPI,api-8080,8080,8080
+30274,API,api-8080,8080,8080
30275,OOF,oof-has-api,8091,8091
30277,SO,so-apih-port,8080,8080
30278,AAI,aai-champ,9522,9522
30279,AAI,babel,9516,9516
-30280,MSB,http-msb-iag,80,80
+30280,MSB,http-msb-iag,443,443
30281,MSB,http-msb-discovery,10081,10081
-30282,MSB,http-msb-eag,80,80
+30282,MSB,http-msb-eag,10081,10081
30283,MSB,https-msb-iag,443,443
30284,MSB,https-msb-eag,443,443
30285,MSB,http-msb-consul,8500,8500
30286,DCAE,client,6379,6379
30287,DCAE,gossip,16379,16379
-30288,SNRIRO,httpd,80,80
-30289,APPC,appc-cdt,80,80
+30289,APPC,appc-cdt,18080,18080
30290,CLAMP,cdash-kibana,5601,5601
-30291,MULTICLOUD,multicloud-framework,9001,9001
-30292,MULTICLOUD,multicloud-vio,9004,9004
-30293,MULTICLOUD,multicloud-ocata,9006,9006
-30294,MULTICLOUD,multicloud-titaniumcloud,9005,9005
-30295,CLAMP,clamp,8080,8080
-30296,MULTICLOUD,multicloud-pike,9007,9007
30297,VNFSDK,refrepo,8702,8702
+30299,POMBA,https,8443,9531
30398,UUI,uui,8080,8080
30399,UUI,uui-server,8082,8082
-30420,CONTRIB,netbox-nginx,8080,8080
+30406,SO,so-vnfm-port,9092,9092
+30415,DCAE,config-binding-service,10000,10000
+30417,DCAE,xport-t-8443,8443,8443
+30418,DCAE,xport-t-8080,8080,8080
+30419,DCAE,xport-t-8443,8443,8443
+30420,API,api-8080,8080,8080
+30431,SDC,sdc-wfd-fe2,8443,8443
+30470,DCAE,xport-u-6162,6162,6162
30476,DCAE,tomcat,8080,8080
-32010,DCAE,xdcae-tca-analytics,11011,11011
-
-
+30490,DMAAP,message-router-kafka-0,9093,9093
+30491,DMAAP,message-router-kafka-1,9093,9093
+30492,DMAAP,message-router-kafka-1,9093,9093
+30493,DMAAP,dmaap-dr-node,8080,8080
+30494,DMAAP,dmaap-dr-node,8443,8443
+30497,CDS,cds-ui-3000,3000,3000
+30499,CDS,blueprints-processor-http,8080,8080
+31110,AAF,aaf-service,8100,8100
+31111,AAF,aaf-locate,8095,8095
+31112,AAF,aaf-oauth,8140,8140
+31113,AAF,aaf-hello,8200,8200
+31114,AAF,aaf-cm,8150,8150
+31115,AAF,aaf-hello,8096,8096
+31116,AAF,aaf-hello,8130,8130
+31907,DMAAP,dmaap-dr-prov2,5000,5000
+32010,DCAE,xport-t-11011,11011,11011
diff --git a/docs/guides/onap-user/design/pre-onboarding/index.rst b/docs/guides/onap-user/design/pre-onboarding/index.rst
index 155ec56..7a09f0d 100644
--- a/docs/guides/onap-user/design/pre-onboarding/index.rst
+++ b/docs/guides/onap-user/design/pre-onboarding/index.rst
@@ -2,6 +2,8 @@
.. International License. http://creativecommons.org/licenses/by/4.0
.. Copyright 2019 ONAP Contributors. All rights reserved.
+.. _doc_guide_user_des_pre-onb:
+
Pre-Onboarding
==============
diff --git a/docs/guides/onap-user/design/resource-onboarding/index.rst b/docs/guides/onap-user/design/resource-onboarding/index.rst
index 4a3cbc1..592651e 100644
--- a/docs/guides/onap-user/design/resource-onboarding/index.rst
+++ b/docs/guides/onap-user/design/resource-onboarding/index.rst
@@ -2,6 +2,8 @@
.. International License. http://creativecommons.org/licenses/by/4.0
.. Copyright 2019 ONAP Contributors. All rights reserved.
+.. _doc_guide_user_des_res-onb:
+
Resource Onboarding
===================
**Goal:** Add models and other artifacts required to create, configure, instantiate, and manage a VF and, optionally, a VFC.
diff --git a/docs/guides/onap-user/design/service-design/index.rst b/docs/guides/onap-user/design/service-design/index.rst
index dcc6b9c..83217bd 100644
--- a/docs/guides/onap-user/design/service-design/index.rst
+++ b/docs/guides/onap-user/design/service-design/index.rst
@@ -2,6 +2,8 @@
.. International License. http://creativecommons.org/licenses/by/4.0
.. Copyright 2019 ONAP Contributors. All rights reserved.
+.. _doc_guide_user_des_ser-des:
+
Service Design
==============
@@ -30,7 +32,7 @@
Create a Service
----------------
-**Prerequisites:** Create VFs required for this service (see :ref:`vfcreation-and-testing`).
+**Prerequisites:** Create VFs required for this service (see :ref:`doc_guide_user_des_vf-cre`).
#. From the SDC HOME page, hover over Add and select Add Service.
#. In the General section, complete all fields.
diff --git a/docs/guides/onap-user/design/service-distribution/index.rst b/docs/guides/onap-user/design/service-distribution/index.rst
index 4ed2310..8de0e92 100644
--- a/docs/guides/onap-user/design/service-distribution/index.rst
+++ b/docs/guides/onap-user/design/service-distribution/index.rst
@@ -2,6 +2,8 @@
.. International License. http://creativecommons.org/licenses/by/4.0
.. Copyright 2019 ONAP Contributors. All rights reserved.
+.. _doc_guide_user_des_ser-dis:
+
Governance Approval and Service Distribution
============================================
diff --git a/docs/guides/onap-user/design/vfcreation/index.rst b/docs/guides/onap-user/design/vfcreation/index.rst
index 3913066..0b49b99 100644
--- a/docs/guides/onap-user/design/vfcreation/index.rst
+++ b/docs/guides/onap-user/design/vfcreation/index.rst
@@ -2,7 +2,7 @@
.. International License. http://creativecommons.org/licenses/by/4.0
.. Copyright 2019 ONAP Doc Team. All rights reserved.
-.. _vfcreation-and-testing:
+.. _doc_guide_user_des_vf-cre:
VF Creation and Testing
=======================
diff --git a/docs/guides/overview/overview.rst b/docs/guides/overview/overview.rst
index 83c7e9d..fc45705 100644
--- a/docs/guides/overview/overview.rst
+++ b/docs/guides/overview/overview.rst
@@ -152,7 +152,9 @@
+----------------------+----------------+----------------------+-----------------------------------------------------------+
|Release Name |Release version |Release Date |Features delivered |
+======================+================+======================+===========================================================+
-|Casablanca |* 3.0.2 |* 31 January 2019 | :ref:`Casablanca Release Notes <casablancarelease-notes>` |
+|Dublin |4.0.0 |2019 | :ref:`Dublin Release Notes <dublinrelease-notes>` |
++----------------------+----------------+----------------------+-----------------------------------------------------------+
+|Casablanca |* 3.0.2 |* 31 January 2019 | |
| |* 3.0.1 |* 30 November 2018 | |
| |* 3.0.0 |* 15 April 2019 | |
+----------------------+----------------+----------------------+-----------------------------------------------------------+
diff --git a/docs/index.rst b/docs/index.rst
index 9902db9..fc772b8 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -23,6 +23,9 @@
+---------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------+
| Main documentation areas | Description |
+=================================================================================+===============================================================================================+
+ | :ref:`Release Notes <dublinrelease-notes>` | The Release Notes besides providing the basic information on the main release, also |
+ | | presents link to the release information of each, specific ONAP component. |
+ +---------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------+
| :ref:`ONAP Overview <overview>` | ONAP Overview provides generic and high-level guidance on the mission and main |
| | functionalities of ONAP. Basic guidelines on license details, limitations and |
| | security references support understanding the solution. |
@@ -62,8 +65,8 @@
:hidden:
Home <self>
- guides/overview/index
release/index
+ guides/overview/index
guides/onap-developer/architecture/index
guides/onap-developer/developing/index
guides/onap-developer/settingup/index
diff --git a/docs/release/index.rst b/docs/release/index.rst
index c3bcba2..99b1400 100644
--- a/docs/release/index.rst
+++ b/docs/release/index.rst
@@ -2,7 +2,7 @@
International License. http://creativecommons.org/licenses/by/4.0
-.. _casablancarelease-notes:
+.. _dublinrelease-notes:
Dublin Release Notes
^^^^^^^^^^^^^^^^^^^^
@@ -11,8 +11,7 @@
outstanding trouble reports.
Release notes are cumulative for the release, meaning this release note for the Dublin release will have an entry for each Major, Minor, and Maintenance
-release, if applicable. Information that is applicable regardless of release is included in the `Getting Started With ONAP`_ section of this
-document.
+release, if applicable.
Each component within the ONAP solution maintains their own component level release notes and links to those release notes are provided below.
Details on the specific items delivered in each releaese by each component is maintained in the component specific release notes.
@@ -26,98 +25,6 @@
The Dublin 4.0.0 is the first release for Dublin.
-.. _getting-started:
-
-Getting Started With ONAP
-=========================
-
-Summary
--------
-ONAP provides a comprehensive platform for real-time, policy-driven
-service orchestration and automation including virtual network functions and
-applications instantiation and configuration, but also physical network
-functions configuration.
-ONAP will enable software, network, IT and cloud providers and developers
-to rapidly automate new services and support complete life cycle 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.
-
-Functionality
--------------
-**Portal** - a single, consistent user experience for both design time
-and run time environments, based on the user’s role.
-
-**Design Time Framework** - a comprehensive development environment with
-tools, techniques, and repositories for defining/describing resources,
-and services:
-
- - Service Design and Creation (SDC) provides tools, techniques, and
- repositories to define/simulate/certify system assets as well as their
- associated processes and policies.
-
- - A VNF Software Development Kit (VNFSDK) and VNF Validation Program (VVP)
- with tools for VNF supplier packaging and validation.
-
- - Policy Creation (POLICY) deals with conditions, requirements,
- constraints, attributes, or needs that must be provided, maintained,
- and/or enforced.
-
- - Closed Loop Automation Management Platform (CLAMP) provides a method
- for designing and managing control loops.
-
- - Optimization Framework (OOF) provides a policy-driven and model-driven
- framework for creating optimization applications.
-
-**Runtime Framework** - The runtime execution framework executes the
-rules and policies distributed by the design and creation environment
-and Controllers that manage resources corresponding to their assigned
-controlled domain:
-
- - Service Orchestrator (SO) executes the specified BPMN 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. SO is especially able to drive
- any OpenStack-based cloud platform.
-
- - Software Defined Network Controller (SDNC) executes network configuration
- for cloud computing resources and network.
-
- - Application Controller (APPC) executes Virtual Network Functions (VNF)
- configurations and lifecycle management operations.
-
- - Virtual Function Controller (VF-C) is responsible for lifecycle management
- of virtual network functions and network services based on VNF using
- VNF Manager.
-
- - Active and Available Inventory (A&AI) provides real-time views of a
- system’s resources, services, products and their relationships with each
- other.
-
-**Closed-Loop Automation** -- Design -> Create -> Collect -> Analyze >
-Detect -> Publish -> Respond:
-
- - Data Collection, Analytics and Events (DCAE) collects events, performance,
- usage and publishes information to policy that executes the rules to perform
- closed loop actions.
-
- - Holmes provides alarm correlation and analysis for Telecom cloud
- infrastructure and services, including servers, cloud infrastructure,
- VNFs and Network Services.
-
- - Common Services - operational services for all ONAP components including
- activity logging, reporting, common data layer, access control, resiliency,
- multisite state coordination, credential/secret management and
- software lifecycle management.
-
-**Microservices Support**
-
- - ONAP Operation Manager (OOM) use Kubernetes and Helm to manage ONAP components.
- - Microservices Bus (MSB) provides service registration/discovery,
- external API gateway, internal API gateway, client software development kit
- (SDK), and Swagger SDK.
-
Project Specific Release Notes
==============================
ONAP releases are specified by a list of project artifact versions in a :ref:`manifest artifacts <doc-release-manifest-artifacts>`
@@ -133,30 +40,13 @@
and prepends to these if/when any updated versions the project team believes
are compatible with a major release are made available.
-.. index:: Download
-
-Installation
-============
-ONAP is installed using :ref:`ONAP Operations Manager (OOM) over Kubernetes<installing-onap>`
-
Documentation
=============
-ONAP Dublin Release provides multiple documents including the following:
+ONAP Dublin Release provides multiple documents, see :ref:`ONAP Home<master_index>`.
- * A high level :ref:`architecture view<doc-architecture>` of how component
- relate to each other.
-
- * A collection of documentation provided
- by :ref:`each project <doc_onap-developer_guide_projects>`.
-
- * Application Programming Interface
- Reference :ref:`available here <doc-apiref>`.
-
- * The `developer wiki <http://wiki.onap.org>`_ remains a good source of
- information on meeting plans and notes from committees, project teams and
- community events.
-
-.. index:: Licensing
+The `developer wiki <http://wiki.onap.org>`_ remains a good source of
+information on meeting plans and notes from committees, project teams and
+community events.
Security Notes
==============
@@ -176,12 +66,6 @@
The Integration team ran the 72 hours stability testing (100% passing rate) and full resilience testing (96.9% passing rate) at ONAP OpenLabs. More details in :ref:`ONAP Maturity Testing Notes <integration-s3p>`
-Licenses
-========
-ONAP Source Code is licensed under the `Apache Version 2 License <http://www.apache.org/licenses/LICENSE-2.0>`_.
-ONAP Documentation is licensed under the `Creative Commons Attribution 4.0
-International License <http://creativecommons.org/licenses/by/4.0>`_.
-
Known Issues and Limitations
============================
Known Issues and limitations are documented in each :ref:`project Release Notes <doc-releaserepos>`.
diff --git a/docs/release/releaserepos.rst b/docs/release/releaserepos.rst
index 4beabfe..f9ece9f 100644
--- a/docs/release/releaserepos.rst
+++ b/docs/release/releaserepos.rst
@@ -196,7 +196,7 @@
:maxdepth: 1
:titlesonly:
- policy<../submodules/policy/engine.git/docs/release-notes.rst>
+ policy<../submodules/policy/parent.git/docs/release-notes.rst>
Portal Platform
---------------
diff --git a/docs/submodules/aaf/authz.git b/docs/submodules/aaf/authz.git
index a47bd51..dbec475 160000
--- a/docs/submodules/aaf/authz.git
+++ b/docs/submodules/aaf/authz.git
@@ -1 +1 @@
-Subproject commit a47bd51641efcb84e19d68a6383f0947df826636
+Subproject commit dbec47530c91b6cd586fb05b44fd27444301e04a
diff --git a/docs/submodules/aaf/sms.git b/docs/submodules/aaf/sms.git
index c0b515d..3984c30 160000
--- a/docs/submodules/aaf/sms.git
+++ b/docs/submodules/aaf/sms.git
@@ -1 +1 @@
-Subproject commit c0b515db857565a259d99a14cd71b58e5d7e8ecc
+Subproject commit 3984c30f5aefca231fdec735ab04cae7bddccd81
diff --git a/docs/submodules/aai/aai-common.git b/docs/submodules/aai/aai-common.git
index 1bef250..2f81c9e 160000
--- a/docs/submodules/aai/aai-common.git
+++ b/docs/submodules/aai/aai-common.git
@@ -1 +1 @@
-Subproject commit 1bef250998b7f5bf628b099dd55235ba0f30e003
+Subproject commit 2f81c9e500cc5d260a66ea70de8397d0c824f67e
diff --git a/docs/submodules/appc/deployment.git b/docs/submodules/appc/deployment.git
index 6919392..23299c9 160000
--- a/docs/submodules/appc/deployment.git
+++ b/docs/submodules/appc/deployment.git
@@ -1 +1 @@
-Subproject commit 6919392881a94fa9823e5ebf8748682a4c499e98
+Subproject commit 23299c969a313f8e3740bceb070655810f5e3efb
diff --git a/docs/submodules/ccsdk/cds.git b/docs/submodules/ccsdk/cds.git
index f40ed23..3fa6fd4 160000
--- a/docs/submodules/ccsdk/cds.git
+++ b/docs/submodules/ccsdk/cds.git
@@ -1 +1 @@
-Subproject commit f40ed23775d6ea00c414c89959dd478a5f30437f
+Subproject commit 3fa6fd4c5a9f6bf5ca522b7dffe07c77626e6403
diff --git a/docs/submodules/ccsdk/dashboard.git b/docs/submodules/ccsdk/dashboard.git
index fd5048d..c0d9bbc 160000
--- a/docs/submodules/ccsdk/dashboard.git
+++ b/docs/submodules/ccsdk/dashboard.git
@@ -1 +1 @@
-Subproject commit fd5048d6050207cc60ac5155a9a6c87a182fb524
+Subproject commit c0d9bbcaa3a1b9d990f6658953523b177c488ad9
diff --git a/docs/submodules/ccsdk/distribution.git b/docs/submodules/ccsdk/distribution.git
index 8d44678..6c62b73 160000
--- a/docs/submodules/ccsdk/distribution.git
+++ b/docs/submodules/ccsdk/distribution.git
@@ -1 +1 @@
-Subproject commit 8d4467847a7992c1525555a3f43599b195a0bf08
+Subproject commit 6c62b73ce21b351cd4d8ce2054fa0e42e4085620
diff --git a/docs/submodules/ccsdk/platform/plugins.git b/docs/submodules/ccsdk/platform/plugins.git
index 906f5e2..d206b39 160000
--- a/docs/submodules/ccsdk/platform/plugins.git
+++ b/docs/submodules/ccsdk/platform/plugins.git
@@ -1 +1 @@
-Subproject commit 906f5e2dc9b12074a12b69cc874056ef4a185dcc
+Subproject commit d206b39f669ff86e469918ef1db5d3e75f4d18d4
diff --git a/docs/submodules/ccsdk/utils.git b/docs/submodules/ccsdk/utils.git
index 950f9e1..e50b344 160000
--- a/docs/submodules/ccsdk/utils.git
+++ b/docs/submodules/ccsdk/utils.git
@@ -1 +1 @@
-Subproject commit 950f9e1ca067c45ba74933030ebf715206bb6017
+Subproject commit e50b344c0491e313c0fff96b37f673388d87cad2
diff --git a/docs/submodules/clamp.git b/docs/submodules/clamp.git
index 2cca1c8..943d7b2 160000
--- a/docs/submodules/clamp.git
+++ b/docs/submodules/clamp.git
@@ -1 +1 @@
-Subproject commit 2cca1c820e38b45879abe1c82ce994283a55818c
+Subproject commit 943d7b2c32d7527cd018cd27f97f1b12a21b8989
diff --git a/docs/submodules/dcaegen2.git b/docs/submodules/dcaegen2.git
index d20ca31..bb8dea8 160000
--- a/docs/submodules/dcaegen2.git
+++ b/docs/submodules/dcaegen2.git
@@ -1 +1 @@
-Subproject commit d20ca31bb588ac665566df777363973257218819
+Subproject commit bb8dea8255097e9cd306d8f02f945bfb684e469b
diff --git a/docs/submodules/dmaap/datarouter.git b/docs/submodules/dmaap/datarouter.git
index 3ebd253..52c5c5a 160000
--- a/docs/submodules/dmaap/datarouter.git
+++ b/docs/submodules/dmaap/datarouter.git
@@ -1 +1 @@
-Subproject commit 3ebd2534167e73426d2b19efb05eaf9892f6f9d6
+Subproject commit 52c5c5ab9ba33755e26f06f41de608f825866a53
diff --git a/docs/submodules/externalapi/nbi.git b/docs/submodules/externalapi/nbi.git
index 6413a21..bce9428 160000
--- a/docs/submodules/externalapi/nbi.git
+++ b/docs/submodules/externalapi/nbi.git
@@ -1 +1 @@
-Subproject commit 6413a21daa01e4ff25fad4f49bc35b01cb98a1a7
+Subproject commit bce9428824803a9f2b03975c7238e52974ec31b2
diff --git a/docs/submodules/integration.git b/docs/submodules/integration.git
index e84c265..c591244 160000
--- a/docs/submodules/integration.git
+++ b/docs/submodules/integration.git
@@ -1 +1 @@
-Subproject commit e84c265f95d046c8514dbb0091dec873e912d8bc
+Subproject commit c5912441be45787488574369e629bc63a9e65dd9
diff --git a/docs/submodules/oom.git b/docs/submodules/oom.git
index 5a9e258..56bc782 160000
--- a/docs/submodules/oom.git
+++ b/docs/submodules/oom.git
@@ -1 +1 @@
-Subproject commit 5a9e258c78a80fa1df9f8b2fbfa08ccacec53b18
+Subproject commit 56bc782c22235987a27f3061799b8e859fffafb2
diff --git a/docs/submodules/oom/offline-installer.git b/docs/submodules/oom/offline-installer.git
index d93b67d..f45f73f 160000
--- a/docs/submodules/oom/offline-installer.git
+++ b/docs/submodules/oom/offline-installer.git
@@ -1 +1 @@
-Subproject commit d93b67d0dc46c9c7a43807de5ca4106d7e3e32dc
+Subproject commit f45f73f749fffb301d825ec53fae2878c505980d
diff --git a/docs/submodules/optf/cmso.git b/docs/submodules/optf/cmso.git
index cc67f22..6df50b9 160000
--- a/docs/submodules/optf/cmso.git
+++ b/docs/submodules/optf/cmso.git
@@ -1 +1 @@
-Subproject commit cc67f224925c03f50ce47068cbde66799c65e3a0
+Subproject commit 6df50b96c77bd6402ea4bd7f1a84de6233549cdf
diff --git a/docs/submodules/optf/osdf.git b/docs/submodules/optf/osdf.git
index a3439d6..95bd3e4 160000
--- a/docs/submodules/optf/osdf.git
+++ b/docs/submodules/optf/osdf.git
@@ -1 +1 @@
-Subproject commit a3439d6e4ae7b518484a589abebc761122a336bf
+Subproject commit 95bd3e4710787de7488be24913f708cf539a577a
diff --git a/docs/submodules/policy/apex-pdp.git b/docs/submodules/policy/apex-pdp.git
index 4b890c7..a9a3a5d 160000
--- a/docs/submodules/policy/apex-pdp.git
+++ b/docs/submodules/policy/apex-pdp.git
@@ -1 +1 @@
-Subproject commit 4b890c78baa7e6ea42a02e140e608491ccb0aa63
+Subproject commit a9a3a5d23130bdd652da64d0297cf00081b085d7
diff --git a/docs/submodules/policy/engine.git b/docs/submodules/policy/engine.git
index 2c533a5..81db61d 160000
--- a/docs/submodules/policy/engine.git
+++ b/docs/submodules/policy/engine.git
@@ -1 +1 @@
-Subproject commit 2c533a581179c1c06c8811b6dda57e8a6d0fbd2c
+Subproject commit 81db61d122e8176bc7237f149d7815bf4979ed97
diff --git a/docs/submodules/policy/parent.git b/docs/submodules/policy/parent.git
index d8d3191..4d1d983 160000
--- a/docs/submodules/policy/parent.git
+++ b/docs/submodules/policy/parent.git
@@ -1 +1 @@
-Subproject commit d8d3191510be75033894d41439dc92ba250eeda5
+Subproject commit 4d1d9830d51d3df59cadaa0ac9c9b004f2cb0d17
diff --git a/docs/submodules/portal.git b/docs/submodules/portal.git
index ba546e9..40c8f07 160000
--- a/docs/submodules/portal.git
+++ b/docs/submodules/portal.git
@@ -1 +1 @@
-Subproject commit ba546e970d779a5e87a07b3058a85e1446c39129
+Subproject commit 40c8f073970f3664786d1bb4d4c69ed3f57b8b45
diff --git a/docs/submodules/sdc.git b/docs/submodules/sdc.git
index ddb67dc..7c62480 160000
--- a/docs/submodules/sdc.git
+++ b/docs/submodules/sdc.git
@@ -1 +1 @@
-Subproject commit ddb67dc3cbb04f4857f2cf24221b306fa2bab052
+Subproject commit 7c62480edb52c829102cddd030384176bf16780b
diff --git a/docs/submodules/sdnc/oam.git b/docs/submodules/sdnc/oam.git
index d62222b..9d188ef 160000
--- a/docs/submodules/sdnc/oam.git
+++ b/docs/submodules/sdnc/oam.git
@@ -1 +1 @@
-Subproject commit d62222b32cb04696dd11917f893397a01c3ba49f
+Subproject commit 9d188efd67fe81b7e9b190afd8858eb042b813ac
diff --git a/docs/submodules/so.git b/docs/submodules/so.git
index c1cd5ef..11b69a4 160000
--- a/docs/submodules/so.git
+++ b/docs/submodules/so.git
@@ -1 +1 @@
-Subproject commit c1cd5ef428017bc26513395a3bfc00caf7209f8a
+Subproject commit 11b69a4a70a70b8eb5b9216ae3f4360e651f12b3
diff --git a/docs/submodules/usecase-ui.git b/docs/submodules/usecase-ui.git
index 4fa6adb..53eb419 160000
--- a/docs/submodules/usecase-ui.git
+++ b/docs/submodules/usecase-ui.git
@@ -1 +1 @@
-Subproject commit 4fa6adb91b4a31cd26d24d834477a1fa94d2a83d
+Subproject commit 53eb419c84adf52c321883bf33af949016a9db2a
diff --git a/docs/submodules/vfc/nfvo/driver/vnfm/svnfm.git b/docs/submodules/vfc/nfvo/driver/vnfm/svnfm.git
index 045656e..451e015 160000
--- a/docs/submodules/vfc/nfvo/driver/vnfm/svnfm.git
+++ b/docs/submodules/vfc/nfvo/driver/vnfm/svnfm.git
@@ -1 +1 @@
-Subproject commit 045656e9d2178f5dfbc14061f4b3edd8e6d7fe1d
+Subproject commit 451e015794a0f3957c9d02685f622817914b4124
diff --git a/docs/submodules/vfc/nfvo/lcm.git b/docs/submodules/vfc/nfvo/lcm.git
index 83f5eaa..b8546fe 160000
--- a/docs/submodules/vfc/nfvo/lcm.git
+++ b/docs/submodules/vfc/nfvo/lcm.git
@@ -1 +1 @@
-Subproject commit 83f5eaad87d82ecc398653f0fd8335ce8d1dbfe8
+Subproject commit b8546fe945ca287d9095b5513fe1f1f5fbb481b1
diff --git a/docs/submodules/vid.git b/docs/submodules/vid.git
index e3c3ba0..e0c59bc 160000
--- a/docs/submodules/vid.git
+++ b/docs/submodules/vid.git
@@ -1 +1 @@
-Subproject commit e3c3ba0dc33afe638cd1cade06331b1c5d379295
+Subproject commit e0c59bc9b16bb69f0f0a47268742c9f030aa3aa6
diff --git a/docs/submodules/vnfrqts/requirements.git b/docs/submodules/vnfrqts/requirements.git
index 83003c3..ad0e89a 160000
--- a/docs/submodules/vnfrqts/requirements.git
+++ b/docs/submodules/vnfrqts/requirements.git
@@ -1 +1 @@
-Subproject commit 83003c307c92f8d240d9e894a4cfeb4ee278b82a
+Subproject commit ad0e89a88920277386971e7945ede8bab0503967
