X-Git-Url: https://gerrit.onap.org/r/gitweb?a=blobdiff_plain;f=docs%2Fguides%2Fonap-developer%2Farchitecture%2Fonap-architecture.rst;h=47928c9c2fe49811b6eba115ed824aa11e2c5961;hb=b6416d85cd51795f72271b654cb20c260a503b8c;hp=995dd8aae5cd5325fa3e19ab980527792a8b5073;hpb=3614d4c7e79deae2b3493fc26f10521a087ff93e;p=doc.git diff --git a/docs/guides/onap-developer/architecture/onap-architecture.rst b/docs/guides/onap-developer/architecture/onap-architecture.rst index 995dd8aae..47928c9c2 100644 --- a/docs/guides/onap-developer/architecture/onap-architecture.rst +++ b/docs/guides/onap-developer/architecture/onap-architecture.rst @@ -2,597 +2,902 @@ .. 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 .. Copyright 2017-2018 Huawei Technologies Co., Ltd. - -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 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: - -- A robust design framework that allows specification of the service in - all aspects – modeling the resources and relationships that make up - the service, specifying the policy rules that guide the service - behavior, specifying the applications, analytics and closed-loop - events needed for the elastic management of the service. - -- An orchestration and control framework (Service Orchestrator and - Controllers) that is recipe/policy-driven to provide automated - instantiation of the service when needed and managing service demands - in an elastic manner. - -- An analytic framework that closely monitors the service behavior - during the service lifecycle based on the specified design, analytics - and policies to enable response as required from the control framework, - to deal with situations ranging from those that require healing to those - that require scaling of the resources to elastically adjust to demand - variations. - -To achieve this, ONAP decouples the details of specific services and -technologies from the common information models, core orchestration -platform and generic management engines (for discovery, provisioning, -assurance etc). Furthermore, it marries the speed and style of a -DevOps/NetOps approach with the formal models and processes operators -require to introduce new services and technologies. 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, +.. Copyright 2019 ONAP Contributors +.. Copyright 2020 ONAP Contributors +.. Copyright 2021 ONAP Contributors + +.. _ONAP-architecture: + +Introduction +============ +ONAP is a comprehensive platform for orchestration, management, and automation +of network and edge computing services for network operators, cloud providers, +and enterprises. Real-time, policy-driven orchestration and automation of +physical, virtual, and cloud native network functions enables rapid automation +of new services and complete lifecycle management critical for 5G and +next-generation networks. + +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. + +The challenge that ONAP meets is to help network operators 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 eighth release. + +ONAP is addressing these challenges by developing global and massive scale +(multi-site and multi-VIM) automation capabilities for physical, virtual, and +cloud native 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, as well as legacy equipment (PNF). The Service Design & Creation +(SDC) project also offers seamless orchestration of CNFs. ONAP’s consolidated +xNF requirements publication enables commercial development of ONAP-compliant +xNFs. This approach allows network and cloud operators to optimize their +physical, virtual and cloud native 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 +providers to collaboratively instantiate network elements and services in a +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 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 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. + +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 +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. - -- 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| - -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 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 +- Scalability 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 + +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. + +Architecture Overview +===================== + +The ONAP architecture consists of a design time and run time functions, as well +as functions for managing ONAP itself. + + Note: Use the interactive features of the below ONAP Architecture Overview. + Hover with your mouse over an element in the figure for a short description. + Click the element to get forwarded to a more detailed description. + +.. raw:: html + :file: media/onap-architecture-overview-interactive-path.svg + +**Figure 1: Interactive high-level view of the ONAP architecture with its +microservices-based platform components.** + +The figure below provides a simplified functional view of the architecture, +which highlights the role of a few key components: + +#. ONAP Design time environment provides onboarding services and resources + into ONAP and designing required services. +#. External API provides northbound interoperability for the ONAP Platform. +#. ONAP Runtime environment provides a model- and policy-driven orchestration + and control framework for an automated instantiation and configuration of + services and resources. Multi-VIM/Cloud provides cloud interoperability for + the ONAP workloads. Analytic framework that closely monitors the service + behavior handles closed control loop management for handling healing, + scaling and update dynamically. +#. 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. 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. 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, ETSI/3GPP, O-RAN, TM Forum SID, ONF Core, OASIS TOSCA, IETF, +and MEF. + +|image2| + +**Figure 2. Functional view of the ONAP architecture** + +Microservices Support +===================== +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 +following best practice building rules to optimize their image size. Numerous +optimizations such as shared databases and the use of standardized lightweight +container operating systems reduce the overall ONAP footprint. + +ONAP Operations Manager (OOM) +----------------------------- +The ONAP Operations Manager (OOM) is responsible for orchestrating the +end-to-end lifecycle management and monitoring of ONAP components. OOM uses +Kubernetes with IPv4 and IPv6 support 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: + +#. Deployment - with built-in component dependency management (including + multiple clusters, federated deployments across sites, and anti-affinity + rules) +#. Configuration - unified configuration across all ONAP components +#. Monitoring - real-time health monitoring feeding to a Consul GUI and + Kubernetes +#. 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 +#. Deletion - clean up individual containers or entire deployments + +OOM supports a wide variety of cloud infrastructures to suit your individual +requirements. + +Starting with the Istanbul-R9, as a PoC, OOM provides Service Mesh-based +mTLS (mutual TLS) between ONAP components to secure component communications, +by leveraging Istio. The goal is to substitute (unmaintained) AAF +functionalities. + +Microservices Bus (MSB) +----------------------- +Microservices Bus (MSB) provides fundamental microservices support including +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. + +In the spirit of leveraging the microservice capabilities, further steps +towards increased modularity have been taken. Service Orchestrator (SO) and the +controllers have increased its level of modularity. + +Portal +====== + +.. important:: PORTAL is an unmaintained ONAP component! + +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 (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 +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. + +Design Time Framework +===================== +The design time framework is a comprehensive development environment with +tools, techniques, and repositories for defining/ describing resources, +services, and products. -In Figure 3 below, we provide a functional view of the architecture, -which highlights the role of key new components: - -1. The Beijing release standardizes and improves northbound - interoperability for the ONAP Platform using the **External API** - component (1) - -2. **OOM** provides the ability to manage cloud-native installation and - deployments to Kubernetes-managed cloud environments. - -3. ONAP Common Services now manage more complex and optimized - topologies. **MUSIC** allows ONAP to scale to multi-site - environments to support global scale infrastructure requirements. The - ONAP Optimization Framework (OOF) provides a declarative, - policy-driven approach for creating and running optimization - applications like Homing/Placement, and Change Management Scheduling - Optimization. - -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 - -3. Microservices Support -======================== +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. -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. +Service Design and Creation (SDC) +--------------------------------- +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. SDC supports the onboarding of Network +Services packages (ETSI SOL007 with ETSI SOL001), CNF packages (Helm), +VNF packages (Heat or ETSI SOL004) and PNF packages (ETSI SOL004). SDC also +includes some capabilities to model 5G network slicing using the standard +properties (Slice Profile, Service Template). + +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 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. ONAP supports onboarding of CNFs and PNFs as +well. + +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. + +VNF SDK +------- +VND SDK provides the functionality to create VNF/PNF packages, test VNF +packages and VNF ONAP compliance and store VNF/PNF packages and upload to/from +a marketplace. + +VVP +--- +VVP provides validation for the VNF Heat package. + +Runtime Framework +================= +The runtime execution framework executes the rules and policies and other +models distributed by the design and creation environment. + +This allows for the distribution of models and policy among various ONAP +modules such as the Service Orchestrator (SO), Controllers, Data Collection, +Analytics and Events (DCAE), Active and Available Inventory (A&AI). These +components use common services that support access control. -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. +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, this includes VNFs, CNFs and PNFs, +by conforming to industry standards such as ETSI, TMF. +The SO provides orchestration at a very high level, with an end-to-end view +of the infrastructure, network, and applications. Examples of this include +BroadBand Service (BBS) and Cross Domain and Cross Layer VPN (CCVPN). +The SO is modular and hierarchical to handle services and multi-level +resources and Network Slicing, by leveraging pluggable adapters and delegating +orchestration operations to NFVO (SO NFVO, VFC), VNFM, CNF Manager, NSMF +(Network Slice Management Function), NSSMF (Network Slice Subnet Management +Function). +Starting from the Guilin release, the SO provides CNF orchestration support +through integration of CNF adapter in ONAP SO: + +- Support for provisioning CNFs using an external K8S Manager +- Support the Helm-based orchestration +- Leverage the CNF Adapter to interact with the K8S Plugin in MultiCloud +- Bring in the advantage of the K8S orchestrator and +- Set stage for the Cloud Native scenarios + +3GPP (TS 28.801) defines three layer slice management function which include: + +- CSMF (Communication Service Management Function) +- NSMF (Network Slice Management Function) +- NSSMF (Network Slice Subnet Management Function) + +To realize the three layers, CSMF, NSMF and/or NSSMF are realized within ONAP, +or use the external CSMF, NSMF or NSSMF. For ONAP-based network slice +management, different choices can be made as follows. among them, ONAP +orchestration currently supports options #1 and #4. |image3| -OOM is the lifecycle manager of the ONAP platform and uses the -Kubernetes container management system and Consul to provide the -following functionality: +**Figure 3: ONAP Network Slicing Support Options** -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 +Virtual Infrastructure Deployment (VID) +--------------------------------------- -3. **Monitoring** - real-time health monitoring feeding to a Consul GUI - and Kubernetes +.. important:: VID is an unmaintained ONAP component! -4. **Restart** - failed ONAP components are restarted automatically +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. -5. **Clustering and Scaling** - cluster ONAP services to enable seamless - scaling  +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 +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 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. -6. **Upgrade** - change-out containers or configuration with little or - no service impact +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 (SDN-C). +The Virtual Function Controller (VF-C) and SO NFVO provide 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, and both VF-C and SO NFVO integrate with +external VNFMs and VIMs as part of an NFV MANO stack. + +.. important:: APP-C is an unmaintained ONAP component! + +ONAP has two application level configuration and lifecycle management modules +called SDN-C and App-C. Both provide similar services (application level +configuration using NetConf, Chef, Ansible, RestConf, etc.) and lifecycle +management functions (e.g., stop, resume, health check, etc.). +They share common code from CCSDK repo. However, there are some differences +between these two modules (SDN-C uses CDS only for onboarding and +configuration / LCM flow design, whereas App-C uses CDT for the LCM functions +for self service to provide artifacts storing in App-C Database). +SDN-C has been used mainly for Layer1-3 network elements and App-C is +being used for Layer4-7 network functions. This is a very loose +distinction and we expect that over time we will get better alignment and +have common repository for controller code supporting application level +configuration and lifecycle management of all network elements (physical or +virtual, layer 1-7). Because of these overlaps, we have documented SDN-C and +App-C together. ONAP Controller Family (SDN-C / App-C) configures and maintains +the health of L1-7 Network Function (VNF, PNF, CNF) and network services +throughout their lifecycle: + +- Configures Network Functions (VNF/PNF) +- Provides programmable network application management platform: + + - Behavior patterns programmed via models and policies + - Standards based models & protocols for multi-vendor implementation + - Extensible SB adapters such as Netconf, Ansible, Rest API, etc. + - Operation control, version management, software updates, etc. +- Local source of truth + - Manages inventory within its scope + - Manages and stores state of NFs + - Supports Configuration Audits + +Controller Design Studio (CDS) +------------------------------ +The Controller Design Studio (CDS) community in ONAP has contributed a +framework to automate the resolution of resources for instantiation and any +config provisioning operation, such as day0, day1 or day2 configuration. The +essential function of CDS is to create and populate a controller blueprint, +create a configuration file from this Controller blueprint, and associate at +design time this configuration file (configlet) to a PNF/VNF/CNF during the +design phase. CDS removes dependence on code releases and the delays they cause +and puts the control of services into the hands of the service providers. Users +can change a model and its parameters with great flexibility to fetch data from +external systems (e.g., IPAM) that is required in real deployments. This makes +service providers more responsive to their customers and able to deliver +products that more closely match the needs of those customers. -7. **Deletion** - cleanup individual containers or entire 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 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. + +Policy Framework +---------------- +The Policy framework provides policy based decision making capability and +supports multiple policy engines and can distribute policies through policy +design capabilities in SDC, simplifying the design process. + +Multi Cloud Adaptation +---------------------- +Multi-VIM/Cloud provides and infrastructure adaptation layer for VIMs/Clouds +and K8s clusters in exposing advanced 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 K8s plugin is in charge of deploying CNFs on the Kubernetes +clusters using Kubernetes APIs. + +Data Collection Analytics and Events (DCAE) +------------------------------------------- +DCAE provides the capability to collect events, and host analytics applications +(DCAE Services) + +Closed Control Loop Automation Management Platform (CLAMP) +---------------------------------------------------------- +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 (VNF Event Streaming) 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 move +through the loop of micro-services like Homes for event detection, Policy +for determining actions, and finally, controllers and orchestrators to +implement actions. The Policy framework is also used to monitor the loops +themselves and manage their lifecycle. DCAE also includes a number of +specialized micro-services to support some use-cases such as the Slice Analysis +or SON-Handler. Some dedicated event processor modules transform collected data +(SNMP, 3GPP XML, RESTCONF) to VES format and push the various data into data +lake. 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, new data collection capabilities with High Volume VES, and bulk +performance management support. + +Working with the Policy Framework (and embedded 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 the +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. + +Starting with the Honolulu-R8 and concluding in the Istanbul-R9 release, the +CLAMP component was successfully integrated into the Policy component initially +as a PoC in the Honolulu-R8 release and then as a fully integrated component +within the Policy component in Istanbul-R9 release. +CLAMP's functional role to provision Policy has been enhanced to support +provisioning of policies outside of the context of a Control Loop and therefore +act as a Policy UI. In the Istanbul release the CLAMP integration was +officially released. -OOM supports a wide variety of cloud infrastructures to suit your -individual requirements. +|image4| -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. +**Figure 4: ONAP Closed Control Loop Automation** -4. Portal -========= +Virtual Function Controller (VFC) +--------------------------------- +VFC provides the NFVO capability to manage the lifecycle of network service and +VNFs, by conforming to ETSI NFV specification. -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. - -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. +Data Movement as a Platform (DMaaP) +----------------------------------- +DMaaP provides data movement service such as message routing and data routing. -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. +Use Case UI (UUI) +----------------- +UUI provides the capability to instantiate the blueprint User Cases and +visualize the state. -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. - -6. 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, 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. +CLI +--- +ONAP CLI provides a command line interface for access to ONAP. -Orchestration +External APIs ------------- -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 ------------------------------------ +.. important:: EXTERNALAPI is an unmaintained ONAP component! -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. +External APIs provide services to expose the capability of ONAP. -Controllers ------------ +Shared Services +=============== -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. +.. important:: LOGGING is an unmaintained ONAP component! -Inventory ---------- +ONAP provides a set of operational services for all ONAP components including +activity logging, reporting, common data layer, configuration, persistence, +access control, secret and credential management, resiliency, and software +lifecycle management. -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 -========================= +These services provide access management and security enforcement, data backup, +configuration persistence, 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. + +Configuration Persistence Service (CPS) +--------------------------------------- +The Configuration Persistence Service (CPS) provides storage for real-time +run-time configuration and operational parameters that need to be used by ONAP. +Several services ranging from SDN-C, DCAE and the network slicing use case +utilize CPS for these purposes. Its details in +:ref:`CPS - Configuration Persistence Service`. + +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 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 +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. -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** +ONAP supports various models detailed in +:ref:`Modeling Documentation`. -|image4| +The modeling project includes the ETSI catalog component, which provides the +parser functionalities, as well as additional package management +functionalities. -8. Common Services +Industry Alignment ================== +ONAP support and collaboration with other standards and open source communities +is evident in the architecture. -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. +- 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). +- Further collaboration includes 5G/ORAN & 3GPP Harmonization, Acumos DCAE + Integration, and CNCF Telecom User Group (TUG). -These services provide access management and security enforcement, data -backup, restoration and recovery. They support standardized VNF -interfaces and guidelines. +Read this whitepaper for more information: +`The Progress of ONAP: Harmonizing Open Source and Standards `_ -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. +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. + +5G Blueprint +------------ +The 5G blueprint is a multi-release effort, with five key initiatives around +end-to-end service orchestration, network slicing, PNF/VNF lifecycle management +, PNF integration, and network optimization. The combination of eMBB that +promises peak data rates of 20 Mbps, uRLLC that guarantees sub-millisecond +response times, MMTC that can support 0.92 devices per sq. ft., and network +slicing brings with it some unique requirements. First ONAP needs to manage the +lifecycle of a network slice from initial creation/activation all the way to +deactivation/termination. Next, 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. ONAP also provides self organizing +network (SON) services such as physical cell ID allocation for new RAN sites. +These requirements have led to the five above-listed initiatives and have been +developed in close cooperation with other standards and open source +organizations such as 3GPP, TM Forum, ETSI, and O-RAN Software Community. -9. ONAP Modeling -================ +|image5| -Adopting the model-driven approach, ONAP provides models to assist the -service design, development of various ONAP components and improve the -interoperability of ONAP. +**Figure 5. End-to-end 5G Service** -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. +Read the `5G Blueprint `_ +to learn more. -In the Bejing Release, ONAP supports the following Models: +A related activity outside of ONAP is called the 5G Super Blueprint where +multiple Linux Foundation projects are collaborating to demonstrate an +end-to-end 5G network. In the short-term, this blueprint will showcase +thre major projects: ONAP, Anuket (K8S NFVI), and Magma (LTE/5GC). -- A VNF Information Model based on ETSI NFV IFA011 v.2.4.1 with - appropriate modifications aligned with ONAP requirements; +|image6| -- 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. +**Figure 6. 5G Super Blueprint Initial Integration Activity** -- VNF Package format based on ETSI NFV SOL004 specification. +In the long-term, the 5G Super Blueprint will integrate O-RAN-SC and LF Edge +projects as well. -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. +Residential Connectivity Blueprints +----------------------------------- +Two ONAP blueprints (vCPE and BBS) address the residential connectivity use +case. + +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. + +|image7| + +**Figure 7. ONAP vCPE Architecture** + +Read the `Residential vCPE Use Case with ONAP blueprint `_ +to learn more. + +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). + +|image8| + +**Figure 8. ONAP BBS Architecture** + +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. + +|image9| + +**Figure 9. ONAP VoLTE Architecture Open Network Automation Platform** + +Read the `VoLTE Blueprint `_ +to learn more. + +Optical Transport Networking (OTN) +---------------------------------- +Two ONAP blueprints (CCVPN and MDONS) address the OTN use case. CCVPN addresses +Layers 2 and 3, while MDONS addresses Layers 0 and 1. + +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. + +|image10| + +**Figure 10. 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 resources and services. It achieves cross-domain orchestration +and 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 an east-west API which is being aligned with the MEF Interlude +API. CCVPN, in conjunction with the IBN use case, offers intent based cloud +leased line service. 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, close-loop reroute +for cross-domain service, dynamic changes (branch sites, VNFs) and intelligent +service optimization (including AI/ML). + +Read the `CCVPN Blueprint `_ +to learn more. + +MDONS (Multi-Domain Optical Network Service) Blueprint +...................................................... +While CCVPN addresses the automation of networking layers 2 and 3, it does not +address layers 0 and 1. Automating these layers is equally important because +providing an end-to-end service to their customers often requires a manual and +complex negotiation between CSPs that includes both the business arrangement +and the actual service design and activation. CSPs may also be structured such +that they operate multiple networks independently and require similar +transactions among their own networks and business units in order to provide an +end-to-end service. The MDONS blueprint created by AT&T, Orange, and Fujitsu +solves the above problem. MDONS and CCVPN used together can solve the OTN +automation problem in a comprehensive manner. + +|image11| + +**Figure 11. ONAP MDONS Architecture** + +Intent Based Network (IBN) Use Case +----------------------------------- +Intent technology can reduce the complexity of management without getting into +the intricate details of the underlying network infrastructure and contribute +to efficient network management. This use case performs a valuable business +function that can further reduce the operating expenses (OPEX) of network +management by shifting the paradigm from complex procedural operations to +declarative intent-driven operations + +|image12| + +**Figure 12. ONAP Intent-Based Networking Use Case** + +3GPP 28.812, Intent driven Management Service (Intent driven MnS), defines +some key concepts that are used by this initiative. The Intent Based Networking +(IBN) use case includes the development of an intent decision making. This use +case has initially been shown for a smart warehouse, where the intent is to +increase the output volume of automated guided vehicles (AVG) and the network +simply scales in response. The intent UI is implemented in UUI and the +components of the intent framework interact with many components of ONAP +including SO, A&AI, Policy, DCAE and CDS. + +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. In the recent releases, the vFW blueprint has been demonstrated by +using a mix of a CNF and VNF and entirely using CNFs. + +Verified end to end tests +========================= +Use cases +--------- +Various use cases have been tested for the Release. Use case examples are +listed below. See detailed information on use cases, functional requirements, +and automated use cases can be found here: +:ref:`Verified Use Cases`. -10. ONAP Use Cases -================== +- E2E Network Slicing +- 5G OOF (ONAP Optimization Framework) SON (Self-Organized Network) +- CCVPN-Transport Slicing -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** +Functional requirements +----------------------- +Various functional requirements have been tested for the Release. Detailed +information can be found in the +:ref:`Verified Use Cases`. -|image5| +- xNF Integration -Read the Residential vCPE Use Case with ONAP whitepaper to learn more. + - ONAP CNF orchestration - Enhancements + - PNF PreOnboarding + - PNF Plug & Play -Voice over LTE (VoLTE) Use Case -------------------------------- +- Lifecycle Management -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. + - Policy Based Filtering + - Bulk PM / PM Data Control Extension + - Support xNF Software Upgrade in association to schema updates + - Configuration & Persistency Service -**Figure 7. ONAP VoLTE Architecture** +- Security -|image6| + - CMPv2 Enhancements -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. +- Standard alignment -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. + - ETSI-Alignment for Guilin + - ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES + - Extend ORAN A1 Adapter and add A1 Policy Management -Read the VoLTE Use Case with ONAP whitepaper to learn more. +- NFV testing Automatic Platform -.. include:: blueprint-enr.rst + - Support for Test Result Auto Analysis & Certification + - Support for Test Task Auto Execution + - Support for Test Environment Auto Deploy + - Support for Test Topology Auto Design Conclusion ========== +The ONAP platform provides a comprehensive platform for real-time, policy- +driven orchestration and automation of physical and virtual network functions +that will enable software, network, IT and cloud providers and developers to +rapidly automate new services and support complete lifecycle management. -The ONAP platform provides a comprehensive platform for real-time, -policy-driven orchestration and automation of physical and virtual -network functions that will enable software, network, IT and cloud -providers and developers to rapidly automate new services and support -complete lifecycle management. - -By unifying member resources, ONAP will accelerate the development of a -vibrant ecosystem of VNFs around a globally shared architecture and -implementation for network automation–with an open standards focus– -faster than any one product could on its own. +By unifying member resources, ONAP will accelerate the development of a vibrant +ecosystem around a globally shared architecture and implementation for network +automation—with an open standards focus— faster than any one product could on +its own. +Resources +========= +See the Resources page on `ONAP.org `_ -.. |image0| image:: media/ONAP-DTRT.png - :width: 6in - :height: 2.6in -.. |image1| image:: media/ONAP-toplevel.png - :width: 6.5in - :height: 3.13548in +.. |image1| image:: media/ONAP-architecture.png + :width: 800px .. |image2| image:: media/ONAP-fncview.png - :width: 6.5in - :height: 3.409in -.. |image3| image:: media/ONAP-oom.png - :width: 2.28472in - :height: 2.30625in + :width: 800px +.. |image3| image:: media/ONAP-NetworkSlicingOptions.png + :width: 800px .. |image4| image:: media/ONAP-closedloop.png - :width: 6in - :height: 2.6in -.. |image5| image:: media/ONAP-vcpe.png - :width: 6.5in - :height: 3.28271in -.. |image6| image:: media/ONAP-volte.png - :width: 6.5in - :height: 3.02431in + :width: 800px +.. |image5| image:: media/ONAP-5G.png + :width: 800px +.. |image6| image:: media/ONAP-5GSuperBP-Integration.png + :width: 800px +.. |image7| image:: media/ONAP-vcpe.png + :width: 800px +.. |image8| image:: media/ONAP-bbs.png + :width: 800px +.. |image9| image:: media/ONAP-volte.png + :width: 800px +.. |image10| image:: media/ONAP-ccvpn.png + :width: 800px +.. |image11| image:: media/ONAP-mdons.png + :width: 800px +.. |image12| image:: media/ONAP-IntentBasedNetworking.png + :width: 800px \ No newline at end of file