Jump to: navigation, search


The Problem

Neutron has several advanced services. But there is some difficulty using multiple advanced services at once.

Current Approach

There are two proposals.

  • Neutron Services' Insertion & Chaining
  • Service Function Chaining

Analysis of Existing Plans

We need to be able to

  1. specify a graph of advanced services in use
  2. supply enough configuration information to each advanced service

The above proposals introduce new DB objects to solve #1, but it is not clear how #2 will be solved. Some abstraction is necessary to be able to chain different services, but existing ideas may be doing too much abstraction. As a result, necessary information might get lost with such abstraction.

The Proposed Solution

The main idea of this proposal is to introduce the notion of virtual network resources.

For example, assume there is a router with a firewall configuration.

  ========= network1
  +-------+   +-----+
  +-------+   +-----+
  ========= network2

Give the combination of router1 and FWaaS a new router UUID and let it have the name vrouter1. It is trivial to define another advanced service using vrouter1 as a router_id.

  ========= network1
|     |    vrouter1     |
| +-------+   +-----+   |   +------------------+
| |router1|...|FWaaS|   |...|other adv. service|
| +-------+   +-----+   |   +------------------+
  ========= network2

For L2VPN, a configured L2VPN service can have a virtual bridge UUID. Then another advanced service can be defined using the virtual bridge_id.

    network1          network2   
   ===========       ===========       
       |                  |
    |  |                  | |        +-------------------------------+
    |  +------l2vpn-------+ |........| firewall, tapping device, etc.|
    |                       |        +-------------------------------+

DB change

Router will get these additional columns:

name type description
parent_id uuid or none id for underlying router
service_type string FIREWALL, VPN, etc.
service_id uuid or none represents specific adv. service. might be necessary (can be inferred from parent_id and service_type?)

Adv. service change

Upon plugin call, if given router_id is virtual:

  1. get the underlying router and adv. service
  2. raise error if the combination of adv. services isn't supported
  3. do whatever necessary (*)
  • (*) supported combinations can be hard-coded, or there can be a inter adv. service API.


A chain of advanced services will not be able to be created in a single API call. Users need to construct a chain step-by-step.