Introducing ONAP Architecture

Open Network Automation Platform (ONAP) Architecture White Paper

Executive Summary [Placeholder for Lisa]

1. Introduction The ONAP project was formed in March, 2017 in response to a rising need for a common platform for telecommunication, cable, and cloud operators—and their solution providers—to deliver differentiated network services on demand, profitably and competitively, while leveraging existing investments.

Prior to ONAP, operators of large networks have been challenged to keep up with the scale and cost of manual changes required to implement new service offerings, from installing new data center equipment to, in some cases, upgrading on-premises customer equipment. Many are seeking to exploit SDN and NFV to improve service velocity, simplify equipment interoperability and integration, and reduce overall CapEx and OpEx costs. In addition, the current, highly fragmented management landscape makes it difficult to monitor and guarantee service-level agreements (SLAs).

ONAP is addressing these problems by developing global and massive scale (multi-site and multi-VIM) orchestration capabilities for both physical and virtual network elements. It facilitates service agility by providing a common set of REST northbound APIs that are open and interoperable, and by supporting YANG and TOSCA data models. ONAP’s modular and layered nature improves interoperability and simplifies integration, allowing it to support multiple VNF environments by integrating with multiple VIMs, VNFMs, SDN Controllers, and even legacy equipment. This approach allows network and cloud operators to optimize their physical and virtual infrastructure for cost and performance; at the same time, ONAP’s use of standard models reduces integration and deployment costs of heterogeneous equipment, while minimizing management fragmentation.

The ONAP platform allows end customers and their network/cloud providers to collaboratively instantiate network elements and services in a dynamic, closed-loop process, with real-time response to actionable events. In order to design, engineer, plan, bill and assure these dynamic services, there are three (3) major requirements:

A robust design framework that allows specification of the service in all aspects – modeling the resources and relationships that make up the service, specifying the policy rules that guide the service behavior, specifying the applications, analytics and closed-loop events needed for the elastic management of the service

2

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.

The [Placeholder for Lisa]

[2.] ONAP Platform

ONAP platform is designed to provide global and massive scale (multi-site and multi-VIM) orchestration capabilities for both physical and virtual network elements. It facilitates service agility by providing a common set of REST northbound APIs that are open and interoperable, as well as supporting YANG and TOSCA data models. ONAP’s modular and layered nature allows 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 is architected to ensure it can support operators’ time to market service agility demands. To achieve this, it decouples the details of specific services and technologies from the common information models, core orchestration platform and generic management engines (for discovery, provisioning, assurance etc). Furthermore it marries the speed and style of a DevOps/NetOps approach with the formal models and processes operators require to introduce new services and technologies. This is in stark contrast to the traditional OSS/Management software platform architectures, which hardcoded service and technologies and required lengthy software development and integration cycles to incorporate changes.

The ONAP Platform enables product/service independent capabilities for design, creation and lifecycle management, in accordance with the following foundational principles:

Ability to dynamically introduce full service life-cycle orchestration (design, provisioning and operation) and service API for new services & technologies without the need for new platform software releases or without affecting operations for the existing services

Carrier-grade scalability including horizontal scaling (linear scale-out) and distribution to support large number of services and large networks

Metadata-driven and policy-driven architecture to ensure flexible ways in which capabilities are used and delivered

The architecture shall enable sourcing best-in-class components Common capabilities are ‘developed’ once and ‘used’ many times Core capabilities shall support many diverse services The architecture shall support elastic scaling as needs grow or shrink

3

These capabilities are provided using two major architectural frameworks: (1) a design time framework to design, define and program the platform (uniform onboarding), and (2) a runtime execution framework to execute the logic programmed in the design time framework (uniform delivery and lifecycle management). Figure 1 shows the ONAP Platform architecture.

Figure 1: ONAP Platform

2.[3.] ONAP ArchitectureFigure 2 provides a high-level view of the ONAP aArchitecture and microservices-based platform components. The platform provides the common functions (e.g., data collection, control loops, meta-data recipe creation, policy/recipe distribution, etc.) necessary to construct specific behaviors. To create a service or operational capability, it is necessary to develop service/operations-specific collection, analytics, and policies (including recipes for corrective/remedial action) using the ONAP Design Framework Portal.

4

Figure 2: ONAP Platform components (Amsterdam Release)

5

