Difference between revisions of "Neutron/VirtualResourceForServiceChaining"
(→Adv. service change) |
(→The Proposed Solution) |
||
| Line 56: | Line 56: | ||
bridge_id. | bridge_id. | ||
| + | |||
| + | network1 network2 | ||
| + | =========== =========== | ||
| + | | | | ||
| + | +-----------------------+ | ||
| + | | | | | +-------------------------------+ | ||
| + | | +------l2vpn-------+ |........| firewall, tapping device, etc.| | ||
| + | | | +-------------------------------+ | ||
| + | +-----------------------+ | ||
| + | vbridge | ||
=== DB change === | === DB change === | ||
| Line 80: | Line 90: | ||
* (*) 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. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Limitations == | == Limitations == | ||
Revision as of 09:28, 8 May 2014
Contents
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.
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.
