1. Introduction
===============
-The ONAP project addresses a rising need for a common platform for
-telecommunication, cable, and cloud operators—and their solution
-providers—to deliver differentiated network services on demand,
-profitably and competitively, while leveraging existing investments.
-
-Prior to ONAP, operators of large networks have been challenged to keep
-up with the scale and cost of manual changes required to implement new
-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 Northbound REST APIs that are open and
-interoperable, and by supporting YANG and TOSCA data models. ONAP’s
-modular and layered nature improves interoperability and simplifies
-integration, allowing it to support multiple VNF environments by
-integrating with multiple VIMs, VNFMs, SDN Controllers, and even legacy
-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. ONAP exists to instantiate and operate VNFs. Typical
-operator networks are expected to support multiple instances of hundreds
-of different types of VNFs. ONAP’s consolidated VNF requirements
-publication is a significant deliverable to enable commercial
-development of ONAP-compliant VNFs.
+The ONAP 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.
+
+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.
The ONAP platform allows end user organizations and their network/cloud
-providers to collaboratively instantiate network elements and services
-in a dynamic, closed-loop process, with real-time response to actionable
-events. In order to design, engineer, plan, bill and assure these
-dynamic services, there are three major requirements:
+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:
-- 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.
+- 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.
- 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.
+ 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.
+- 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. It leverages
-cloud-native technologies including Kubernetes to manage and rapidly
-deploy the ONAP platform and related components. This is in stark
-contrast to traditional OSS/Management software platform architectures,
-which hardcoded services and technologies, and required lengthy software
-development and integration cycles to incorporate changes.
-
-The ONAP Platform enables product/service independent capabilities for
-design, creation and lifecycle management, in accordance with the
-following foundational principles:
+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. It leverages cloud-native technologies including Kubernetes
+to manage and rapidly deploy the ONAP platform and related components. This is
+in stark contrast to traditional OSS/Management software platform
+architectures, which hardcoded services and technologies, and required lengthy
+software development and integration cycles to incorporate changes.
+
+The ONAP Platform enables product/service independent capabilities for design,
+creation and lifecycle management, in accordance with the following
+foundational principles:
- Ability to dynamically introduce full service lifecycle orchestration
- (design, provisioning and operation) and service API for new services
- & technologies without the need for new platform software releases or
- without affecting operations for the existing services.
-
-- Carrier-grade scalability including horizontal scaling (linear
- scale-out) and distribution to support large number of services and
- large networks.
-
+ (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.
-
-**Figure 1: ONAP Platform**
-
-|image0|
+ 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
2. ONAP Architecture
====================
-The platform provides the common functions (e.g., data collection,
-control loops, metadata recipe creation, policy/recipe distribution,
-etc.) necessary to construct specific behaviors. To create a service or
-operational capability, it is necessary to develop
-service/operations-specific service definitions, data collection,
-analytics, and policies (including recipes for corrective/remedial
-action) using the ONAP Design Framework Portal. Figure 2 provides a
-high-level view of the ONAP architecture and microservices-based
-platform components, including all ONAP projects.
-
-**Figure 2: ONAP Platform components with projects (Beijing Release)**
-
-|image1|
+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.
-In Figure 3 below, we provide a functional view of the architecture,
-which highlights the role of key new components:
+To create a service or operational capability, it is necessary to develop
+service/operations-specific service definitions, data collection, analytics,
+and policies (including recipes for corrective/remedial action) using the ONAP
+Design Framework Portal.
-1. The Beijing release standardizes and improves northbound
- interoperability for the ONAP Platform using the **External API**
- component (1)
+Figure 1 provides a high-level view of the ONAP architecture and
+microservices-based platform components.
-2. **OOM** provides the ability to manage cloud-native installation and
- deployments to Kubernetes-managed cloud environments.
+|image1|
-3. ONAP Common Services now manage more complex and optimized
- topologies. **MUSIC** allows ONAP to scale to multi-site
- environments to support global scale infrastructure requirements. The
- ONAP Optimization Framework (OOF) provides a declarative,
- policy-driven approach for creating and running optimization
+**Figure 1: ONAP Platform architecture (Casablanca 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
+ designing required services.
+2. 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
+ 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.
-
-4. **Information Model and framework utilities** have evolved to
- harmonize the topology, workflow, and policy models from a number of
- SDOs including ETSI NFV MANO, TM Forum SID, ONF Core, OASIS TOSCA,
- IETF and MEF.
-
-|image2| Figure 3. Functional view of the ONAP architecture
+5. 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.
+
+|image2|
+
+**Figure 2. Functional view of the ONAP architecture**
+
+The Casablanca 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.
+
+Runtime: Service Orchestration (SO) and controllers have new functionality to
+support physical network functions (PNFs), reboot, traffic migration, expanded
+hardware platform awareness (HPA), cloud agnostic intent capabilities, improved
+homing service, SDN geographic redundancy, scale-out and edge cloud onboarding.
+This will expand the actions available to support lifecycle management
+functionality, increase performance and availability, and unlock new edge
+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.
+
+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.
+
+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.
+
+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: 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
========================
-As a cloud-native application that consists of numerous services, ONAP
-requires sophisticated initial deployment as well as post-deployment
-management. It needs to be highly reliable, scalable, secure and easy to
-manage. Also, the ONAP deployment needs to be flexible to suit the
-different scenarios and purposes for various operator environments.
-Users may also want to select part of the ONAP components to integrate
-into their own systems. To achieve all these goals, ONAP is designed as
-a microservices based system, with all components released as Docker
-containers.
-
-The ONAP Operations Manager
-(`OOM <https://wiki.onap.org/display/DW/ONAP+Operations+Manager+Project>`__)
-is responsible for orchestrating the end-to-end lifecycle management and
-monitoring of ONAP components. OOM uses Kubernetes to provide CPU
-efficiency and platform deployment. In addition, OOM helps enhance ONAP
-platform maturity by providing scalability and resiliency enhancements
-to the components it manages.
-
-|image3|
-
-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 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 Kubernetes
-
-4. **Restart** - failed ONAP components are restarted automatically
-
-5. **Clustering and Scaling** - cluster ONAP services to enable seamless
- scaling
-
-6. **Upgrade** - change-out containers or configuration with little or
- no service impact
-
-7. **Deletion** - cleanup individual containers or entire deployments
-
-OOM supports a wide variety of cloud infrastructures to suit your
-individual requirements.
-
-The Microservices Bus (MSB) component project provides some fundamental
-microservices support such as service registration/discovery, external
-API gateway, internal API gateway, client software development kit
-(SDK), and Swagger SDK to help ONAP projects evolve towards the
-microservice direction. MSB is integrated with OOM to provide
-transparent service registration for ONAP microservices, it also
-supports OpenStack(Heat) and bare metal deployment.
+As a cloud-native application that consists of numerous services, ONAP requires
+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.
+
+The ONAP Operations Manager (OOM) is responsible for orchestrating the
+end-to-end lifecycle management and monitoring of ONAP components. OOM uses
+Kubernetes to provide CPU efficiency and platform deployment. In addition, OOM
+helps enhance ONAP platform maturity by providing scalability and resiliency
+enhancements to the components it manages.
+
+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
+ 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
+ Kubernetes
+4. Restart - failed ONAP components are restarted automatically
+5. Clustering and Scaling - cluster ONAP services to enable seamless scaling
+6. Upgrade - change out containers or configuration with little or no service
+ impact
+7. Deletion - 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.
4. Portal
=========
-ONAP delivers a single, consistent user experience to both design-time
-and run-time environments, based on the user’s role. Role changes are
-configured within a single ONAP instance.
-
-This user experience is managed by the ONAP Portal, which provides
-access to design, analytics and operational control/administration
-functions via a shared, role-based menu or dashboard. The portal
-architecture provides web-based capabilities such as application
-onboarding and management, centralized access management, and
-dashboards, as well as hosted application widgets.
-
-The portal provides an SDK to enable multiple development teams to
-adhere to consistent UI development requirements by taking advantage of
-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/redefine new collection, analytics, and policies (including
-recipes for corrective/remedial action) using the ONAP Design Framework
-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.
+
+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 through the Authentication and Authorization
+Framework, 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/redefine new collection, analytics, and policies
+(including recipes for corrective/remedial action) using the ONAP Design
+Framework Portal.
5. Design-time Framework
========================
-The design-time framework is a comprehensive development environment
-with tools, techniques, and repositories for defining/ describing
-resources, services, and products.
+The design time framework is a comprehensive development environment with
+tools, techniques, and repositories for defining/describing resources,
+services, and products.
The design time framework facilitates reuse of models, further improving
-efficiency as more and more models become available. Resources,
-services, products, and their management and control functions can all
-be modeled using a common set of specifications and policies (e.g., rule
-sets) for controlling behavior and process execution. Process
-specifications automatically sequence instantiation, delivery and
-lifecycle management for resources, services, products and the ONAP
-platform components themselves. Certain process specifications (i.e.,
-‘recipes’) and policies are geographically distributed to optimize
-performance and maximize autonomous behavior in federated cloud
-environments.
-
-Service Design and Creation (SDC) provides tools, techniques, and
-repositories to define/simulate/certify system assets as well as their
-associated processes and policies. Each asset is categorized into one of
-four 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/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.
-
-The Policy Creation component deals with polices; these are rules,
-conditions, requirements, constraints, attributes, or needs that must be
-provided, maintained, and/or enforced. At a lower level, Policy involves
-machine-readable rules enabling actions to be taken based on triggers or
-requests. Policies often consider specific conditions in effect (both in
-terms of triggering specific policies when conditions are met, and in
-selecting specific outcomes of the evaluated policies appropriate to the
-conditions). Policy allows rapid modification through easily updating
-rules, thus updating technical behaviors of components in which those
-policies are used, without requiring rewrites of their software code.
-Policy permits simpler management / control of complex mechanisms via
-abstraction.
-
-The Closed Loop Automation Management Platform (CLAMP) provides a
-platform for designing and managing control loops. CLAMP is used to
-design a closed loop, configure it with specific parameters for a
-particular network service, then deploy and decommission it. Once
-deployed, a user can also update the loop with new parameters during
-runtime, as well as suspend and restart it.
+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.
+
+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.
+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.
+
+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.
+
+The Policy Creation component deals with policies; these are rules, conditions,
+requirements, constraints, attributes, or needs that must be provided,
+maintained, and/or enforced. At a lower level, Policy involves machine-readable
+rules enabling actions to be taken based on triggers or requests. Policies
+often consider specific conditions in effect (both in terms of triggering
+specific policies when conditions are met, and in selecting specific outcomes
+of the evaluated policies appropriate to the conditions).
+
+Policy allows rapid modification through easily updating rules, thus updating
+technical behaviors of components in which those policies are used, without
+requiring rewrites of their software code. Policy permits simpler management /
+control of complex mechanisms via abstraction.
+
+The Closed Loop Automation Management Platform (CLAMP) provides a platform for
+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
====================
-The runtime execution framework executes the rules and policies
-distributed by the design and creation environment.
+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, and data
-management. A new component, Multi-Site State Coordination (MUSIC),
-allows the platform to register and manage state across multi-site
-deployments. The External API provides access for third-party frameworks
-such as MEF, TM Forum and potentially others, to facilitate interactions
-between operator BSS and relevant ONAP components.
+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.
Orchestration
-------------
-The Service Orchestrator (SO) component executes the specified processes
-by automating sequences of activities, tasks, rules and policies needed
-for on-demand creation, modification or removal of network, application
-or infrastructure services and resources. The SO provides orchestration
-at a very high level, with an end-to-end view of the infrastructure,
-network, and applications.
-
-The External API Northbound Interface component provides a
-standards-based interface between the BSS and and various ONAP
-components, including Service Orchestrator, A&AI and SDC, providing an
-abstracted view of the platform. This type of abstraction allows service
-providers to use their existing BSS/OSS environment and minimize
-lengthy, high-cost integration with underlying infrastructure. The
-Beijing release is the first of a series of enhancements in support of
-SDO collaborations, which are expected to support inter-operator
-exchanges and other use cases defined by associated standards bodies
-such as MEF, TM Forum and others.
-
-Policy-driven Workload Optimization
+The Service Orchestrator (SO) component executes the specified processes by
+automating sequences of activities, tasks, rules and policies needed for
+on-demand creation, modification or removal of network, application or
+infrastructure services and resources. The SO provides orchestration at a very
+high level, with an end-to-end view of the infrastructure, network, and
+applications.
+
+The External API Northbound Interface component provides a standards-based
+interface between the BSS and 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.
+
+The Virtual Infrastructure Deployment (VID) application enables users to
+instantiate infrastructure services from SDC, along with their associated
+components, and to execute change management operations such as scaling and
+software upgrades to existing VNF instances.
+
+Policy-Driven Workload Optimization
-----------------------------------
-In the Beijing Release, ONAP Optimization Framework (OOF) provides a
-policy-driven and model-driven framework for creating optimization
-applications for a broad range of use cases. OOF-HAS is a policy-driven
-workload optimization service that enables optimized placement of
-services across multiple sites and multiple clouds, based on a wide
-variety of policy constraints including capacity, location, platform
-capabilities, and other service specific constraints.
-
-In the Beijing Release, ONAP Multi-VIM/Cloud (MC) and several other ONAP
-components such as Policy, SO, A&AI etc. play an important role in
-enabling “Policy-driven Performance/Security-aware Adaptive Workload
-Placement/Scheduling” across cloud sites through OOF-HAS. OOF-HAS uses
-Hardware Platform Awareness (HPA) and real-time Capacity Checks provided
-by ONAP MC to determine the optimal VIM/Cloud instances, which can
-deliver the required performance SLAs, for workload (VNF etc.) placement
-and scheduling (Homing). The key operator benefit is realizing the true
-value of virtualization through fine grained optimization of cloud
-resources while delivering the performance/security SLAs. For the
-Beijing release, this feature is available for the vCPE use case.
+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
+optimization service that enables optimized placement of services across
+multiple sites and multiple clouds, based on a wide variety of policy
+constraints including capacity, location, platform capabilities, and other
+service specific constraints.
+
+ONAP Multi-VIM/Cloud (MC) and several other ONAP components such as Policy, SO,
+A&AI etc. play an important role in enabling “Policy-driven
+Performance/Security-Aware Adaptive Workload Placement/ Scheduling” across
+cloud sites through OOF-HAS. OOF-HAS uses Hardware Platform Awareness (HPA),
+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.
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, that is responsible for lifecycle
-management of virtual services and the associated physical COTS server
-infrastructure. VF-C provides a generic VNFM capability but also
-integrates with external VNFMs and VIMs as part of a NFV MANO stack.
-
-In the Beijing release, the new Multisite State Coordination (MUSIC)
-project records and manages state of the Portal and ONAP Optimization
-Framework to ensure consistency, redundancy and high availability across
-geographically distributed ONAP deployments.
+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 that is
+responsible for lifecycle management of virtual services and the associated
+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. 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 metadata-driven, allowing new inventory types to be added
-dynamically and quickly via SDC catalog definitions, eliminating the
-need for lengthy development cycles.
-
-7. Closed-Loop Automation
-=========================
-
-The following sections describe the ONAP frameworks designed to address
-major operator 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 3.
-
-Closed-loop control is provided by Data Collection, Analytics and Events
-(DCAE) and one or more of the other ONAP runtime components.
-Collectively, they provide FCAPS (Fault Configuration Accounting
-Performance Security) functionality. DCAE collects performance, usage,
-and configuration data; provides computation of analytics; aids in
-troubleshooting; and publishes events, data and analytics (e.g., to
-policy, orchestration, and the data lake). Another component, “Holmes”,
-connects to DCAE and provides alarm correlation for ONAP, which depicts
-the topological relation between different alarms raising either from
-different layers of VNFs or from different VNF entities that are
-distributed all over the network.
-
-Working with the Policy Framework and CLAMP, these components detect
-problems in the network and identify the appropriate remediation. In
-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.
-
-**Figure 5: ONAP Closed Loop Automation**
+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.
+
+To deliver the promised dynamism of SDN/NFV, A&AI is updated in real time by
+the controllers as they make changes in the network environment. A&AI is
+metadata-driven, allowing new inventory types to be added dynamically and
+quickly via SDC catalog definitions, eliminating the need for lengthy
+development cycles.
+
+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.
+
+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 Homes
+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.
+
+We refer to this automation pattern as “closed control 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 control loop automation” and the various phases within the service
+lifecycle using the automation is depicted in Figure 3.
+
+Closed control loop control is provided by Data Collection, Analytics and
+Events (DCAE) and one or more of the other ONAP runtime components.
+Collectively, they provide FCAPS (Fault Configuration Accounting Performance
+Security) functionality. DCAE collects performance, usage, and configuration
+data; provides computation of analytics; aids in troubleshooting; and publishes
+events, data and analytics (e.g., to policy, orchestration, and the data lake).
+Another component, “Holmes”, connects to DCAE and provides alarm correlation
+for ONAP. 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.
+
+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. The policy framework is extended to support additional policy decision
+capabilities with the introduction of adaptive policy execution.
-|image4|
+|image3|
+
+**Figure 3: ONAP Closed Control Loop Automation**
8. Common Services
==================
-ONAP provides common operational services for all ONAP components
-including activity logging, reporting, common data layer, access
-control, secret and credential management, resiliency, and software
-lifecycle management.
+ONAP provides common operational services for all ONAP components including
+activity logging, reporting, common data layer, access control, secret and
+credential management, resiliency, and software lifecycle management.
-These services provide access management and security enforcement, data
-backup, restoration and recovery. They support standardized VNF
-interfaces and guidelines.
+These services provide access management and security enforcement, data backup,
+restoration and recovery. They support standardized VNF interfaces and
+guidelines.
-Operating in a virtualized environment introduces new security
-challenges and opportunities. ONAP provides increased security by
-embedding access controls in each ONAP platform component, augmented by
-analytics and policy components specifically designed for the detection
-and mitigation of security violations.
+Operating in a virtualized environment introduces new security challenges and
+opportunities. ONAP provides increased security by embedding access controls
+in each ONAP platform component, augmented by analytics and policy components
+specifically designed for the detection and mitigation of security violations.
9. ONAP Modeling
================
-Adopting the model-driven approach, ONAP provides models to assist the
-service design, development of various ONAP components and improve the
-interoperability of ONAP.
+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 run time framework
-development. The ONAP modeling project leverages the experience of
-member companies, standard organizations and other open source projects
-to produce models which are simple, extensible, and reusable. The goal
-is to fulfill the requirements of various use cases, guide the
-development and bring consistency among ONAP components and explore a
-common model to improve the interoperability of ONAP.
+Models are 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
+requirements of various use cases, guide the development and bring consistency
+among ONAP components and explore a common model to improve the
+interoperability of ONAP.
-In the Bejing Release, ONAP supports the following Models:
+In the Casablanca Release, ONAP supports the following Models:
-- A VNF Information Model based on ETSI NFV IFA011 v.2.4.1 with
+- 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 Model based on TOSCA implementation based on the IM
- and follow the same model definitions in ETSI NFV SOL001 v 0.6.0.
+These models enable ONAP to interoperate with implementations based on
+standards, and improve the industry collaboration.
+
+10. ONAP Blueprints
+===================
+
+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.
+
+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.
-- VNF Package format based on ETSI NFV SOL004 specification.
+|image4|
-These models enable ONAP to interoperate with implementations based on
-standard, and improve the industry collaboration. Service models,
-multi-VIM models and other models will be explored and defined in the
-Casablanca and future releases.
+**Figure 4. Disaggregated Hybrid RAN**
-10. ONAP Use Cases
-==================
+Read the 5G Blueprint to learn more.
+
+Virtual CPE Blueprint
+---------------------
-The ONAP project tests blueprints for real-world use cases to enable
-rapid adoption of the platform. With the first release of ONAP
-(“Amsterdam”), we introduced two blueprints: vCPE and VoLTE. Subsequent
-releases test additional functionality and/or new blueprints.
-
-Virtual CPE Use Case
---------------------
-
-In this use case, many traditional network functions such as NAT,
-firewall, and parental controls are implemented as virtual network
-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 VNF
-lifecycle. Deploying ONAP in this fashion simplifies and greatly
-accelerates the task of trialing and launching new value-added services.
-
-In the Beijing Release, the vCPE use case supports Policy-driven
-Workload Optimization, which is supported by OOF, Multi-VIM/Cloud,
-Policy, SO, A&AI and other ONAP components.
-
-**Figure 6. ONAP vCPE Architecture**
+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.
|image5|
-Read the Residential vCPE Use Case with ONAP whitepaper to learn more.
+**Figure 5. ONAP vCPE Architecture**
-Voice over LTE (VoLTE) Use Case
--------------------------------
+Read the Residential vCPE Use Case with ONAP blueprint to learn more.
-The second blueprint developed for ONAP is Voice over LTE. This
-blueprint demonstrates how a Mobile Service Provider (SP) could deploy
-VoLTE services based on SDN/NFV. This blueprint incorporates commercial
-VNFs to create and manage the underlying vEPC and vIMS services by
-interworking with vendor-specific components, including VNFMs, EMSs,
-VIMs and SDN controllers, across Edge Data Centers and a Core Date
-Center.
+Voice over LTE (VoLTE) Blueprint
+--------------------------------
-**Figure 7. ONAP VoLTE Architecture**
+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.
|image6|
-ONAP supports the VoLTE use case with several key components: SO, VF-C,
-SDN-C, and Multi-VIM/ Cloud. In this use case, SO is responsible for
-VoLTE end-to-end service orchestration. It collaborates with VF-C and
-SDN-C to deploy the VoLTE service. ONAP uses the SDN-C component to
-establish network connectivity, then the VF-C component completes the
-Network Services and VNF lifecycle management (including service
-initiation, termination and manual scaling which is composed of VNFs
-based on the unified VNFD model) and FCAPS (fault, configuration,
-accounting, performance, security) management. VF-C can also integrate
-with commercial VIMs in the Edge and Core datacenters via abstract
-interfaces provided by Multi-VIM/Cloud.
+**Figure 6. ONAP VoLTE Architecture Open Network Automation Platform**
+
+Read the VoLTE with ONAP blueprint to learn more.
-Using ONAP to manage the complete lifecycle of the VoLTE use case brings
-increased agility, CAPEX and OPEX reductions, and increased
-infrastructure efficiency to Communication Service Providers (CSPs). In
-addition, the usage of commercial software in this blueprint offers CSPs
-an efficient path to rapid production.
+CCVPN (Cross Domain and Cross Layer VPN) Blueprint
+--------------------------------------------------
+CSPs, such as CMCC and Vodafone, see a strong demand for high-bandwidth, flat,
+high-speed OTN (Optical Transport Networks) across carrier networks. They also
+want to provide a high-speed, flexible and intelligent service for high-value
+customers, and an instant and flexible VPN service for SMB companies.
-Read the VoLTE Use Case with ONAP whitepaper to learn more.
+|image7|
-.. include:: blueprint-enr.rst
+**Figure 7. 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.
+
+Read the CCVPN with ONAP 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
+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.
+
+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.
+policy-driven orchestration and automation of physical and virtual network
+functions that will enable software, network, IT and cloud providers and
+developers to rapidly automate new services and support complete lifecycle
+management.
-By unifying member resources, ONAP will accelerate the development of a
-vibrant ecosystem of VNFs around a globally shared architecture and
-implementation for network automation–with an open standards focus–
-faster than any one product could on its own.
+By unifying member resources, ONAP will accelerate the development of a vibrant
+ecosystem around a globally shared architecture and implementation for network
+automation—with an open standards focus—faster than any one product could on
+its own.
+Resources
+=========
+Watch videos about the major platform components on YouTube and Youku
+Read about how ONAP can be deployed using containers
-.. |image0| image:: media/ONAP-DTRT.png
- :width: 6in
- :height: 2.6in
.. |image1| image:: media/ONAP-toplevel.png
:width: 6.5in
:height: 3.13548in
.. |image2| image:: media/ONAP-fncview.png
:width: 6.5in
:height: 3.409in
-.. |image3| image:: media/ONAP-oom.png
- :width: 2.28472in
- :height: 2.30625in
-.. |image4| image:: media/ONAP-closedloop.png
+.. |image3| image:: media/ONAP-closedloop.png
+ :width: 6in
+ :height: 2.6in
+.. |image4| image:: media/ONAP-5G.png
:width: 6in
:height: 2.6in
.. |image5| image:: media/ONAP-vcpe.png
.. |image6| image:: media/ONAP-volte.png
:width: 6.5in
:height: 3.02431in
+.. |image7| image:: media/ONAP-ccvpn.png
+ :width: 6.5in
+ :height: 3.02431in
Code Review / doc.git / commitdiff
