This document provides an overview of OpenStack Quantum, the networking component of OpenStack. It discusses the history and motivation for Quantum, including limitations of the original networking model. The document describes the key aspects of the Quantum architecture, including the plugin framework and ability to support different networking technologies. It also provides an update on the project status as of the Essex release and previews upcoming capabilities for the Folsom release.

1. OpenStack Quantum
Past, Present & Future
Somik Behera
Founding Member- OpenStack Quantum
Twitter: @strikesme

2. Outline
• Why Quantum?
• What is Quantum – Live Demo!
• What is Quantum – Architecture
• Current Project Status
• Future Directions
• Frequently Asked Questions

3. In the beginning..
*-as-a-Service Capability OpenStack Service
Compute Nova
Swift (Objects)
Storage
Glance (Images)
Network
?

4. Why Quantum?
• Networking API strongly coupled as part of
Nova(Compute) APIs
• OpenStack Networking model was very rigid.
– Flat Networking
– FlatDHCP Networking
– Or VLAN-based Networking model
– One- Size fits all use-cases.
• No support for integrating external NW services like
best of breed Firewall and Load Balancers.
• No “pluggability” in the Networking Architecture to
take advantage of best of breed vendors or emerging
SDN techniques.

5. Problem #1: Stone-age technology
• Cloud stresses networks like never before:
– High-density multi-tenancy, massive scale
– Strict uptime requirements.
– Integrate with legacy hosting environments /
remote data centers.
– Price pressure to use commodity gear.
– VM mobility
• Nova provides only basic technologies:
– VLANs are only option for multitenancy
– Used simple Linux Bridge (no advanced
QoS, ACLs, or monitoring)
VLANs are Great!
– “network controller” node is centralized - Stone Age Man
single-point of failure for large networks.

6. Why Quantum? Reason #1
Advanced Technologies & Choice!
• New networking technologies are emerging to try and
tackle these challenges.
– Software-defined Networking (SDN) / OpenFlow
– Overlay tunneling: VXLAN, NVGRE, STT
– Fabric solutions: FabricPath, Qfabric, etc.
– [ insert other solution here ]
• Quantum provides a “plugin” mechanism to enable
different technologies implement calls made via the
Quantum API.
• Choice is a good thing!

7. Problem #2: Rigid Networking model
• Cloud tenants want to replicate rich
enterprise network topologies:
– Ability to create “multi-tier” networks
(e.g., web tier, app tier, db tier)
– Control over IP addressing.
– Ability to insert and configure your
own services (e.g., firewall, IPS)
– VPN/Bridge to remote physical hosting
or customer premises.
• Nova provides no tenant control: “You can have any color as long
– No way to control topology. as its black.“
- Henry Ford about the Model-T
– Cloud assigns IP prefixes + addresses.
– No generic service insertion.

8. Why Quantum? Reason #2
Flexible Enterprise-class Networking!
• Base Quantum API lets tenants create multiple
private networks, control IP addressing on them.
• Quantum API extensions enable additional
control:
– Security & Compliance Policies
– Quality-of-Service
– Monitoring + Troubleshooting
• “Advanced Network Services” such as
firewall, intrusion detection, VPN, can be inserted
either as VMs that route between networks, or as
API extensions.

9. All is Right with the World…
*-as-a-Service Capability OpenStack Service
Compute Nova
Swift (Objects)
Storage
Glance (Images)
Network Quantum

10. OpenStack Quantum Demo! – Complex Enterprise Apps
Tenant Coca-Cola Enterprise App
Data2-net ExtendNet VM
Tenant Pepsi Enterprise App
Data2-net ExtendNet VM
VM Data2-net ExtendNet VM
VM
VM VM VM VM VM
VM Data1-net
VM VM VM VM VM
VM VM VM VM VM Data1-net
VM VM VM VM VM
VM VM VM VM VM Data1-net
VM
Mgmt-net VM VM VM VM
Mgmt-net
Mgmt-net

