Jump to: navigation, search

Difference between revisions of "Neutron/VirtualResourceForServiceChaining"

(Limitations)
(Adv. service change)
Line 80: Line 80:
  
 
* (*)  supported combinations can be hard-coded, or there can be a inter adv. service API.
 
* (*)  supported combinations can be hard-coded, or there can be a inter adv. service API.
 +
 +
=== Other virtual resources ===
 +
 +
Just a rough idea.
 +
    network1          network2 
 +
    ===========      ===========     
 +
        |                  |
 +
    +-----------------------+
 +
    |  |                  | |        +-------------------------------+
 +
    |  +------l2vpn-------+ |........| firewall, tapping device, etc.|
 +
    |                      |        +-------------------------------+
 +
    +-----------------------+
 +
              vbridge
 +
 
== Limitations ==
 
== Limitations ==
  
 
A chain of advanced services will not be able to be created in a
 
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.
 
single API call.  Users need to construct a chain step-by-step.

Revision as of 09:25, 8 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

  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.

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.


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.

Other virtual resources

Just a rough idea.

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

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.