Should we use this picture instead, given where the discussion ended up at this week’s Architecture committee meeting?

3.[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 to be configured within the single ecosystem. This user experience is managed by the ONAP Portal, which provides access to design, analytics and operational control/administration functions via a shared, role-based menu or dashboard. The portal architecture provides web-based capabilities such as application onboarding and management, centralized access management, and dashboards, as well as hosted application widgets.

The portal provides an SDK to enable multiple development teams to adhere to consistent UI development requirements by taking advantage of built-in capabilities (Services/ API/ UI controls), tools and technologies. ONAP also provides a Command Line Interface (CLI) for operators who require it (e.g., to integrate with their scripting environment). ONAP SDKs enable operations/security, third parties (e.g., vendors and consultants), and other experts to continually define/refine new collection, analytics, and policies (including recipes for corrective/remedial action) using the ONAP Design Framework Portal.

UUI

4.[5.] Design time FrameworkThe design time framework is an integrated comprehensive development environment with tools, techniques, and repositories for defining/describing resources, services, and products. The design time framework facilitates re-use of models, further improving efficiency as more and more models become available. RAssets include models for resources, services and products. The models include various can all be modeled using a common set of process 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.

6

The design time framework supports the development of new capabilities, augmentation of existing capabilities and operational improvements throughout the service lifecycle. ONAP SDKs enable operations/security, 3rd parties (e.g., vendors), and other experts to continually define/refine new collection, analytics, and policies (including recipes for corrective/remedial action) using the ONAP Design Framework Portal. Certain process specifications (aka i.e., ‘recipes’) and policies are geographically distributed to optimize performance and maximize autonomous behavior in federated cloud environments.

To support and encourage a healthy VNF ecosystem, ONAP provides a set of VNF packaging and validation tools in the VNF Supplier API and Software Development Kit (VNF SDK) component. Vendors can integrate these tools in their CI/CD environments to package VNFs and upload them to the validation engine. Once tested, the VNFs can be onboarded through SDC. In the future, ONAP is developing a VNF logo program to indicate to operators which VNFs have gone through ONAP validation testing.

Service Design and Creation (SDC) is an integrated development environment withprovides tools, techniques, and repositories to define/simulate/certify system assets as well as their associated processes and policies. Each asset is categorized into one of four (4) asset groups: Resource, Services, Products, or Offers.

The SDC environment supports a multitude of diverse users via common services and utilities. Using the design studio, product and service designers onboard/extend/retire resources, services and products. Operations, Engineers, Customer Experience Managers, and Security Experts create workflows, policies and methods to implement Closed Loop Automation and manage elastic scalability.

To support and encourage a healthy VNF ecosystem, ONAP provides a set of VNF packaging and validation tools in the VNF Supplier API and Software Development Kit (VNF SDK) component. Vendors can integrate these tools in their CI/CD environments to package VNFs and upload them to the validation engine. Once tested, the VNFs can be onboarded through SDC. In the future, ONAP plans to develop a VNF logo program to indicate to users which VNFs have gone through formal ONAP validation testing.

The Policy Creation component deals with pPolices; these are conditions, requirements, constraints, attributes, or needs that must be provided, maintained, and/or enforced. At a lower level, Policy involves machine-readable rules enabling actions to be taken based on triggers or requests. Policies often consider specific conditions in effect (both in terms of triggering specific policies when conditions are met, and in selecting specific outcomes of the evaluated policies appropriate to the conditions). Policy allows rapid updates through easily updating rules, thus updating technical behaviors of components in which those policies are used, without requiring rewrites of their software code. Policy permits simpler management / control of complex mechanisms via abstraction.

The Closed Loop Automation Management Platform (CLAMP) provides a platform for designing and managing control loops. It is used to design a closed loop, configure it with specific parameters for a particular network service, then deploy and undeploy decommission it. Once deployed, a user can also update the loop with new parameters during runtime, as well as suspend and restart it.

5.[6.] Runtime Framework

7

The ONAP platform allows customers and providers to instantiated network elements and services in a significantly dynamic process with real-time response to actionable events. In order to design, engineer, plan, bill and assure these dynamic services, there are three (3) major requirements:

A robust design framework that allows specification of the service in all aspects – modeling the resources and relationships that make up the service, specifying the policy rules that guide the service behavior, specifying the applications, analytics and closed-loop events needed for the elastic management of the service

An orchestration and control framework (Service Orchestrator and Controllers) that is recipe/policy driven to provide automated instantiation of the service when needed and managing service demands in an elastic manner

An analytic framework that closely monitors the service behavior during the service lifecycle based on the specified design, analytics and policies to enable response as required from the control framework, to deal with situations ranging from those that require healing to those that require scaling of the resources to elastically adjust to demand variations.

The runtime execution framework executes the rules and policies distributed by the design and creation environment. This allows us to distribute policy enforcement and templates among various ONAP modules such as the Service Orchestrator (SO), Controllers, Data Collection, Analytics and Events (DCAE), Active and Available Inventory (A&AI), and a Security Framework. These components use common services that support logging, access control, and data management.

Orchestration The Service Orchestrator (- defined by process specifications that are executed by the SO) component executes the specified processes and- automates sequences of activities, tasks, rules and policies needed for on-demand creation, modification or removal of network, application or infrastructure services and resources. The SO provides orchestration at a very high level, with an end to end view of the infrastructure, network, and applications.

Controllers

Controllers are applications which are coupled with cloud and network services and execute the configuration, real-time policies, and control the state of distributed components and services. Rather than using a single monolithic control layer, operators may choose to use multiple distinct Controller types that manage resources in the execution environment corresponding to their assigned controlled domain such as cloud computing resources (network configuration (SDN-C) and application (App-C). Also, the Virtual Function Controller (VF-C) provides an ETSI NFV compliant NFV-O function, and is responsible for life cycle management of virtual services and the associated physical COTS server infrastructure. While it provides a generic VNFM, it also integrates with external VNFMs and VIMs as part of a NFV MANO stack.

DCAE and other ONAP components provide FCAPS (Fault Configuration Accounting Performance Security) functionality. DCAE supports data collectioncollects data from infrastructure, OS operating system (OS) and network applications, and supports correlation and analysis of events. It is the ecosystem component supporting analytics and events: it collects performance, usage, and configuration data; provides computation of analytics; aids in trouble-shooting; and publishes events, data and analytics (e.g., to policy, orchestration, and the data lake). DCAE identifies actionable conditions as defined during the design them. Closed loop control and higher-level correlation for business and operations activities are realized using DCAE (identifying actionable conditions), Policy to determine best possible corrective action and useing SO and the Controllers to execute the corrective action.

Inventory

Active and Available Inventory (A&AI) is the ONAP component that provides real-time views of a system’s rResources, sServices, pProducts and their relationships with each other. The views provided by Active and Available InventoryA&AI relate data managed by multiple ONAP pPlatforms, Business Support Systems (BSS), Operation Support Systems (OSS), and network applications to form a “top to bottom” view ranging from the pProducts end-users buy, to the rResources that form the raw material for creating the pProducts. Active and

8

Available InventoryA&AI not only forms a registry of pProducts, sServices, and rResources, it also maintains up-to-date views of the relationships between these inventory items.

To deliver the vision of thepromised dynamism of SDN/NFV, A&AI will manage these multi-dimensional relationships in real-time.

Active and Available Inventory is updated in real -time by the controllers as they make changes in the Domain 2 environment. A&AI is metadata- driven, allowing new inventory item types to be added dynamically and quickly via SDC catalog definitions, eliminating the need for lengthy development cycles.

6.[7.] Closed-Loop AutomationThe following sections describe the ONAP frameworks designed to address these major requirements. The key pattern that these frameworks help automate is

Design -> Create -> Collect -> Analyze -> Detect -> Publish -> Respond.

We refer to this automation pattern as “cClosed-loop automation” in that it provides the necessary automations toin proactively responding to network and service conditions without human intervention. A high-level schematic of the “cClosed-loop automation” and the various phases within the service lifecycle using the automation is depicted in Figure 4.

Closed-loop control is provided by Data Collection, Analytics and Events (DCAE) and other ONAP components. Collectively, they provide FCAPS (Fault Configuration Accounting Performance Security) functionality. DCAE cis the ecosystem component supporting analytics and events: it collects performance, usage, and configuration data; provides computation of analytics; aids in troubles-shooting; and publishes events, data and analytics (e.g., to policy, orchestration, and the data lake). Another component, “Holmes”, connects to DCAE and provides alarm correlation for ONAP.

Working with the Policy Framework and CLAMP, these components detect problems in the network and identify the appropriate remediation. In some cases, the action will be automatic, and they will notify Service Orchestrator or one of the controllers to take action. In other cases, as configured by the operator, they will raise an alarm but require human intervention before executing the change.

Figure 3: ONAP Closed Loop Automation

9

[8.] User ExperienceONAP includes a real-time dashboard, controller and administration tools to monitor and manage all of its components via an OA&M (Operations, Administration & Management) instance of ONAP. It allows the SDC to onboard ONAP components, create recipes, and allow the policy framework to define ONAP automation.

ONAP delivers a single, consistent user experience based on the user’s role and allows role changes to be configured within the single ecosystem. This user experience is managed by the ONAP Portal, which provides access to design, analytics and operational control/administration functions via a common role based menu or dashboard. The portal architecture provides web based capabilities including application onboarding and management, centralized access management, dashboards as well as hosted application widgets. The portal provides an SDK to drive 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).

[9.] Common ServicesONAP provides common operational services for all ONAP components including activity logging, reporting, common data layer, access control, resiliency, and software lifecycle management. These services provides 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.

7.[10.] Amsterdam Use CasesThe ONAP project uses operator real-world use cases to help focus our releases. For the first release of ONAP (“Amsterdam”), we introduce two new use cases: vCPE and VoLTE.

Virtual CPE Use Case

An important use case illustrating some of the key features and benefits of ONAP is the residential/consumer virtual CPE. 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.

I In this use case, the customer has a physical CPE (pCPE) attached to a traditional broadband network such as DSL (Figure 1). On top of this service, a tunnel is established to a data center hosting various VNFs. In addition, depending on the capabilities of the pCPE, some functions can be deployed on the customer site.

This use case traditionally requires fairly complicated orchestration and management, managing both the virtual environment and underlay connectivity between the customer and the service provider. ONAP supports such a use case with two key components – SDN-C, which manages connectivity services, and APP-C, which manages virtualization services. In this case, ONAP provides a common service orchestration layer for the end-to-end service. It uses the SDN-C component to establish network connectivity. Similarly, ONAP uses the APP-C component to manage the virtualization

10

infrastructure. Deploying ONAP in this fashion simplifies and greatly accelerates the task of trialing and launching new value-added services.

Read the Residential vCPE Use Case with ONAP whitepaper to learn more.

Voice over LTE (VoLTE) Use Case

The second new use case introduced indeveloped with Amsterdam is Voice over LTE. This use case demonstrates how a Mobile Service Provider (SP) could deploy VoLTE services based on SDN/NFV. The SP is able to onboard the service via ONAP. Specific sub-use cases are:

Service onboarding Service configuration Service termination Auto-scaling based on fault and/or performance Fault detection & correlation, and auto-healing Data correlation and analytics to support all sub use cases

ONAP will perform those functions in a reliable way, which includes:

Demonstrating the reliability, performance and serviceability of the ONAP platform itself security of the ONAP platform policy driven configuration management using standard APIs or scripting languages automated configuration audit and change management To connect the different dData centers, ONAP will also have to interface with legacy systems and physical function to establish VPN connectivity in a brown field deployment.

11

The VoLTE use case demonstrates the use of the VF-C component and TOSCA-based data models to manage the virtualization infrastructure.

Read the VoLTE Use Case with ONAP whitepaper to learn more.

Conclusion

The ONAP platform provides a comprehensive platform for real-time, policy-driven orchestration and

automation of physical and virtual network functions that will enable software, network, IT and cloud

providers and developers to rapidly automate new services and support complete lifecycle

management.

By unifying member resources, ONAP will accelerate the development of a vibrant ecosystem around a

globally shared architecture and implementation for network automation–with an open standards

focus–faster than any one product could on its own.

4

Clippings not intended for final paper

Overview of the Solution Architecture

To deliver these two core requirements, the architecture must include:

Generic Service, Device, and Resource models capable of supporting any network service or resource regardless of complexity, providing a dynamic Service Catalogue that can be readily consumed via API by Applications, OSS/BSS systems

Accurate, real-time (or as near real-time as is possible) inventory of service and available network resources and complete mapping between the two. The service inventory must also include all high level service assurance info that needs to be correlated to services and exposed via open API.

Service orchestration engine with common re-usable business logic that automates the full service lifecycle

Service API for service inventory, service intent based service design & provisioning, service assurance and any other supported orchestration function

Fully run-time programmable orchestrator:o Modeling of services and resourceso Dynamically rendered North Bound APIs for rapid integration with OSS/BSSo Dynamically auto-rending South Bound API’s for rapid integration with Networko Network integration (SDN controller, device, NMS, ... any system) o Dynamically auto-rendered GUI o Fully model-driven, generic management engines for (inventory, discovery, provisioning

and assurance) of network service and resources.o Plug-in and extensions that allow operators to develop advanced applications

Support integration of best-in-breed real-time OSS applications capable of delivering real-time inventory, provisioning, assurance and fully orchestrated closed-loop operations

Plug-in framework to support rapid development and runtime environment for advanced application to optimize the delivery of services and use of the network

A core platform that supports powerful concurrent distributed applications and is high performance, scalable, reliable and secure

Multi-tenancy support

ONAP supports a design framework and an execution framework. The design framework provides a collaborative environment for the design, creation, composition, versioning, repository, and publishing of comprehensive models that define the run-time behavior of the components in the execution framework. While the design framework ensures rapid introduction and reuse of models, their flexible composition, and their consistent distribution, the execution framework ensures their consistent enforcement and automates provisioning of composite service instances.

The Need for Open Orchestrator

5

As new SDN and NFV technologies are being introduced, and as the communication endpoints are becoming more diverse and agile, there is a need for an open source orchestrator that can manage these complex environments and provision composite end-to-end SDN and NFV services across physical and virtual resources, bridging between fixed and mobile communication endpoints. Such an orchestrator would provide the largest service providers with the platform to rapidly deliver complex value-added services. Furthermore, it would compensate for the shortcomings of some cloud management systems that lack the ability to support service provider’s services and SLAs, span multiple regional sites or domains (e.g., multiple VIMs) or create dynamic network connectivity across WANs. ONAP plays this role by providing a single point from which to compose, roll-out, and operate new services , taking advantage of SDN and NFV technologies across multiple software stacks, vendors, technologies, and domains. Furthermore, ONAP will provide clean abstraction layers based on layered “apps/services” and service intent demarcations, ensuring change isolation and minimizing operation disruption and risk.

One of the cornerstones of the ONAP framework is to leverage advanced software techniques such as abstraction and modeling of services and resources. Models in a generic sense also include process specifications and policies (rule sets) for controlling behavior and process execution. Model-driven frameworks enable introduction of new services and resources without the need for custom software changes or having to wait for new software releases. Ideally, models and policies would influence the behaviors of functions and systems without requiring rewrites of their software code. The goal of ONAP is to reduce initial and incremental effort to introduce new services and incorporate changes with maximum re-use without the long software development, integration and test cycles. The common data model aligns individual VNF modules, facilitating interoperability of multi-vendor components in a composite service scenario. It also facilitates re-use of models, with common capabilities developed once and used many times. For example:

When introducing a new service, if compared to an existing service only one attribute changes, the goal is that ONAP should require incremental modeling, integration & configuration work only for that new attribute. Past modeling, integration & configuration for other attributes should be reusable.

When introducing a new device software version, if compared to an existing device software version only one feature changes, the goal is that ONAP should require incremental modeling, integration and configuration work only for that new feature. If the feature has already been supported and modeled in a generic way and integrated with other device types, the modeling work should not be required. Past modeling, integration & configuration for other features should be reusable.

A second key requirement for ONAP is to ensure that end-to-end service requests are completed and selects the appropriate SDN domain controllers and NFV managers for each service component. ONAP decomposes an incoming request, performs proper placement to domain controllers, and retrieves the necessary rules for execution. The controllers are directed to instantiate resources within their scope according to the pre-defined service models, rule sets, and recipes. Furthermore, ONAP will also support a comprehensive service intent framework, where a global intent is shard across diverse,

6

autonomous domain controllers that scales out linearly by orchestrating the end-to-end traversal of diverse fabrics and interconnects.

A third key requirement for ONAP is to be scalable enough for support of the world’s largest tier-one infrastructures. One such example is the emerging IoT use cases, which require management of billions of fixed and mobile communication endpoints. The system is being built for deployment at the world’s largest network providers. ONAP is designed for maximum operational relevance and simplicity, as well as full coverage of service lifecycle (plan-build-operate), by supporting both legacy and new SDN/NFV infrastructures across domains and locations. To achieve its objective and address operators’ service agility requirements at scale, ONAP must be built on a core orchestration framework that is capable of supporting real-time automation across the full service life-cycle for any services and technologies. The proper hierarchy of orchestrators and controllers allows massive scale with maximum system performance. The end-to-end system is distributed on several levels, each with consistency of state for different abstractions, and careful mix of sharing desired state versus implementing local/instantaneous state.

Another cornerstone of ONAP is an accurate service and resource inventory, including a real-time view of services and network topology with status. The inventory component provides real-time registry and views of resources, services, and products, with their vertical mapping and horizontal service-chain associations. To achieve this, operators need an accurate, real-time, centralized, shared inventory system that combines the ability to discover and reconcile all information about services and resources in real-time. Central to the success of this shared inventory is the use of standardized open Information and Data Model embedded in the software (ETSI, TOSCA, YANG, etc.), across all ONAP modules and APIs where that inventory is the master source for all information about services, resource and the mapping between them. With this approach there is a single source of truth for ONAP to exploit and build advanced orchestration capabilities to automate across the full service-lifecycle. The common Data Models provide a much clearer set of requirements and models for VNF vendors to follow, thus increasing ease and speed of development and interoperability between their components.

Furthermore the core orchestration framework must be flexible to integrate with existing OSS modules (Assurance Applications, Inventory Database etc.).

Business Drivers in Carrier Networks

To remain competitive in the rapidly accelerating telecommunications environment, service providers need to address several business challenges, for which ONAP can help:

1) Increasing service agility, and the need to support new composite and value-added service types