11. OpenStack Quantum – Architecture
Basics
• During demo tenant didn’t see the technology used to
implement L2 isolation (VLANs, tunneling, etc.).
• Key tenets:
– Abstract logical API
– “pluggable engine” back-end gives choice.
• Pluggable engines will give operators choice of:
– Advanced Features
– Cost
– Scale
– High Availability
– Hypervisor + Network HW Compatibility
– Manageability / Polish

12. Quantum ‘Engine’ Architecture – Simple
API Clients Quantum Server
Internal plugin
Quantum communication.
Uniform API
for all clients API Quantum
Plugin
Tenant Create-net
Scripts . Create-net
virtual switch
Nova Compute
. .
Horizon Nova Compute
. . Nova Compute
Create-port Nova Compute
Nova .
Create-port
Interfaces from a service
API like Nova plug into a
Extensions DB switch manages by the
Quantum plugin.
API + Plugin = Quantum Service

13. Quantum ‘Engine’ Architecture -
Advanced
External
API Clients Quantum Server Manager
DB
Internal plugin
Uniform API Quantum
communication.
for all clients API Quantum
Plugin
Tenant Create-net
Scripts . Create-net
virtual switch
Nova Compute
. .
Horizon Nova Compute
. . Nova Compute
Create-port Nova Compute
Nova .
Create-port
Interfaces from a service
API like Nova plug into a
Extensions DB switch manages by the
Quantum plugin.
API + Plugin = Quantum Service

14. OpenStack Folsom Architecture with
Quantum
COMPUTE NODE
• OpenStack
Architecture
as of Essex
• Network
components are
passed from Nova
to Quantum QUANTUM MGR
• In Folsom, Layer DHCP L3/NAT
3/NAT/DHCP will
move from Nova QUANTUM
to Quantum. PLUG-IN

15. Project Status: Essex Release
• Started at Diablo summit, “incubated” for Essex, “core” in Folsom.
• Available at: http://launchpad.net/quantum
• Docs at: http://docs.openstack.org/incubation/
• Current Capabilities:
– v1.1 of the Quantum Layer 2 API, with extension support.
– API client library and CLI
– Nova Integration via the QuantumManager
– Pluggable Engine Framework
• Open vSwitch Plugin
• Cisco UCS/Nexus Plugin
• Linux Bridge Plugin
• Nicira Network Virtualization Platform (NVP)
• Ryu OpenFlow Controller
– Integrated with “devstack” (see:
http://wiki.openstack.org/QuantumDevstack)
– Packaging for Ubuntu 12.04 / Fedora 17 / Debian .

16. Project Status: Two Deployment Models
• Proxied Quantum (available as of Essex release):
– 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, but doesn’t give tenant’s network control.
• Direct Quantum (available in Folsom release):
– Tenants can create their own networks, determine their own IP
addressing via Quantum API.
– Tenants can insert other logical services exposed by service
provider (e.g., router, VPN) using extensions.
– Requires Keystone Authn/Authz for API and a tenant API for
IPAM (i.e., Melange)

17. Project Status: Who should use Quantum?
• “Early adopters” already putting Quantum into
trial & production OpenStack deployments.
• Caution: Deployments are by people at the
cutting edge, require significant familiarity with
Quantum.
• Folsom release will be targeted for widespread
adoption.

18. How do I use OpenStack Quantum?
• Now integrated with DevStack
• http://wiki.openstack.org/QuantumDevstack
• Use nova-manage to create networks (i.e.
proxied mode)
• Spin up VMs with -- nic option.
• See Quantum Administrator Guide for details
– http://docs.openstack.org/incubation/openstack-
network/admin/content/

19. Folsom Direction
• Tenant Control of Networking
– Keystone Authn, Authz
– Expose IPAM to tenants (Integrate Melange project)
– Nova Integration enhancements
– Horizon integration, CLI rewrite.
• Move networking from Nova to Quantum
– L3 Forwarding + NAT/Floating IPs,
– Security Groups
– DHCP injection
• Follow Quantum pattern:
– Enable tenant control by extending existing API
– Allow pluggable backends ‘engines’

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

21. Thanks!
somik@nicira.com
Twitter: @strikesme