NetworkServiceDiablo

Network Service Proposal for Diablo

Overview

This proposal is the result of discussions between several community members that had independently submitted blueprints for networking capabilities in Openstack. Those proposals included:

(List proposals here)

This page describes the resulting target services to be delivered in experiemental form in the Diablo timeframe.

Network Services Model

The diagram below describes two things:

1. The software services architecture, and the relationship of the Virtual Network Service and IPAM Service to Nova
2. The logical network architecture elements used to describe a virtual network topology in the Diablo timeframe

(diagram goes here)

Network Services Actors

Nova Refactoring and Responsibilities

It is proposed that Nova networking be refactored in two ways:

1. Combine networking capabilities in a more contained model, but do not remove support for existing options
2. Add support for the Virtual Network Service to the existing flat (static), flat (DHCP), and VLAN options

Virtual Networking Service

(This project needs a name. "Quantum" was proposed.)

The Virtual Networking Service will have the following responsiblities for Diablo:

1. Provide API for managing L2 network abstraction (“virtual networks”?)
2. Provide authentication, verification, etc
3. Provide error handling
4. Decompose request (if necessary)
5. Dispatch requests to appropriate plug-in(s)
6. Resource consumption look-up service
7. Plug-in capability directory

Virtual Networking Service Plug-in

Plug-ins to the VNS will have the following responsibilities for Diablo:

1. Receive and verify requests from L2 Service
2. Map logical abstractions to actual physical/virtual service implementation/configuration
3. Advertise capabilities to L2 Service

IPAM Service

TBD

IPAM Servcie Plug-in

TBD

Container Service

The container service (if targeted in Diablo timeframe) will:

1. Provide an API for managing a container abstraction
   • Container represents a logical group of resources to be managed as a unit
   • Initial focus to be on networks and net services
2. Provide catalog of container “flavors”
3. Provide way to define container “flavors”
4. Provide way to instantiate instance of container “flavor”
5. Provide way to build container definition dynamically
6. Provide mechanism for modifying container instance at run-time.
7. Decompose request an communicate with other network services as required.