Quantum: Network Virtualization in the OpenStack Essex Release

This post is part of my notes from the 2/1 Boston OpenStack meetup.


David Lapsley from Nicira gave the Quantum presentation (his slides). My notes include additional explication and interpretation so he is not to blame for errors (but I’ll share credit for clarity).

The objective for Quantum is to replace the current networking modes (flat, vlan, dhcp, dhcp ha) with a programmatic networking API. The idea is that cloud users would use the API to request the network topology they wanted to implement rather than have it imposed by the infrastructure’s network mode. To accomplish this, the API must allow users to create complex & hierarchical network topologies without being aware of the underlying network infrastructure (aka “an abstraction layer”).

In simpler terms: Quantum allows users to design their own isolated networks without knowing how the network is actually deployed.

Quantum is a stand-alone service with its own API. It is not simply an extension of the Nova API. The Quantum API an extensibility model similar to Nova and it also has a plug-in architecture so that it can be implementation agnostic. The plug-ins are needed to map the user’s API abstraction into actual networking. For example, if the user requests a network tunnel between two VMs then the plug in may choose to implement a tagged VLAN, OpenFlow connections, IPtable filters, or encapsulated tunnels. The goal is that the implementation of the API should not matter to the user of the API!

For (hopefully) obvious reasons, the use cases the Quantum are similar to the Amazon EC2 VPC. The notable exception is service injection. Quantum wants to allow vendors/providers to innovate around value-added services. This should result in a diversity of choices as vendors offer additional network services such as load balancers, IPS, IDS, etc. While this is a great concept, it’s important to note that Quantum is currently limited to a single plug-in!  [see note in comments by Quantum PTL Dan Wendlandt (@danwendlandt)]

The expectation is that cloud users will want to create traditional application topologies with different tiers of access. For example, applications may require a dedicated network between web and database tiers or a DMZ between web and load balancer. The challenge is that these are patterns not rigid requirements. Ultimately, the simplest solution for the feature is to allow users to create “virtual VLANs.”

Essentially, the current Quantum API is creating virtual VLANs.

The Quantum API has four basic abstractions: interface, network, port and attachment. These primitives are used to build up a virtual network just as they are in physical networks.

  • Interface: cloud / tenant / server / GUID / eth0
  • Network: cloud / tenant / network / GUID
  • Port: cloud ID / tenant / network / GUID / port / GUID
  • Attachement : interface & network & port

To use the Quantum API, you must create a network, add ports (to network) and interfaces (to vms) then attach the network, interface, and port together. This gives users very fine grained control over their network topology. It is up to the plug-in to translate these primitives into a working physical topology.

According to my teammate and OSBOS organizer, Andi Abes, the Quantum API reached consensus in the community quickly because these it started with this basic but extensible API. In the meeting, I added that this approach is typical for OpenStack where it is considered better to demonstrate working core functionality than build extra complexity into the initial delivery. This approach links back to the API vs. Implementation debate I’ve discussed before. This simple API also provides room for innovation – while providing the basic constructs it is light, and does not encumber mappings of this API to different underlying technologies with lots of extras. OEM Vendors and service providers this have an easier time differentiating their offerings be it equipment or services.

In my experience, people often link OpenFlow and Quantum into a single technology base. I have certainly been guilty making that generalization. Quantum does not require OpenFlow or vice versa; however, they are highly complementary. OpenFlow takes over the switches’ “flow table” and allows administrators to control how every packet that touches the switch is routed. The potential for OpenFlow is to create highly dynamic and controlled network conduits. Quantum needs exactly that functionality to most directly map the virtual network requests into a physical fabric. In this way, OpenFlow is the most direct approach to building a fully enabled Quantum plug-in.

In the Essex release, progress has been made (and still is being made) towards integrating Nova and Quantum. The workflow of attaching a VIF (virtual interface) to the right network, and assigning it an appropriate IP (using Melange – the OpenStack IP address management project) are making headway. That said, the dashboard integration still lags and more progress is required.

Overall, my impression is that Quantum has great potential; however, I think that Nova in Essex will be sufficient for real applications without Quantum. As my freshman roommate used to say, “potential means you’ve got to keep working on it.”

This entry was posted in Andi Abes, Cisco, Meetup, OpenStack by Rob H. Bookmark the permalink.

About Rob H

A Baltimore transplant to Austin, Rob thinks about ways of building scale infrastructure for the clouds using Agile processes. He sat on the OpenStack Foundation board for four years. He co-founded RackN enable software that creates hyperscale converged infrastructure.

6 thoughts on “Quantum: Network Virtualization in the OpenStack Essex Release

  1. Pingback: OpenStack Boston Meetup 2/1 covers Quantum & Foundation « Rob Hirschfeld's Blog

  2. Fantastic write-up Rob! You did a great job of summarizing the goals and the current state of Quantum. Progress will move faster the more people who are contributing, so I’d encourage more people & companies to get involved.

    One minor nit. The blog states: “The notable exception is service injection. Quantum wants to allow vendors/providers to innovate around value-added services. This should result in a diversity of choices as vendors offer additional network services such as load balancers, IPS, IDS, etc. While this is a great concept, it’s important to note that Quantum is currently limited to a single plug-in!”

    Its actually possible to do service insertion already; its not really an issue of Quantum needing to support multiple plugins. Other services (e.g., Firewalls, load balancers, etc.) can be modeled as other services that “plug” into a port on a quantum network, just like a VM’s vNIC plugs into a port.

    If these services are implemented as VMs, this is trivial, as the service acts just like Nova. But it is even possible if those services are implemented in some other way. Take as an example how the Nova’s L3/NAT/Floating-IP functionality is “plugged” into a Quantum network. I also know of people adding services that enable Load-balancing, cross-data center connectivity, and other capabilities.


  3. Pingback: OpenStack Essex Deploy Day 3/8 – Get involved and install with us « Rob Hirschfeld's Blog

  4. Pingback: Wrap Up Blog Post: OpenStack Chat - Dell TechCenter - TechCenter - Dell Community

  5. Pingback: Wrap Up Blog Post: OpenStack Chat | ServerGround.net

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s