Skip to main content

5 areas OpenStack needs help to support NFV

OpenStack isn’t an as-is solution for telco network functions virtualization (NFV) infrastructures. OpenStack is an open-source cloud management technology that provides many of the capabilities needed in any NFV environment. And this has prompted interest among many telco service providers.

But to realize the full benefits of NFV, service providers need NFV platforms that provide additional capabilities to support distributed clouds, enhanced network control, lifecycle management, and high performance data planes.

The OpenStack/NFV backstory

In 2010, RackSpace® and NASA jointly launched OpenStack®, an open-source cloud computing platform. Since then, the OpenStack community has gained tremendous momentum, with over 200 member companies.

Originally, OpenStack was not designed with carrier requirements in mind. So in 2012, a group of major telecommunication service providers founded an initiative to apply virtualization and cloud principles to the telecommunications domain.

The term network functions virtualization was coined for this initiative. Service providers called for vendors to build virtualized network functions (VNFs) and NFV platforms to help them become more agile in delivering services, and to reduce equipment and operational cost.

To address identified gaps in OpenStack and other relevant open source projects, major industry players established in September 2014 “Open Platform for NFV” as a Linux™ Foundation Collaborative Project. The intention is to create a carrier-grade, open source reference platform for NFV. Industry peers will build this platform together to evolve NFV and to ensure consistency, performance, and interoperability among multiple open source components.

There are 5 main areas in which OpenStack is currently lacking as a solution for telco NFV environments:

  • Distribution
  • Networking
  • Automated lifecycle management
  • NFV infrastructure operations
  • High performance data plane

1. Distribution

In the IT world, enterprises want to consolidate their datacenters to reduce costs. But this is not always the best choice for NFV. Many NFV applications require a real-time response with low latency. NFV applications also need to be highly available and survive disasters. Service providers need the flexibility to deploy network functions in a distributed infrastructure — at the network core, metro area, access, and possibly even a customer’s premises.

OpenStack supports Cells, Regions, and Availabilities Zones, but these concepts are not sufficient for the needs of NFV. Each OpenStack Region provides separate API endpoints, with no coordination between Regions. Typically, one or more Regions are located in one datacenter. The Cells component provides a single API endpoint that aggregates multiple regions.

With Cells, workload placement (“scheduling”) across cells is by explicit specification or by random selection. The Cells component doesn’t have a placement algorithm that is able to choose the best location based on the needs of the application.

The Horizon GUI is restricted to a single region at a time. There is no GUI able to show an aggregated view of the NFV cloud infrastructure. The OpenStack Glance virtual machine image manager is also limited to a single region. This means that the NFV operator would have to deploy images manually to the regions needed.

Bottom line: Service providers need a platform that will deal efficiently with the distributed NFV infrastructure necessary for low signal latencies and disaster resiliency. This infrastructure must also be manageable as a single distributed cloud with global views, statistics, and policies.

2. Networking

VNFs vary widely in their network demands. Because they are distributed throughout an NFV infrastructure, the baseline requirement for an NFV network is connectivity, both within datacenters and across WANs. Security dictates that different network functions should only be connected to each other if they need to exchange data, and the NFV control, data, and management traffic should be separated.

As network functions are decomposed – for example into data plane components and a centralized control plane component – network connectivity between these components needs to remain as highly reliable as traditional integrated architectures. Sufficient network resources should be available to ensure surging traffic from other applications cannot adversely affect NFV applications.

The network should be resilient against equipment failures and force majeure disasters. Latency and jitter requirements vary from hundreds of milliseconds for some control and management systems, to single digit milliseconds for mobile gateways and cloud radio access networks.

NFV networks will typically consist of a semi-static physical infrastructure, along with a much more dynamic overlay network layer to address the needs of VNFs. The overlay layer needs to respond quickly to factors such as changing service demands and new service deployments.

OpenStack Neutron is the OpenStack networking component offering abstractions, such as Layer 2 and Layer 3 networks, subnets, IP addresses, and virtual middleboxes. Neutron has a plugin-based architecture. Networking requests to Neutron are forwarded to the Neutron plugin installed to handle the specifics of the present network. Neutron is limited to a single space of network resources typically associated with an OpenStack region. It is unable to directly federate multiple network domains and manage WAN capabilities.

Bottom line: Service providers need a platform that will set up and manage local- and wide-area network (LAN and WAN) structures needed for carrier applications in a programmable manner

