Difference between revisions of "Neutron/VirtualResourceForServiceChaining"

Latest revision as of 12:45, 14 May 2014

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

specify a graph of advanced services in use
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
      |
  +-------+   +-----+
  |router1|...|FWaaS|
  +-------+   +-----+
      |
  ========= 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.|
    |                       |        +-------------------------------+
    +-----------------------+
              vbridge

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:

get the underlying router and adv. service
raise error if the combination of adv. services isn't supported
do whatever necessary (*)

(*) supported combinations can be hard-coded, or there can be a inter adv. service API.

Limitations

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.

@@ Line 19: / Line 19: @@
 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 ==