PTL talk about Quantum at the Folsom summit.

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

2. Caveats
• Quantum is young: there are lots of things
that it WILL do, but doesn’t yet.
• Target of talk is Cloud Operators that would
deploy Quantum.

3. Outline
• Why Quantum?
• What is Quantum?
• Current Project Status
• Demo!
• Future Directions
• Questions

4. Why Quantum?

5. What is OpenStack?
• Open Source Cloud Software…
• A collection of “cloud services”
• Each service includes:
– A tenant-facing API that exposes
logical abstractions for consuming
the service.
– One or more backend
implementations of that API

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

7. Why Quantum?
• Networking was sub-component of Nova
• Two Key Problems:
#1: Limited technology “baked in” to design.
#2: No tenant control of networking.

8. Problem #1: Technology Limitations
• Cloud stresses networks like never
before:
– High-density multi-tenancy, massive scale
– Strict uptime requirements.
– Integrate with legacy hosting
environments / remote data centers.
– VM mobility
• Nova provides only basic technologies: Who needs private
networks?
– VLANs are only option for multitenancy
– Linux Bridge only Trunking all VLANs
– “network controller” node is centralized is a great idea!
single-point of failure for large networks.
- Stone Age Man

9. Why Quantum?
#1: Leveraging Advanced Technologies
• 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!

10. Problem #2: No Tenant Control
• 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
(“cloudbursting”).
“You can have any color as long
as its black.“
• Nova provides no tenant control: - Henry Ford about the Model-T
– No way to control topology.
– Cloud assigns IP prefixes + addresses.
– No generic service insertion.

11. Why Quantum? Reason #2
On-demand Enterprise-Class Networking
• Tenants can:
– create multiple private networks
– control IP addressing (bring your own!).
• Quantum API extensions enable additional
control:
– Security, Quality-of-Service, Monitoring +
Troubleshooting.
• “Advanced Network Services”
– Routers, Firewalls, VPN, IDS, etc.

12. Finally, Network-as-a-Service!
*-as-a-Service Capability OpenStack Service
Compute Nova
Swift (Objects)
Storage
Glance (Images)
Network Quantum

13. Why Quantum?
Quantum enables advanced network “engines”….
that let you leave Amazon VPC in the dust…

14. Why Quantum?
Questions?

15. What is Quantum?

16. Quantum Basics (by analogy to Nova)
Nova Quantum
*-as-a-service Compute Network
Major API abstractions “virtual servers”: represents “virtual networks”:
a host with CPU, memory, A basic L2 network segment.
disk, and NICs. “virtual ports”:
Attachment point for devices
connecting to virtual networks.
Interactions with other virtual servers use “virtual virtual ports are linked to vNICs on
OpenStack services. images” from Glance. “virtual servers”.
Supports different “virt-drivers” for KVM, “plugins” for Open vSwitch Cisco
back-end technologies XenServer, Hyper-V, UCS, Linux Bridge, Nicira NVP, Ryu
VMWare ESX Controller (and more!).
API Extensibility for keypairs, instance rescue, quality-of-service, port statistics,
new or back-end volumes, etc. security groups, etc.
specific features.

17. Basic API Abstractions
VM1 VM2 virtual server
Nova 10.0.0.2 10.0.0.3
virtual interface (VIF)
virtual port
Quantum Net1
virtual network
10.0.0.0/24
“virtual networks” are fundamentally
multi-tenant, just like virtual servers.

18. Quantum API Extensions
• Enables innovation in virtual networking.
• Add properties to existing network/port
abstractions (e.g., QoS settings on virtual
port, port statistics).
• Can introduce new API entities (e.g., Security
Groups that are linked to ports).

19. Old Model: Static Nova Networking
TenantA-VM1 TenantB-VM1 TenantA-VM2 TenantA-VM3
88.0.0.2 88.0.0.3 88.0.0.4 88.0.0.5
Public Net
88.0.0.0/18
• Single network exists (per-project or global).
• VMs automatically get a vNIC on that single network on boot.
• Tenants have no control over IP addressing.