Confronted with growing customer demand for advanced value-added services, service providers are increasingly turning to NFV and SDN for help to respond to their market needs. The low service agility of legacy OSS hinders the service providers’ ability to quickly design and deploy these new cloud-

7

centric composite service types. ONAP’s end-to-end integration of SDN and NFV technologies leverages the principles of modern model-driven systems to give service providers a platform for rapid introduction of complex and composite services.

2) Reducing CapEx/OpExThe rising operational and infrastructure costs of traditional network equipment on the one side,

and the flattening revenues on the other side, puts service providers under pressure. Many operators are unsatisfied with the current status of their service provisioning operations and the associated poor service and infrastructure agility. When activities are not automated and take too long to complete, their associated CAPEX and OPEX grow quickly. In fact, many operators’ annual IT expense (BSS/OSS, IT devices) has become comparable to their network investment. Squeezed between flattening revenue and rapid traffic growth and their associated infrastructure cost, service providers are eager to improve their service agility and reduce cost. By using common data models and integrating with multiple vendors’ equipment, coupled with its support for legacy equipment, ONAP helps operators reduce spending by providing a common platform for automation of service delivery and a migration path from legacy to SDN and NFV technologies.

3) Reducing service provisioning timesCurrently, some of the problems facing the service providers with respect to provisioning time are:

