Difference between revisions of "Neutron/VirtualResourceForServiceChaining"

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

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.

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:

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 57: / Line 57: @@
+=== DB change ===
+Router will get these additional columns:
+{| class="wikitable"
+|-
+! 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.