Quantum, part of the NetStack suite, provides “Network Connectivity as a service” to instances running in Openstack clouds.

What Quantum is, and why one would need it

Quantum is a standalone Openstack Service aimed at providing Layer-2 network connectivity for VM instances running in clouds based on the Openstack cloud fabric. It exposes a generic (i.e.: technology-independent) and extensible API allowing users to build and manage their networks, and uses a pluggable architecture, thus enabling different technologies to implement the logical abstractions exposed by the API.

It can be therefore regarded as the fundamental building block for cloud networking services for Openstack, as consumer will be able to create the network topologies required for deploying their applications in the cloud, and build higher-layer network services, such as VPN access, Firewall, or Load Balancing, on top of the virtual networks defined by Quantum.

Moreover, thanks to its pluggable infrastructure, the abstractions exposed by its API can be implemented by a number of technologies, thus enabling innovative plugins dealing with common cloud networking problems, such as VLAN limits, or leveraging ground-breaking technologies for networking in highly virtualized environments, such as VEPA or InfiniBand.

How it works

The design goals behind Quantum development can be summarized as follows:

  • It must be decoupled from nova and other services; communication should happen only via well-defined REST APIs;
  • It should be able to run even without nova; this implies it should be generic enough to be plugged also in other cloud computing fabrics;
  • It must be flexible enough to support plugins employing a wide range of technologies.

The Quantum service includes two components, reported in the following figure.

Overview of Quantum architecture

The Quantum-common component exposes the tenant-facing API, and provides typical services such as Authentication, Authorization, and Rate Limiting, whereas the Plugin component contains the actual implementation of the API; the plugin is responsible for directly managing the network, or acting as a proxy towards another entity which manages the network, in order to enforce the configuration required for satisfying requests made by tenants through the API. According to the particular technology it employs, a plugin can either manage just the network edge, for instance a virtual switch such Open vSwitch, or control all network devices, including, for instance, physical network switches.

Quantum must work in conjunction with Nova. This implies that either nova should be able to plug virtual network interfaces for instances it creates into Quantum networks, or that Nova should be able to inform Quantum whenever a new virtual network interfaces is created, so that the Quantum service will be able to plug it into the appropriate network. This issue, also known as the “edge-binding” problem is currently still being discussed; both approaches have their positive and negative aspects.

The Quantum API

Tenants can create and manage their network using the Quantum API, which is divided into a “core“, exposing the minimum set of functionalities that each plugin must implement, and “extensions“, which are plugin-specific and can be used by tenants to leverage particular plugin capabilities such as, for instance, ACL or QoS policies.

The core API allows for creating networks, configuring logical ports for them, and plugging/unplugging network interfaces into networks. The complete specification of the API is available on the Openstack wiki, together with a set of sequence diagrams explaining how the API can be used in several common use cases, such as spawning a VM and attaching its interfaces to Quantum networks.

Work on the extension APIs is still in progress; however, API extensions will allow plugin to define new resources (for instance a port profile), extend existing resources, for instance by adding the concept of operational state to a port, or define new methods for existing resources, for instance by adding a method for enabling port isolation for a given logical port.

The core API currently defines a very simple data model, as it manages a very limited number of entities (network, port, interface), and each entity has a very limited number of attributes. As the projects becomes more mature, it is likely that resources, attributes, and operations which are now regarded as extensions will become part of the core API.

Current development status

Quantum is currently under development. At the time of writing the following components have been implemented:

  • Core API
  • Plugin based on Open vSwitch
  • Test harness

Work on API extensions is in progress, and there’s already some code available, just as work on authentication and authorization. Quantum will probably use KeyStone, the new identity service being developed for Openstack, although it might be possible to configure it to use different authentication mechanisms.

Apart from the Open vSwitch plugin, two other plugins have been proposed for implementation in the Open Source project: a plugin for creating virtual networking using ‘traiditionals’ VLANs on top of Linux Bridge, and a plugin for mapping the quantum logical model to infiniband switches.

Quantum development trunk can be downloaded from the launchpad website. A guide for configuring Quantum with the Open vSwitch plugin can be found in the README file in Quantum/plugins/openvswitch in the source code tree.

Plans for the Diablo Timeframe

A first release of Quantum should be available by the time Openstack Diablo is released (September 22nd). It will include the following features:

  • A plugin-agnostic API
  • A mechanisms to allow plugins to register extensions
  • Authentication and authorization
  • At least one Open Source plugin to be used to experiment with Quantum
  • Full integration with nova (although it will not replace nova-network)

References: