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

Quantum

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.”