ONAP: Orchestration for Real Results

A Guide to ONAP Architecture and Use Cases

hello@cloudify.co | cloudify.co
Table of Contents

Orchestration: Critical to NFV 2

ONAP: The Open-Source Orchestration Platform 4

What is ONAP? 4

The Architecture of ONAP Explained 4

ONAP First Use Cases: Proven Success 6

Voice over LTE (VoLTE) 6
Virtual CPE (vCPE) 7

Final Thoughts 7

Additional Resources 8
With the unstoppable growth of smartphone penetration, internet users, and global spending
through digital channels, the main question for the telco industry is becoming not when to
move toward cloud solutions, but how to do it and how to do so fast. Digitalization brings
services closer to the end user (by always being in their pockets), which in turn increases the
need for internet connectivity and thus also the demand for service availability and
accessibility. Service providers are therefore faced with the issue of needing to provide the
best possible service for all users at the same time as well as be cost-effective and profitable
companies.

All of this pushes most telco service providers to either use public cloud services (i.e.
Amazon​, ​Microsoft Azure​) or deploy their own private cloud, as cloud computing is seen as
the most effective and agile way to develop a network for the growing digital market. The
main challenge for service providers is to make their infrastructure more efficient by
decreasing time to market and also make it faster to react on any sudden increase of service
use.

