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
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.
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.
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.