Jump to: navigation, search


< Neutron
Revision as of 13:28, 30 October 2012 by Salvatore (talk)

This page contains the design spec for the service insertion blueprint. Despite being quite fleshed out the spec is not finalised yet, as some details are still subject to change, especially as far as the implementation plan is concerned. Please subscribe to this page to get every update, or check it as often as necessary. The blueprint itself can be found at this address:

This specification does not fully respects the blueprint template set for Quantum. This is because we are giving much more space to the design discussion. We will have another wiki page using the blueprint template once the design discussion is Finalied.

High level description

The service insertion feature aims at defining a framework for running L4/L7 network services on Quantum Logical Topologies. This framework will be immediately leveraged by the LBaaS effort; and in the near future by other advanced services which will be plugged into Quantum (for instance, VPN, and edge firewalls).

What Service Insertion means

Before going in depth into design and implementation discussion, it might be worth to define in a detailed way what an advanced service is, and how it could be inserted in the Quantum logical topology. The diagram below show Quantum's basic network topology, with a logica router interconnecting internal and external networks; ports, which are used for VIF, DHCP server, router, and floating IP attachments are also shown in the diagram.


From previous discussions it emerged that services can be inserted in the following modes:

  1. Routed mode - Where the service is attached to a logical router, which then becomes a multi-service appliance


  1. Floating mode - Where the service run in a standalone way. Please note that the "Floating" insertion is not automatically a network level insertion, as L3 routing might still occur.
    In particular, the second model could be reduced to the first assuming that a standalone service is regarded as a peculiar case of router capable of providing only a specific service.


Scope of this blueprint

This blueprint which focuses on:

  • Providing the infrastructure for allowing implementations of these services to serve API requests; multiple implementations for each class of service should be allowed to coexist at the same time in a Quantum deployment.
  • Defining a set of API calls (as well supporting logic and data model) for defining which, where, and how services might be attached on the logical topology defined by the basic Quantum topology;
  • Allowing providers of such services to expose implementation-specific service extensions and advertising them to API users.

Defining which services might be inserted, and how they should be presented to tenants is beyond the scope of this blueprint. Activity is already ongoing for the Load Balancing service; for more information please refer to lbaas-* blueprints in the Quantum framework.

Most of the concepts expressed in this blueprint are not new to the Quantum community and can be found in this wiki page authored by Edgar Magana from Cisco: http://wiki.openstack.org/QuantumServicesInsertion

Further notes (or what this design specification is not about):

  • There might be scenarios where service insertion happens at network level, as shown in Sasha Ratkovic's presentation. For the scope of this blueprint we will consider only router-level insertion, assuming that network-level insertion could be reduced to a case in which the service is inserted on a router connected to a single network only.
  • There are also definitely scenarios where service insertion happens at the port level; in this case the insertion might be simply represented by attributes applied to the port itself. For an example please refer to the proposed | API for security groups.
  • The concept of port group, presented by Sasha Ratkovic at the Openstack Design Summit is also outside of the scope of this blueprint.
  • Whether advanced services will be realized as new resource (as described in the LBaaS proposal) or as policies (as described by Sasha Ratkovic proposal), is also beyond the scope of this blueprint.

At this stage the careful reader might be wondering whether this blueprint is actually about anything. With all due honesty by defining a (small) set of items we want to address, and a (very large) of items that we definitely do not want to address, it might be argued that this blueprint is actually pretty well scoped, leaving a very thin, blurred, area of items which might or might not be addressed by it.


Service insertion support will require the following changes in the Quantum API The service insertion API might be implemented as a Quantum extension for the Grizzly release cycle.

ServiceType Definition

This is an entirely new resource, which defines a list of services (and their providers) which can be offered to tenants. Note: ServiceDefinition might translate either to a 1st class resource or to an element of the service_definition attribute of the ServiceType resource. While the former approach might seem conceptually more correct, the latter approach will probably lead to a leaner, more efficient, and easier to use API interface.

  id: uuid,
  name: string,
  service_definitions: list<ServiceDefinition>
  default: {True¦False} # Only one service_type could be the default one. This is the service type which should be picked if none is specified in the API (think backward compatibility)

  id: uuid,
  name: string,
  type: enum(LB, VPN, FW) # or whatever you think is right
  provider: string # This ultimately must map to a python class (perhaps indirectly)
  capabilities: list of API extensions which are enabled for this specify service provider

CRUD operations should be available on a ServiceType object. Regular tenants typically should be allowed to read only, whereas administrators would have right to create, modify, and delete those object. Also, the provider attribute might be hidden in response returned to regular tenants. Please note however, that default policy settings might always be overridden as they're specified in etc/policy.json


In order to associate services with Quantum logical router, these resource should be associated with a service_type resource. In order to ensure backward compatibility a default service type must be specified. This can be achieved either in Quantum configuration or through APIs, by designing a specific service_type as the default one.

The Router resource should therefore be extended with the following attribute:

  services:service_type_id # which refers to service_type object

Network level insertion might be an interesting concepts for services such as L2 VPNs, or if we want to move the DHCP service we already run in the service insertion scheme.

Enabling or Disabling services on a router

