Abstract
The ever-increasing complexity of networks and services advocates for the introduction of automation techniques to facilitate the design, the delivery, and the operation of such networks and services. The emergence of both network function virtualization (NFV) and software-defined networks (SDN) enable network flexibility and adaptability which open the door to on-demand services requiring automation. In aim of holding the increasing number of customized services and the evolved capabilities of public networks, the open network automation platform (ONAP), which is in open source, particularly addresses automation techniques while enabling dynamic orchestration, optimal resource allocation capabilities, and end-to-end service lifecycle management. This chapter addresses the key ONAP features that can be used by industrials and operators to automatically manage and orchestrate a wide set of services ranging from elementary network functions (e.g., firewalls) to more complex services (e.g., 5G network slices).
TopIntroduction
The evolution of telecommunication networks towards on-demand services has raised the need for automation to facilitate the massive deployment of tailored services. The emergence of virtualization technology has clearly played a crucial role in this groundbreaking evolution. The introduction of cloud native principles when implementing network functions promises flexible and accurate management of both resources and services. Network operators can then instantiate virtual functions on the fly at various network locations as needed to meet customers’ requirements.
Today, End-to-End (E2E) network services can be conceived as a chain of Cloud-native Network Functions (CNFs), Virtual Network Functions (VNFs), Physical Network Functions (PNFs), or a combination thereof. The intrinsic principles of cloud native networks implemented as a bundle of microservices particularly enable network scalability, reliability, and agility. Microservices may be instantiated on Commercial Off-the-Shelf (COTS) servers, while these servers are distributed at different levels of the network.
To manage hundreds of servers, the widely adopted NFV architecture (ETSI-NFV, 2013) considers the so-called Virtualized Infrastructure Management (VIM). It particularly performs the allocation of computing, storage, and network resources. The VIM is also responsible for collecting and monitoring data. The VIM is part of the Management and Orchestration (MANO) framework proposed by the European Telecommunications Standards Institute (ETSI) (ETSI-NFV-MAN, 2014) where resides the Network Service Orchestrator functional block.
Beyond resource allocation, various challenges come with network virtualization and particularly with the required automation, e.g., VNF placement, multi-vendor solutions, VNF lifecycle management, monitoring automation, E2E orchestration, multi-domain and multi-cloud management, close loop automation, etc.
To address these challenges, ONAP was created in 2017 (ONAP, 2021b) as a result of a merger of OpenECOMP and Open Orchestrator (Open-O) solutions. ONAP is an open source project hosted by the Linux Foundation with contributions from major network operators (e.g., AT&T, China Mobile, Orange, Bell Canada, Deutsche Telekom, Vodafone, SwissCom, Telecom Italia, Telstra), main network vendors (e.g., Ericsson, Huawei, Nokia, Cisco, and ZTE), and IT integrators (e.g., Amdocs, IBM, Tech Mahindra). The full list of members can be found at (Members, 2021). The main goal set for ONAP is to develop a policy-driven orchestration and automation platform while considering a full lifecycle management of network services and their components, i.e., VNFs, CNFs, and PNFs. ONAP works in strong relation with standardization bodies as 3GPP, ETSI, IETF, and TMF in order to align the ONAP features to the available standards. Other orchestration platforms are under development such as Open Source MANO (OSM) which is particularly based on ETSI-NFV MANO (OSM, 2020) or Open Baton.
For network operators, ONAP enables orchestration, control, and automated operation of end-to-end network services. ONAP aims to simplify integration of multi-vendor equipment and products while reducing Capital Expenditure (CAPEX) and Operational Expenditure OPEX costs. ONAP additionally promises advanced monitoring and analytics in order to guarantee negotiated Service Level Agreements (SLAs). The dynamic negotiation can be performed between a customer and a service provider (namely, network operators) whose outcomes give rise to a customized service model and feed the orchestration logic to be addressed during the whole service lifecycle, i.e., ONAP enables to dynamically design and structure the service that best accommodates to the customer’s needs.
Supporting performance monitoring, control-loop automation, and service optimization is especially important when considering the virtualization of critical network functions that have to fulfill very stringent requirements in terms of latency and/or throughput. That is notably the case of mobile networks, especially when considering the Radio Access Network (RAN).
This chapter addresses the main features offered by ONAP (as per 2021) and introduces a set of illustrative use cases that evidence the strengths of this platform to manage end-to-end network services. The chapter is organized as follows:
Key Terms in this Chapter
Cloud Native Network Functions: Represents network functions designed and developed to be run on cloud infrastructures. CNFs follows the cloud native approaches defined in the Cloud Manifesto. CNFs are designed as microservices and executed in Docker containers. CNFs are also deeply integrated with automation tools to facilitate their lifecycle.
Model-Driven: Is an approach to fully separate what is expected from the execution. For the orchestrator, model-driven approaches avoid defining the set and sequences of actions to be executed via a workflow. The orchestrator analyzes the model, decompose it into a set of predefined tasks, and then run the different actions.
Network Function Placement: Is an optimization problem to select the hosting service to instantiate VNFs or CNFs. Placement strategy depends on various technical factors such as locations, capacity, affinity or anti-affinity rules, or other constraints (e.g., regulation ones). NF placement may be statically defined during the engineering phase or via policies that are dynamically executed during the handling of a service reques t.
Orchestrator: An orchestrator is usually based on a set of predefined models, policies, rules, or workflows and executes the required set of actions to deploy on-demand services. The goal of an orchestrator is also to guarantee that services run as expected. Different types of orchestrators are involved in the operation of network services. Some orchestrators focus on virtual resource layer such as OpenStack/Heat or Kubernetes, on network layer such as controllers like OpenDayLight while others like ONAP have a broader scope to cover end-to-end services while interacting with the vertical orchestration layer stack.
Automation Framework: A set of tools enabling to design models, policies or rules to be executed without manual intervention. An automation framework can focus on: policy framework, CI/CD, control-loop, workflow engine, tests.
Control Loop: Is a term coming from the industrial control systems and refers to an automation pattern where a system is able to react based on events received from network functions in a full automation way. In telecoms, a control loop is based on a set of predefined rules that are executed by an orchestrator to launch the required actions to fulfill service requirements. In general, a control loop starts with an event emitted by a network element and then a policy framework identifies the rules to be executed by controllers to correct the detected issue.
Policy: Is a set of rules defining actions to be executed. Typical policies include placement policies, scaling policies, or QoS-related policies.