Objective

The Reference Architecture for Virtualised Cloud Infrastructure (RA1) specifies an OpenStack based Infrastructure-as-a-Service (IaaS) cloud architecture. The Reference Architectures define all infrastructure components and properties which have effect on the virtualised services  design, deployment, and operations. The RA1 document specifies the components of an IaaS cloud platform stack: a selection of OpenStack projects, the resources, and the interfaces exposed by a conformant IaaS cloud service to the workloads.

Problem Statement

Over the past few years, the telecom industry has been going through a massive technology revolution by embracing software defined networking and cloud architecture principles, in pursuit of the goal of achieving more flexibility, agility and operational efficiency. At a high level, the main objective of NFV (Network Function Virtualisation) is the ability to use general purpose standard COTS (Commercial off the Shelf) compute, memory and storage hardware platforms to run multiple virtualised network services (Virtualised Network Functions (VNF)/Cloud Native Network Functions (CNF)). Earlier common infrastructure models built on the previous assumption that networking applications are typically built on discrete hardware, do not offer the level of flexibility and agility needed for the support of newer networking technologies such as 5G, intelligent networks and Edge computing.

One of major challenges holding back the more rapid and widespread adoption of virtualised services (VNFs/CNFs) is that the traditional telecom ecosystem vendors, while building or designing their virtualised network services, are making their own infrastructure assumptions and requirements, often with custom design parameters. This leaves the operators being forced to either build complex integrations of various vendor/function specific silos which are incompatible with each other and might possibly have different and conflicting operating models, or work with the vendors to customise the virtualised services for operation on operator infrastructure. In either case, this makes the onboarding and conformance processes of VNFs/CNFs (coming from different vendors) very time consuming, costly and hard to automate and standardise.

Among the operators and service developers, there is a realisation that there are significant technical, operational and business challenges to the development and deployment of virtualised services related to the lack of a common cloud infrastructure platform. These include but are not limited to the following:

• Higher development costs due to the need to develop virtualised services on multiple custom platforms for each operator
• Increased complexities due to the need to maintain multiple versions of applications to support each custom environment
• Lack of testing and validation commonalities, leading to inefficiencies and increased time to market. While the operators will still do internal testing, but using an industry driven verification program based on a common cloud infrastructure would provide a head start.
• Slower adoption of cloud-native applications and architectures. A Common Telco Cloud may provide an easier path to methodologies that will drive faster cloud-native development.
• Increased operational overhead due to the need for operators to integrate diverse and sometime conflicting cloud platform requirements.

The need for a Common Telco Cloud Infrastructure model across the industry to facilitate more rapid adoption is clear. By running network applications as software rather on commodity rather than on purpose-built hardware, the operators aspire to realize operational efficiencies, and capital expense savings. These virtualised network services  are increasingly being used by telecom operators to support their internal and customer facing network infrastructures. The need for a Common Cloud Infrastructure model across the industry to facilitate more rapid adoption is clear.

Scope

The diagram below shows the different types of specifications and how they relate to the different elements of a typical cloud platform stack.

The RA1 document specifies:

OpenStack: the selection of OpenStack version and OpenStack projects that would be components of the cloud platform

OpenStack APIs: the API version for each of the selected OpenStack projects

Resources: the resources that shall be exposed to the workloads

Life Cycle Management (LCM): including but not limited to configuration management, logging, monitoring, and alerting.

The RA1 documentation is available here.