The following options are being considered at the moment for providing APIs for enabling or disabling specific services on a router, in accordance with the service_type associated with the router. This feature should be available to tenants.

  • Option 1: Resource action /routers/<router_id>/enable_service


  • Option 2: List Attribute
  • Option 3: Sub-Resource POST /routers/<router_id>/enabled_services

Option 1 is currently the preferred one, as it is consistent with "the Openstack way" of defining APIs executing actions on resources beyond the ones that can be expressed as HTTP methods.

Advanced services (such as load balancers)

When they are specified, according to the particular model of insertion, one of the following two might be specified:

  1. services:service_type_id # standalone, one-arm, or whatever we call it
  2. router_id # insertion in routed mode

Configuration variables

This details have not been fleshed out yet. The service insertion feature will probably add several configuration variables, for specifying things such as default service type, or service providers. For more details concerning configuration variables please refer to the Plugin Interface section.

Data Model Changes

ServiceType definition will require two model classes. The ServiceType class will have a 1:n relationship with the ServiceDefinition class. This class will have an attribute for defining the type of the advanced services provider. This could either be another class in the model or extracted from the Quantum configuration file.

ServiceProvider definition could as well be either another model class or information extracted from the configuration file (see next section on plugin integration)

Every time a router is created, an instance of service_type should be created. Even if this could be part of the router object, it might come handy having it as a standalone model class.


        <- 1 --- 1 --/ 

If the service_type_instance model class is not used, model classes for LB, and other type of services will directly refer a service_type, which is however acceptable.

Plugin Interface

The service insertion feature will add a new interface which might be implemented as a new mixin to be inherited by the "core" plugin (a completely standalone class is a viable alternative, albeit less straightforward)

Required Plugin support: [What should the plugins do to support this new feature? (If applicable)]

Plugin Integration

The concept of service type implicitly allows for different paths for an API call. Ideally one would reuse the "mixin" mechanism which proved successful when integrating DHCP and L3 services. The possibility of augmenting the core_plugin with the capability of handling advanced services should definitely be allowed. In this case there will still be a 'core_plugin" only. However, it is a principle of Quantum that plugins are required only to implement the plugin interface. Hence they are not required to adopt the mixin mechanism; hence another aspect to consider is that there could be multiplie plugins at the same type, and the intelligence of dispatching a call to one plugin or another should reside in the API layer.

It seems that the following situations are therefore to be considered:

  1. Single plugin with the same provider for all advanced services (think about current implementation). In this case no service provider definition should be needed.
  2. Single plugin with distinct "drivers" for each service provider. This implies that all services implement the same db model. The mixin classes for advanced services will have a driver interface which will be invoked for performing actual configuration.
    • In this case service drivers should be specified in the configuration file. For each service multiple drivers should be allowed (consider using multivalued options); The service driver should not be seen as a driver for a specific appliance implementing the service. It is rather a driver managing the service for a given provider. As an example, it might manage a pool of physical load balancers, or handle the provisioning of integrated services virtual appliances.
  3. Multiple independent plugins. In this case several plugins might be configured at the same time. The API layer will need to figure out, for each router and/or advanced service, to which plugin the API call should be dispatched.
  4. An arbitrary mix of scenarios #2 and #3,

Scenarios #3 and #4 appear more complex than #1 and #2. This is for the following reasons:

  • multiple plugins will require the API to manipulate data from different sources. Even if each plugin will return data in the same format, we will still need logic to handle collecting data from multiple sources on GET requests, and dispatching commands to the appropriate destination on POST/PUT/DELETE.
  • currently all plugins already implement the "mixin" approach
  • compatibility between plugins (not something we need to worry from day 1, but still an interesting problem)
  • interactions among plugins. In scenarios #1 and #2, having a single plugin, the data model has all the information it needs. With scenarios #3 and #4 the "additional" plugins will have to interact with the "base" plugin (or in some cases even among them); this could be achieved throughout he REST interfaces or by creating appropriate RPC interfaces

It seems however that scenarios #1, #2, #3 should all be covered by the service insertion framework for the Grizzly release.

Potential changes to the current implementation

  1. Floating IPs: despite being shipped with Folsom, this feature might actually be regarded as an 'advanced service', and should probably fit in the service insertion framework.
  2. External Gateway: This might be possibly be regarded as an advanced service too. For instance, a SNAT service.
  3. DHCP: think about how the DHCP service we implement today through the agent fits in the service insertion model. We are not exposing specifically any DHCP API, creating implicitly an instance of this service for each subnet for which dhcp_enable=True. We can either leave DHCP as it is, or include it in the service insertion model.

NOTE: For the cases listed above it is very important to preserve backward compatibility.

POC implementation

A POC of the service insertion model could be offered regardless of actual advanced services being implemented on top of Quantum. This POC might leverage Floating IP and possibly also the external gateway concept.

The following choice of service types might be offered:

  1. ServiceType1:

routing, floating_ips: l3_agent (already implemented)

  1. ServiceType2:

routing, floating_ips: integrated_services_vm (a cloudstack-style virtual router providing L3 routing and advanced network services)

The provisioning of back end resource, such as spinning integrated services VMs is probably a plugin specific task.