When introducing a new service, it usually can take more than 12 months, and far longer if a multivendor solution is required;

When upgrading or replacing network devices, OSS integration commonly takes more than 3 months;

When provisioning an existing service, it can take more than 1 week for residential service, and 6 weeks for enterprise private line or VPN service;

When customers experience problems or network outages occur, it can take significant effort and time to troubleshoot and diagnose the source;

By providing common interoperable northbound interfaces and a framework for supporting multiple southbound connections, ONAP decouples the service from the hardware, and thereby greatly reduces the time required for provisioning. The integrated ONAP also leverages rapid development of models to give service providers a platform for fast delivery of complex value-added services. Furthermore, enabling customer self-service through a web portal automation frontend leads to increased customer satisfaction and reduces order-to-bill time.

4) Reducing troubleshooting timesMany operators report that more than 50% of their trouble tickets are caused by human error.

Furthermore, when customers experience problems, or when unplanned network outages occur, with the existing systems it can take significant effort and time to troubleshoot and diagnose the source of the problem and take remedial action. A comprehensive orchestration platform such as ONAP can reduce troubleshooting times by allowing automated tools to rapidly solve many problems, while providing a holistic view of the network that can facilitate more rapid human intervention for harder-to-solve problems.

8

Figure 1) Virtual CPE Architecture

