2. Outline
• Why Quantum?
• What is Quantum – Live Demo!
• What is Quantum – Architecture
• Current Project Status
• Future Directions
• Frequently Asked Questions
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.