The answer for service providers can be found in the use of software-based technologies
​ oftware-Defined Networking​) as well as open-source
(​Network Functions Virtualization​ or S
solutions, giving them the opportunity to build their own cloud solution. Plus, by using these
technologies, service providers also receive the added ability to program and automate their
networks in order to make them more responsive on different targeted events in network.

Orchestration: Critical to NFV

Decoupling software from hardware, enabling software to progress separately from the
hardware and vice versa, and providing the possibility to reassign and share infrastructure
resources are the main principles behind a virtual platform. In order to get a virtual platform
to handle all such network functions, it is necessary to add certain technical capabilities
including:

● Flexible network function deployment, providing the opportunity to deploy new

network services faster over the same physical platform depending on market needs
or a change in business requirements.
● Dynamic operation, offering greater flexibility and automation in the scaling of actual
virtual network functions​ according to the actual use of services.

All of the above mentioned capabilities form the basis of Network Functions Virtualization
(NFV) network architecture as defined by ​ETSI NFV​ Industry Specifications Group. ​The
basic reference architecture framework is shown in the figure below and features its most
important aspects​:

● Network functions are implemented as independent software components running on

common infrastructure or Virtualized Network Functions (VNFs).
 ● A virtualization layer abstracts the hardware resources into virtual resources making
them available for the applications according to a defined set of policy rules. The
virtualization layer and the hardware resources constitute the NFV Infrastructure
(NFVI).
● A Management and Orchestration (MANO) group of functionality manages the overall
set of resources, functions, and services to ensure appropriate automated resource
distribution, configuration, and fault handling.
● Element Management (EM) of virtual network elements as well as their interfaces
with Operational and Billing Support Systems are retained, thereby requiring a new
interface with the MANO layer.

Source:​ ​NFV network architecture

The whole architecture of ​NFV Management and Orchestration​ (MANO) consists of different
functions, with the main task being to maintain and control the virtual platform. The ​Virtual
Infrastructure Manager (VIM)​ is the part of MANO responsible for the allocation of physical
resources to the virtual resources in the NFVI. Together with the virtualization layer, the VIM
handles the full management of the virtual resources. A VIM typically has a scalability limit in
terms of the number of servers and the number of virtual machines it can handle, which is
the reason to have multiple VIMs.

The main responsibility of the ​VNF Manager​ is to follow the VNF cycle management of
instantiation, scaling, and termination of VNFs. Depending on the complexity of the network
function, the VNF Manager can be used generically for most virtual functions or can be
dedicated to a specific complex domain within the network. Lastly, the distribution,
reservation, and allocation of NFVI resources across multiple VIMs, the lifecycle
management of network services, and the policy management of all VNFs are the main
functions of the ​NFV Orchestrator​.
The key characteristic of such an architecture is that one pool of hardware resources is
utilized for all network functions, enabled by a virtualization layer, and governed by the
essential function of the NFV Management and Orchestration. MANO is also meant to
automate the provisioning, deployment, and operation of network services that utilize
resources in the virtual infrastructure. MANO is the element that will simplify and hide the
complexity of the underlying infrastructure resources, VNFs, and other resources in order to
implement end-to-end network services. In this way, service providers achieve a network
driven by applications rather than the underlying infrastructure.

ONAP: The Open-Source Orchestration Platform

What is ONAP?
ONAP​ stands for Open Network Automation Platform and is an open-source software
platform that gives capabilities for design, creation, and orchestration of services created on
top of individual Virtual Network Functions and Software-Defined Networking (SDN). ONAP
has been formed by combining code bases from Linux Foundation’s ​OPEN-O Project​ and
the ​AT&T ECOMP platform​. On one side, there was the OPEN-O project with the main goal
of giving us an open-source software framework for the orchestration of SDN and NFV. And
on the other hand, there was AT&T’s comprehensive virtual platform being developed with
more or less the same goal.

Having a foundation in these two projects and by using cloud technologies along with
network virtualization techniques to offer its services, ONAP has essentially answered the
rising need for a common platform that will deliver different network services on demand,
faster, and with greater operational automation. ONAP as an orchestration platform should
be an enabler for service providers to quickly deploy new features in the network, have
greater control of their network services, and reduce operating costs, giving developers a
proper playing field on which to create their own network services.

ONAP is off to a good start, as it is currently being supported as well as pushed by major
players in both the telco and IT sectors. The only concern is the complexity of having to
merge two already large projects.

The Architecture of ONAP Explained

ONAP as an open-source software platform provides the end user with the ability to organize
their network or cloud through the instantiation of virtual network elements and services in a
dynamic process and in real time in order to react to different events in network. This
platform boasts a robust design for modeling resources and policies that make up service,
orchestration, and control to slice network services when needed and provide valuable
analytics that closely monitor service behavior. ONAP thus offers a framework to design,
develop, and implement dynamic services across a service provider’s network or within its
own cloud.

Source: Cloudify

ONAP architecture consists of two major architectural frameworks with numerous

subsystems separated inside of them:

● Design-time environment
● Run-time environment

Design-time environment represents the development environment with all necessary

functions and libraries required for the development of new capabilities and the improvement
of existing ones through a portal, role-based interface and CLI. It is also used for operational
improvements via already developed services. As part of the design-time environment,
Service Design and Creation (SDC) is used as a visual tool for designing and modeling
assets used in all ONAP components. In order to make policies and conditional rules vital for
proper orchestration and management, a policy subsystem is also used as part of the same
environment.

Run-time environment is used for the execution of all policies and rules prepared in the
design-time environment. There are several subsystems running in this environment, but the
main functions are:

● Active and Available Inventory that maintains available resources and services along
with their relationships.
 ● Controller to represent the lower level of orchestration that manages the status of a
single resource (VNF or network).
● Data Collection, Analytics, and Events used for gathering performance, usage, and
configuration data.
● Master Service Orchestrator responsible for the automation of end-to-end service
and instance provisioning activities such as instantiation, release, and the migration
and relocation of the VNF.
● Security Framework based on a strong foundation inherited from the ECOMP
platform.

Finally, ONAP provides the solution to the increasing demand for a proactive response to
network events and service lifecycle management through a Closed Loop Automation
Management platform. ONAP thus enables service providers to ​manage the operational
lifecycle of virtual network functions as well as automate the process of deployment and control,
allowing for significant operational cost savings when compared to the legacy approach of
maintaining networks.

ONAP First Use Cases: Proven Success

The ONAP project is not only a developing solution for the orchestration and automation of
physical and virtual network functions but has also proven itself in real-world situations
where the platform can be used. The first platform release, called Amsterdam, introduced
two such use cases: Voice over LTE (VoLTE) and virtual CPE (vCPE).

Source: ​ONAP
Voice over LTE (VoLTE)
VoLTE​ stands for Voice over Long Term Evolution and represents the evolution of voice
service in the telco sector. If it is not yet deployed as a pilot or commercial service, VoLTE is
on the roadmap of every telco service provider out there. The technology utilizes IMS Core
and Evolved Packet Core network, delivering digital packet voice service via a 4G access
network. VoLTE implementation offers a variety of benefits for telco service providers looking
to achieve more efficient spectrum use, more reliable service, and better quality voice
service as well as the ability to fully incorporate video.

As a completely new service, VoLTE is a perfect use case for telco service providers to start
their transformation and implement it into a completely new virtual ecosystem. In this way,
they can develop their own private cloud, making it stable and reliable for the eventual
migration of legacy services as well as the development of new ones.

For the same reason, VoLTE is a perfect test case for the ONAP project as well. The ONAP
VoLTE use case combines virtual network functions to create virtual ​IMS​ and ​EPC​ services
(​vIMS and vEPC​), a vendor specific VNF Manager, and an element management system,
with everything deployed over two data centers using SDN.

This entire use case started with the design of vEPC and vIMS services via the import of
vendor specific VNFs into the ONAP platform, followed by the design of communication in
the virtual ecosystem between them (control and data paths) and, lastly, the preparation of
the end-to-end VoLTE service concept. In addition, to provide for automation, closed loop
has been planned to be triggered via an alarm from the VIM and element manager to ensure
that policies for self-healing are applied. With the design phase completed, run-time
environment takes over to deploy the initial setup and orchestrate the end-to-end VoLTE
service, giving the ability for data collectors to monitor and generate events on which the
ONAP platform can instantly react.

This is a very important use case for an open-source software platform such as the ONAP
project, since it was used to combine vendor specific VNFs through different domains and to
orchestrate an end-to-end complex service such as VoLTE.
 Source: ​ONAP

Virtual CPE (vCPE)

Traditionally, service providers deliver service to end customers by using end-user devices
called Customer Premises Equipment (CPE). CPEs are often used to provide one dedicated
service to the end user, making it difficult for service providers to deploy a new service over
the same box and for the end user to maintain the equipment. The ​vCPE​ concept allows for
the distribution of CPE functions, enabling service providers to keep some of the networking
and service-related functions and to roll out new services faster without any need for a
change in CPE. Also, this concept gives the end user less responsibility in maintaining CPE.

For this particular use case, the ONAP project used the Network Enhanced Residential
Gateway (NERG) concept specified by the Broadband Forum. This concept splits CPE into a
Bridged Residential Gateway (BRG) and a Virtual Gateway (vG). BRG is used for
connectivity with service providers and is still needed to be physically on the residential side,
while vG is a hosted in-service provider network providing network functions and services. In
this way, the service provider should have the possibility to offer on-demand services as well
as some value-added services.

This case did not require external VNF managers, element managers, or SDN controllers
since ONAP includes all of these functions in its framework. Besides vG and BRG (which
was emulated instead of a physical box), there was the need to design some of the generic
services in order to have a fully functional test that included vDHCP, vAAA, and vDNS.
Additionally, the end-user service has been designed as an independent vG VNF per each
customer, and certain triggers in closed loop have been defined for the monitoring of packet
loss. When a defined threshold is exceeded, the restart action of vG is triggered.
Cases like this showed that an open-source software platform such as ONAP has the
possibility to slice generic virtual network services and design end-to-end service, enabling
service providers to be more innovative in offering new services.

Final Thoughts
Moving to virtualization and deployment of a private cloud is not just cost effective but also
enables the service provider to become more agile and flexible in providing services to its
customers. ONAP gives them an open platform to address all the challenges they are
currently facing and also be prepared for new ones that are yet to come. The key to
incorporating all of cloud’s advantages and to quickly and easily implement the number of
new products and services available lays in the right choice of orchestration. Orchestration
should support multiple types of virtual functions, be vendor agnostic, allow for multiple
VIMs, and be programmable enough to offer a ​high degree of network automation​. Made on
a solid foundation, supported by major service providers and vendors, and boasting
numerous functions already, ​ONAP can be seen as a platform that delivers the end-to-end
orchestration needed for future development of private clouds in a cost-effective and flexible
manner.

Additional Resources
1. Deploying ONAP OOM on top of Kubernetes with Cloudify
2. ONAP Service Orchestration with Cloudify and ARIA
3. Multi-Cloud VNF On-Boarding via ONAP with Cloudify
4. ONAP Model-Driven Orchestration with TOSCA
5. Introduction to ONAP Webinar
hello@cloudify.co | cloudify.co