Why Open Source?

Open Source is a proven way used by the industry to create new “agreements” among vendors and operators. The open source approach has proven very successful for cloud, operating systems, SDN controllers and virtualization technologies. Cooperation among major industry players on promoting and developing an Open Source Orchestrator will deliver the following benefits to the community:

1) Unleash the full potential of the automation of service delivery and avoid market fragmentation

Open source is necessary to unleash the full potential of ONAP. It provides a forum for customers and suppliers to work together on a common platform, helping to deliver product-market fit. Without open source, vendors will compete to provide their own service orchestration and automation solutions, which will lead to many different abstraction and modeling approaches. This will either lead to a highly fragmented service delivery/orchestration market, requiring significant integration efforts to work in service providers’ environments, and slowing service velocity, or it will lead to just a few dominant solution offerings with their incompatible APIs (e.g., vendor lock-in). Open sourcing the code for a comprehensive services and applications orchestrator that meets the needs of the market standardizes on interoperable interfaces, becomes product and device agnostic, and brings people together to facilitate innovation.

9

2) Promote vendor and operator cooperation and minimize duplication of efforts, while enabling operators to better leverage community support

ONAP will leverage the open source community in order to facilitate adoption of a single ONAP framework, minimizing duplication of work among operators and vendors. The open source approach can provide the opportunity for vendors to cooperate and define the best abstraction and modeling methods for both services and devices. At the same time, service providers can adopt the common and community-tested open source ONAP solution, or any components of it, to meet their business needs. Compared to duplicated and fragmented OSS development, this constitutes significant savings for the industry as a whole. Note that even with the same ONAP solution, operators can still differentiate themselves based on different service catalogs, self-service portals, service logic, service composition, service pricing and business model, different network coverage, different accuracy of their resource database, etc.

