The document discusses OpenStack Quantum, focusing on its capabilities for advanced networking in cloud environments to meet the sophisticated requirements of enterprise applications. Quantum facilitates creating virtual networks, managing switches, and integrating various networking technologies through a flexible plugin architecture. The presentation outlines current project status, future directions, and answers frequently asked questions regarding its implementation and comparison with existing solutions like Amazon VPC.

1. Intro to OpenStack Quantum
Dan Wendlandt – Quantum Hacker & PTL
dan@nicira.com
twitter - danwendlandt

2. Outline
• Why Quantum?
• What is Quantum?
– API
– High-level System Components
• Current Project Status
• Future Directions
• Frequently Asked Questions

3. Why Quantum?
Reason #1

4. Enterprise applications have sophisticated
networking requirements
Image curtsey of “the Hoff”:
http://rationalsecurity.typepad.com/blog/2008/08/all-your-virtua.html

5. Traditional “clouds” provide
little/no network control.
Example of Nova
Network “multi-NIC”.
Each VM gets VIF on
same two networks,
regardless of tenant.

6. Why Quantum? Reason #1
• To attract enterprise workloads, cloud must
give tenants the tools + control for enterprise-
class networking.
– Rich multi-tier topologies
– Insert services (FW, VPN, IDS, etc.)
– QoS guarantees for SLAs
– Security & Monitoring for compliance
• Quantum API can allows user control to build
advanced networking configurations.

7. Why Quantum?
Reason #2

8. Cloud Networking Challenges
• Cloud environments stress networks like never
before:
– High-density multi-tenancy
– Massive scale
– Strong price pressure.
– VM mobility
– EVERYTHING must be automated

9. New approaches are looking
to tackle these issues
• Software-Defined Networking / OpenFlow
• VXLAN / NVGRE
• * insert other solution here…. +

10. Why Quantum? Reason #2
• New technologies are needed to cope with
new challenges in cloud networking.
• Existing Nova implementation used basic
Linux Bridge + VLANs (very limiting)
• Quantum provides a “plugin” mechanism to
enable different technologies implement calls
made via the Quantum API.
• Choice is a good thing!

11. Why Do You Care?
• Cloud Provider / OpenStack consultants: Help
understand how Quantum can overcome
limitations of existing Nova networking.
• Network Vendor: learn how you can integrate
with or contribute to Quantum.
• Cloud User: Help is on the way!

12. What is Quantum?

13. Quantum Basics
Nova : virtual server
Quantum : virtual network
Quantum is:
- Expose a API for creating virtual networks and attaching
instances (e.g., nova servers) to those networks.
- Manage switches (virtual or physical) in the data center to
implement connectivity described via API.
- Provide a “plugin” architecture to leverage support using
different back-end technologies.

14. Quantum API Abstractions
• Networks:
– Equivalent to a “virtual VLAN”, a dedicated L2 segment.
– Tenants use Quantum API to create networks, get back UUID:
– Example: quantum.foo.com/<tenant-id>/network/<network-id>
• Ports:
– When an interface (e.g., Nova vNIC) is attached to a network,
attachment point is a “port”.
– Ports expose configuration and monitoring state (e.g., ACLs, QoS
policies, Packet Statistics)
– Example: quantum.foo.com/<tenant-id>/network/<network-
id>/port/<port-id>

15. Basic Quantum + Nova API Flow
API Client Quantum Nova Server
Create Network (POST /tenant1/network) Server
Network UUID: ‘abc’
Create Server (POST /tenant1/server)
Server UUID: ‘def’
Get Server Interface(s) (GET /tenant1/server/def/interface)
Server Interface UUID List: * ‘ghi’ +
Create Port on Network (POST /tenant1/network/abc/port)
Port UUID ‘jkl’
Attach Interface to port (PUT /tenant1/network/abc/port/jkl) , ‘attachment’ : ‘ghi’ -
Success

16. Old Model: Static Nova Networking
Nova i-23 Nova i-26 Nova i-22 Nova i-24
10.0.0.23 10.0.0.26 10.0.0.22 10.0.0.24
Tenant-A Net
• Single network exists (per-project or
global).
• VMs automatically get a vNIC on that
single network on boot.

17. New Model: Dynamic Network
Creation + Association
Nova i-23 Nova i-26 Nova i-22 Nova i-24
10.0.0.23 10.0.0.26 10.0.0.22 10.0.0.24
Tenant-A Tenant-A
Net #1 Net #2
Internet
• Tenant can use API to create many networks.
• When booting a VM, define which network(s) it
should connect to.
• Can even plug-in instances from other services
(e.g., a load-balancing service).

18. Quantum API Principles
• Implementation Abstraction: At no time does the customer see details of how a
network is implemented (e.g., VLANs).
• Explicit Association: Association of interfaces with network is an explicit step 
more control.
• API Extensions: Plugins can expose API extensions to introduce more complex
functionality (e.g., QoS). Extension support is queriable, so a customer can
“discover” capabilities.
• Extension Refactoring: API extensions that represent common functionality across
many plug-ins can become part of the core API.
• API Evolution: Core API is currently simple, focused on connectivity. Core API will
evolve.

19. Plugin Architecture
• “Quantum Plugin” design allows abstract
network/port API to be implemented using
many different technologies.
• Plugins perform two main tasks:
– Process all API calls: store the results of all
network + port calls, while mapping abstract
entities to a plugin-specific technology (e.g., map
a network to a VLAN)
– Manage switches: learn about nova interfaces
when they are attached to the network and
configure network switches accordingly.