3. Automated lifecycle management

One of the greatest advantages of NFV as a software-based solution is its ability to automate operational processes. This includes the application lifecycle, from deployment to monitoring, scaling, healing and upgrading, all the way to phase out. Studies have shown that this automation will allow service providers to reduce operational expenses (OPEX) by more than 50 percent in some cases.

OpenStack Heat allows users to write templates to describe virtual applications (“stacks”) in terms of their component resources, such as virtual machines including nested stacks. Originally, Heat templates were based on AWS™ CloudFormation™, but more recently Heat Orchestration Templates (HOT) have been introduced that offer additional expressive power. Heat focuses on defining and deploying application stacks but does not explicitly support other lifecycle phases.

OpenStack Solum is a new project designed to make cloud services easier to consume and integrate into the development process. It is being designed to provide some of the missing lifecycle automation functions. There is some initial work on auto-scaling by combining the measurement capabilities of OpenStack Ceilometer with Heat. Heat is currently limited to a single OpenStack region.

Bottom line: Service providers need a platform that will automate not only deployment and scaling but also many other lifecycle operations of complex carrier applications with many component functions.

4. NFV infrastructure operations

The distribution of NFV infrastructures across many locations in a service provider’s network – as opposed to a few centralized locations - will pose specific challenges and impact the operational processes and support systems. NFV’s distributed infrastructure means that cloud nodes at different locations are added, upgraded, and/or removed more frequently than in a centralized cloud. These processes should be performed remotely whenever possible to avoid truck rolls across the coverage area.

OpenStack TripleO (OpenStack on OpenStack) is an experimental addition to the OpenStack family. The project aims at automating the installation, upgrade and operation of OpenStack clouds using OpenStack’s own cloud facilities. TripleO uses Heat to deploy an OpenStack instance on top of a bare-metal infrastructure.

Bottom line: Service providers need a platform specifically designed for a distributed NFV infrastructure, one that automates the complex software stack deployment and upgrade procedures.

5. High-performance data plane

Many carrier network functions (e.g., deep packet inspection, media gateways, session border controllers, and mobile core serving gateways and packet data network gateways) are currently implemented on special-purpose hardware to achieve high packet processing and input/output throughput. Running those functions on current off-the-shelf servers with current hypervisors can lead to a 10-fold performance degradation.

The industry is currently working on new technologies that have the potential to improve data plane performance on commercial off-the-shelf servers, in some cases to nearly the levels of special-purpose hardware.

Data plane performance, however, has been a fringe activity in the OpenStack community. Only recently, e.g., with the Juno release, more focus has been put on data plane acceleration. Juno offers support for requesting access for virtual machines to Intel®’s Single Root I/O Virtualization technology.

Bottom line: Service providers need a platform that will manage high-performance data plane network functions on commercial off-the-shelf servers.

Beyond OpenStack: What’s needed to make NFV work today?

Most service providers around the globe are looking for an open and multi-vendor NFV platform based on OpenStack. But as discussed, the OpenStack community is not strongly focused on some key NFV requirements. What’s missing is an NFV platform that goes beyond the scope of OpenStack to help customers realize reductions in CAPEX and OPEX, and improved service agility.

OpenStack is still under heavy development in many areas. As it matures, OpenStack will become more stable and richer in functionality, allowing it to better meet NFV requirements in certain areas. However, it is not expected to meet all requirements.

Service providers need a horizontal NFV platform that provides:

  • Compute, storage and networking resources for the VNFs
  • A centralized platform for NFV Orchestration (NFVO)
  • A centralized VNF Manager (VNFM) that manages the VNF lifecycles

This approach will make it possible to break open today’s multiple application silos.

This article is based on the Alcatel-Lucent/Red Hat white paper CloudBand with OpenStack as NFV Platform.

To contact the author or request additional information, please send an email to

Andreas Lemke

About Andreas Lemke

Andreas Lemke joined Alcatel-Lucent from the German National Institute for Integrated Publication and Information Systems (IPSI). While at Alcatel-Lucent, Andreas has held various positions in research, product and solution management, technology management and marketing with a continuous focus on the next generation of network innovation. Currently Andreas is a leading NFV industry evangelist heading up the marketing efforts for the CloudBand™ NFV platform. Andreas holds degrees in computer science from the University of Stuttgart, Germany, and a Ph.D. in Computer Science from the University of Colorado, Boulder, USA.

Article tags