3) Reducing integration and deployment cost of SDN and NFV through standard models and vendor pre-integration

With ONAP, vendors can pre-integrate their devices, unleashing savings in time and cost for both operators and vendors due to reduced integration work. When an operator wants to introduce a new device type, the previously time-consuming and costly integration is hugely mitigated. In comparison, if there are many orchestrator solutions, or if ONAP is proprietary, no or little pre-integration would be possible.

Furthermore, with pre-integration, each vendor’s device becomes plug-in for operator’s network. Operators gain in that they can plug in/out vendors easily. Vendors gain in that they can compete purely on the merit of their products without being skewed by a 3rd party OSS.

4) Easing the creation of complex composite services that can consist of several SDN and NFV elements

ONAP will leverage abstraction and modeling to make code reusable and simplify introduction of new service and device types. Service providers can make connectivity services more agile, and can quickly combine the network with other components (e.g. VAS Firewall or Cloud Computing & Storage) to deliver high-value, carrier class, differentiated services to customer.

5) Shorten time-to-market (TTM) for new services through faster system integrationONAP will accelerate the launch of new services through rapid system integration. With Traditional

network evolving to SDN and NFV, the integration of physical networks, virtual networks, and IT systems is becoming more complex. Through open source, it can accelerate the industry's de facto standard formation to solve the problem of multi-vendor systems integration with lower costs and shorter time. Open source can help form the de facto standard of a complex system integration environment (multi-vendor, interface and cross domains), which helps service providers achieve faster service TTM.

