The document outlines goals for an OpenStack Networking Service blueprint including providing networking as a first-class service and flexibility through plugins. The scope is for the networking service to manage connectivity and addressing while other services like compute, firewalls, and load balancers would consume it. A plug-in design is proposed to incorporate different networking solutions and customer-aware business logic to manage network creation and associations. Examples of use cases and interactions with other services are provided, along with a sample sequence of attaching a VM interface to a logical network.

1. OpenStack Networking Service
Blueprint
11/10/2010

2. Goals
• Networking as a first class service that can tie together
network “endpoints” from different services.
• Provide flexibility in networking implementations with
plug-ins that implement a generic network interface:
– Network segmentation/provisioning
– IP address management
– Business logic to determine what customers are
allowed to configure with networking.

3. Scope
• Network service only manages connectivity +
addressing, which are shared across services.
• Compute, Firewalls, Load Balancers, VPN, etc…
should be separate services, and would
consume the networking service.

4. Why?
• Why 1st-class service?
– Cloud is about orchestrating all kinds of services, not all will be
provided by compute VMs. Network must be able to tie
together all such services.
– Single integration point for networking logic, instead of having to do it
in each service.
• Why plug-in design?
– Want to incorporate “best-of-breed” networking solutions that solve
cloud networking challenges. Best solution may depend on provider.
– How and to what degree customers can manipulate networking will
depend on provider. Need customer-aware “business logic” to
manage things network creation, network associations, IP addresses.

5. Use Case Examples
• Private tenant network with VPN network
connection.
• Firewall service with interface on public
interface and interface on a private tenant
network.
• Multi-tier web application, web VMs have two
interfaces, one on public, one on private
backend network with DB servers.

6. High-level Interactions
Customer APIs
Network Service
Generic Network API
Compute Service
Network Plugin(s)
LB Service
Talks to
Compute Nodes
Talks to Network Devices
(vSwitches, physical switches, etc.)
Talks to LB Nodes

7. Example Sequence with VMs
• create “logical network”
– Logical networks are created on top of a physical “provider
network”
– Networks my be shared across tenants or private to a tenant,
etc.
• Attach VM interface to logical network
– VMs may have multiple interfaces.
– Other services (VPNs, physical hosts, firewalls can also be attached to
logical networks)
• Compute service would inform network service about what
compute node + port (e.g., tap0) corresponds to a VM interface
• Network service must orchestrate network (e.g., tag VLAN).

8. What’s Next?
• This is a long-term project. Want to get
started during Bexar.
• Plan to create group of interested parties for
detailed designed discussions, coordinating
coding.
• First goal will be to implement existing
OpenStack nova networking functionality as
“default plugins”.