20. Quantum Architecture
API Clients Quantum Server
Internal plugin
communication.
Uniform API Quantum Quantum
for all clients API Plugin
Tenant Create-net Create-net
Scripts . .
Nova Computeswitch
virtual
. . Nova Compute
Horizon Nova Compute
. . Nova Compute
Create-port Create-port Nova Compute
Nova
Interfaces from a service
like Nova plug into a
switch manages by the
API + Plugin = Quantum Service Quantum plugin.

21. Simple VLAN Plugin Example
• Plugin assumes all VLANs are trunked to all
hypervisors (similar to nova-network)
• When new q-network is created, creates a DB
entry mapping network to a free VLAN.
• Stores port + attachment mappings in DB.
• Runs agent on hypervisor to recognize new
vswitch ports that represent Nova interfaces.
• When new vswitch port appears, finds q-port + q-
network associated with interface-id, configures
vswitch port with correct VLAN.

22. Example Quantum + Nova Architecture
Dashboard /
Automation Tools
Tenant API Tenant API
Quantum Quantum API Nova Service
Service
nova-scheduler nova-api
Quantum Plugin
Internal nova
Communication
Two Plugins Available: nova-compute
- Open vSwitch
- Cisco UCS/Nexus
vswitch
XenServer #1
Internal Plugin
Communication Hypervisor

23. Key Take-away
• A “plugin” is NOT a “driver” *
• A “plugin” is NOT a “driver” *
• A “plugin” is NOT a “driver” *
• A “plugin” is NOT a “driver” *
• A “plugin” is NOT a “driver” *
• A “plugin” is NOT a “driver” *
• A “plugin” is NOT a “driver” *
• A “plugin” is NOT a “driver” *
* Explained on next slide….

24. A plugin is not a driver
• A plugin registers to handle all Quantum API
calls in a “group” (e.g., all network/port calls).
• Because Quantum only has one “group” of API
calls right now, only one plugin runs at a time
(this will change as APIs expand beyond L2).
• A single plugin may talk to multiple types of
switches (i.e., it may have multiple “drivers”)
• “driver” code can be shared across plugins.

25. Why separate plugins + drivers?
• Plugins may make decisions that are technology,
but not device-specific (e.g., mapping q-network
‘foo’ to VLAN 99).
• That decision must be made by only a single
entity… if multiple such decisions were made by
different plugins, they likely would conflict.
• The plugin may use drivers to communicate the
results of this decision to different devices (e.g., it
may configure the VLAN on a vswitch port, and
tell the upstream physical switch to trunk that
VLAN).

26. Current Project Status

27. Project Status: Essex Cycle
• Started at Diablo summit, became “incubation” for Essex,
will apply to be “core” in Folsom.
• Available at: http://launchpad.net/quantum
• Docs at: http://docs.openstack.org/incubation/
• Current Features:
– v1.1 of the Quantum L2 API, with extension support.
– API client library and CLI
– Nova Integration via the QuantumManager
– OpenStack Dashboard Integration (a bit borked right now…)
– Plugin framework & two publicly available plugins:
• Open vSwitch Plugin
• Cisco UCS/Nexus Plugin
• Linux Bridge Plugin
– Packaging for Ubuntu / Red Hat / Debian + more.

28. Project Status: Two Deployment Models
• Model #1 (available now):
– QuantumManager in Nova is only Quantum API client.
– Cloud admin must define networks with nova-manage.
– Tenant can place VMs on different networks using nova
extension (--nic option in nova client).
– Allows cloud provider to leverage advanced networking
technologies.
• Model #2 (few months out):
– Tenants can create their own networks, determine their
own IP addressing via Quantum API.
– Tenants can insert other services exposed by service
provider (e.g., router, VPN) using extensions.

29. Project Status: Who should use Quantum?
• “Early adopters” are already putting Quantum
into their OpenStack trial deployments.
• Expect early adopters to go live with Quantum
in spring / summer.
• Caution: deployments are by bleeding edge,
working closely with someone who knows
Quantum well.
• Folsom release will be first target for
widespread adoption.

30. Future Directions
• More L2 Plugins
– Linux Bridge, Ryu Controller, Nicira NVP, Brocade
• Beyond L2: Advanced Network Services
– L3 routing + NAT, Firewall, VPN, DHCP, LB
– Services may be part of Quantum, or separate
projects that integrate with Quantum.
– Additional services will be independently pluggable
(i.e., can choose L2 plugin X, L3 plugin Y)
• RBAC via API to allow for fine grain controls
among users of the same tenant.

31. Play with Quantum
• New integrated with DevStack
• http://wiki.openstack.org/QuantumDevstack
• Use nova-manage to create networks
• Spin up VMs with -- nic option.
• See Quantum Administrator Guide for details
– http://docs.openstack.org/incubation/openstack-
network/admin/content/

32. Frequently Asked Questions
• Is OpenFlow required for Quantum
– A: Nope! OpenFlow is just one technology that
Quantum enables.
• Is Quantum “software-defined networking”?
– It depends…
• How does Quantum compare to Amazon VPC?
– A: Have similar goal of enabling advanced networking
in cloud. Quantum will give cloud operators ability to
compete with (and go beyond) VPC feature-set.

33. Thanks! Questions / Comments?
Come join us:
http://wiki.openstack.org/Quantum
netstack@lists.launchpad.net
Dan Wendlandt
Dan@nicira.com
Twitter: danwendlandt
http://www.slideshare.net/danwent/