6) Faster revenue generationONAP will drive new revenue growth through one open ecosystem. Open source can help create

one open and collaborative service development & solution innovation platform. In order for service

10

providers to cross the digital transformation and compete with OTTs, an open and innovative ecosystem is required.

7) Quicker response to market needsThe traditional specification approach lacks the agility and speed to fulfill the consumer digital

experience. ONAP facilitates a much quicker development cycle, through rapid trial and error and recursive optimization of its code. This will ultimately help service providers capture the market in a more timely manner.

Additionally ONAP considers support for the most relevant industry standards and other open source projects on the basis of the value they offer in achieving its functions and the overall contribution they can bring to achieving service agility and reducing time to market.

1. ONAP Alignment with the SDN/NFV CommunityETSI NFV MANO and ONAP Alignment

The European Telecommunications Standards Institute (ETSI) developed NFV Management and Orchestration (MANO) Architectural Framework. NFV MANO has the role to manage the NFVI and orchestrate the allocation of resources needed by the Network Services and VNFs. The main components of the ETSI-NFV architecture are: NFV Orchestrator (NFV-O), VNF Manager (VNFM), and Virtualized Infrastructure Manager (VIM).

While ETSI NFV MANO focuses on orchestrating VNFs and managing the underlying NFV-Infrastructure (NFV-I), ONAP provides an end-to-end, open source platform that orchestrates and automates services over NFV-I, SDN, and legacy infrastructure.