20. Quantum Model: Dynamic Network
Creation + Association
TenantA-VM2 TenantA-VM3
TenantA-VM1
10.0.0.3 9.0.0.2
10.0.0.2
9.0.0.3
Tenant-A Net1 Tenant-A Net2
10.0.0.0/24 9.0.0.0/24
Public Net
88.0.0.0/18
• 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).

21. Quantum “Plugins”
• “Plugin” model give cloud operators choices:
– Advanced Features (exposed as API extensions)
– Cost / open vs. propriety
– Scale
– High Availability
– Hypervisor + Network HW Compatibility
– Manageability / Polish
• Abstract logical API
– tenants don’t see underlying technologies
– Example: VLANs vs. tunneling

22. Current Project Status

23. Project Status: Essex Cycle
• Started at Diablo summit, “incubated” for Essex, “core” in Folsom.
• Available at: http://launchpad.net/quantum
• http://docs.openstack.org/incubation/openstack-network/admin/content/
• Current Capabilities:
– v1.1 of the Quantum L2 API, with extension support.
– API client library and CLI
– Nova Integration via the QuantumManager (DHCP, L3/NAT)
– Plugin framework & several publicly available plugins:
• 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 .

24. Project Status: Two Deployment Models
• Admin-facing Quantum (available now):
– 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.
• Tenant-facing Quantum (Folsom Target):
– 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.

25. Project Status: Is Quantum “Ready”?
• “Early adopters” already putting
OpenStack
Quantum into production networking Panel
deployments (using Essex). today @ 3:50 in
Seacliff AB
• Many more are testing it out.
Interested in a
• Folsom release is target for general demo? Let me
know!
adoption. Planned to be default
networking option.

26. Future Directions

27. Folsom Priorities: Tenant Control
• Enabling tenant-facing network control.
– Keystone Integration
– New 2.0 API (with IP address management)
– Horizon Integration
– Improved CLI

28. Folsom Priorities: Network Services
• Quantum is not just about L2 networks.
• Essex already supports simple service insertion as VMs
• Enable Quantum APIs for advanced services:
– Quantum API extensions to control “service”.
– Pluggable back-end implementations.
• Achieve “Nova Parity” with L3/NAT + DHCP services:
– plugins can eliminates single-point-of-failure and bottlenecks of
existing nova-network implementations!
– Programmatically build rich L2 + L3 topologies.

29. Service Example: “virtual NAT router”
• API to create/manage “instances”
– POST /router/
• Create router, specify NAT/forwarding configuration.
– PUT /router/<uuid>
• Modify router later.
– POST /router/<uuid>/interface
• Specify network that this interface is attached to.
• On demand creation of rich L2+L3 topologies.

30. Folsom Priorities: Growing the
Quantum Community
• Growing Development team
• Networking Vendors:
– Many planning new plugins.
• OpenStack Integrators/Distros:
– Get them up to speed on Quantum early.
– Improve packaging, install processes.
• OpenStack Users/Operators:
– Improving documentation, help + support channels.
– Let’s work together to stand it up!

31. Key Takeaways
• Enterprise-class OpenStack networking is here:
– Leveraging advanced technologies.
– Tenant control of networking.
• Enable you as a cloud operator to not just copy
Amazon VPC, but to innovate beyond that.
• Quantum is in production today at early adopters.
• Folsom is target for widespread deployment.

32. Thanks!
Questions?
Dan Wendlandt – Quantum Hacker & PTL
dan@nicira.com
twitter - danwendlandt

33. Bonus Slides

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

35. Plugins: A tiny bit of technical detail…
• Define “quantum plugin”:
Code that communicates with network devices to
implement a particular set of Quantum API calls.
• API currently has one set of calls for “base L2”
networking => one plugin running at a time.
• A plugin is not a “driver”. A single plugin can talk
to different types of network devices.
• Future: will support multiple plugins that expose
different APIs (e.g., “virtual networks” vs. “virtual
firewalls”)

36. Quantum 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

37. Quantum 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

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

39. 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
nova-compute
vswitch
XenServer #1
Internal Plugin
Communication Hypervisor

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