OpenStack Networking Service Blueprint

11/10/2010

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.

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.

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.

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.

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

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

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