ONAP also provide many functions not defined by the ETSI NFV ISG, including the service design environment/tooling, integration with OSS and BSS applications, Policy Management, closed-loop automation, user interface, catalogues, and much more.

Policy plays an important role to control and manage behavior of various VNFs and the management framework. ONAP also significantly increases the scope of ETSI NFV MANO’s resource description to include complete meta-data for lifecycle management of the virtual environment (Infrastructure as well as VNFs). The ONAP design framework is used to create resource / service / product definitions (consistent with MANO) as well as engineering rules, recipes for various actions, policies and processes. The Meta-data-driven Generic VNF managers allow us rapid on-boarding of new VNFs, avoiding long development and integration cycles and efficiently manage cross-dependencies between various VNFs. Once a VNF is on-boarded, the design time framework facilitates rapid incorporation into future services.

ONAP can be considered as an enhanced Generic VNF manager as described by MANO NFV Management and Orchestration Architectural Framework (see Figure 3).

11

Figure 4: Comparison of ETSI MANO and ONAP Architectures

12

In addition, ONAP subsumes the traditional FCAPS functionality as supported by EMSs in the MANO architectural framework. This is critical to implementing analytic driven closed loop automation across the infrastructure and VNFs, analyzing cross dependencies and responding to the root cause of problems as quickly as possible. To successfully implement ONAP, the Ve-Vnfm-vnf reference point (as well as Nf-Vi) is critical. It is in the industry’s interest for Ve-Vnfm-vnf interface to be standardized.

ETSI, TMF, MEF, among open source projects including the ONAP and OPNFV communities have been meeting informally to converge on a common approach for managing VNFs. ONAP’s approach is to document detailed specifications for such interface(s) to collect rich real-time VNF lifecycle and FCAPS management data in a standard format. This enables VNF developers to quickly integrate many diverse VNFs with the ONAP platform without long custom development work.

OPNFV and ONAP Alignment

The Linux Foundation introduced the Open Platform for NFV (OPNFV) in 2014. OPNFV is an open NFV reference platform that “facilitates the development and evolution of NFV components” . . . “through systems level integration, deployment, and testing.”

The OPNFV reference platform originated from the ETSI NFV ISG, with the intent of providing a reference platform to facilitate development of the NFV Infrastructure (NFV-I) along with the NFV MANO. A Continuous Integration/Continuous Deployment (CI/CD) infrastructure, essential for DevOps migration, was established, along with a global set of Pharos test labs to continuously test the OPNFV platform, which is also open to users interested in accessing the platform.

OPNFV provides a rich development environment that enables solution providers, software innovators, VNF developers, and network operators for conducting investigations, evaluations, validation, and benchmarking over open SDN and NFV components.

ONAP and OPNFV prove to be highly complementary. Whereas ONAP provides the platform that enables solution providers and network operators to create vertically integrated service delivery solutions, OPNFV provides a flexible development tool to facilitate development, testing, and integration.

Discussions are already underway to integrate ONAP (when available) into an upcoming OPNFV release.

MEF LSO and ONAP Alignment

The MEF (formerly Metro Ethernet Forum) forged the Lifecycle Services Orchestration (LSO) reference architecture. “LSO enables service providers to transition from a silo-structured BSS/OSS approach towards flexible end-to-end orchestration that unleashes the value of SDN and NFV.”

“LSO aims to streamline and automate the service lifecycle for coordinated management and control across all network domains responsible for delivering an end-to-end orchestrated service. The LSO RA describes the management entities needed to support LSO and the Management Interface Reference Points between them.”

ONAP is aligned with the LSO reference architecture, and provides the functionality and APIs specified in the Service Orchestration Function (SOF, referenced in the MEF-55 specification). ONAP is collaborating with the MEF on the LSO APIs for SOF to Northbound Business Applications (including OSS/BSS), Southbound Infrastructure Control and Management (including SDN Controllers), and East-West (including inter-domain coordination).

ONAP and MEF are also coordinating on an implementation of ONAP in the MEF, which integrates open source building blocks into an open platform for multi-vendor investigations, demonstrations, and testing.