| 2015-04-30 20:18:16 |
cathy Hong Zhang |
bug |
|
|
added bug |
| 2015-04-30 20:18:48 |
cathy Hong Zhang |
neutron: assignee |
|
cathy Hong Zhang (cathy-h-zhang) |
|
| 2015-04-30 20:19:12 |
cathy Hong Zhang |
neutron: status |
New |
In Progress |
|
| 2015-05-01 17:00:38 |
vikram.choudhary |
bug |
|
|
added subscriber vikram.choudhary |
| 2015-05-02 00:39:41 |
cathy Hong Zhang |
description |
Currently Neutron does not support service chaining. To support service chaining, Service VMs must be attached to points of the
network and then traffic must be steered between these attachment points.
There are two steps in creating a service chain. First, Services VMs (such as FW VM) need to be created and connected to a Neutron network via Neutron ports. After that, selected traffic flows need to be steered through an ordered sequence of these service VM ports. Current OpenStack already support creation of service VMs and attachment of these service VMs to Neutron network ports. What is missing is an API to specify classification rules of the selected flow and the sequence of service VM ports the selected flow needs to go through so that it can get the desired service treatment. Neutron API can be extended to fill in this gap. This new "port chain" API does not need to know the actual services attached to these Neutron ports since the Service VM creation API already has this information.
In summary, first the service function is instantiated and connected to the network through Neutron ports. Once the service function is attached to Neutron ports, the ports are included in a "port chain" to allow the service function to provide treatment to the user's traffic. |
In current Data Center, the deployment of service chain for a tenant's flow is through static, complex, and rigid configurations since they are tightly coupled with physical network topology and physical resources. The introduction of new services into a network usually requires the reconfiguration of most (if not all)
network elements. This is not acceptable in cloud environment. To reduce the OPEX and increase agility, automatic setup of service chain according to user's service chain requirement specification is needed. There is already a BP submitted on service chain use case ttps://review.openstack.org/#/c/169201/4
Currently Neutron does not support service chaining. To support service chaining, Service VMs must be attached to points of the network and then traffic must be steered between these attachment points.
There are two steps in creating a service chain. First, Services VMs (such as FW VM) need to be created and connected to a Neutron network via Neutron ports. After that, selected traffic flows need to be steered through an ordered sequence of these service VM ports. Current OpenStack already support creation of service VMs and attachment of these service VMs to Neutron network ports. What is missing is an API to specify classification rules of the selected flow and the sequence of service VM ports the selected flow needs to go through so that it can get the desired service treatment. Neutron API can be extended to fill in this gap. This new "port chain" API does not need to know the actual services attached to these Neutron ports since the Service VM creation API already has this information.
In summary, first the service function is instantiated and connected to the network through Neutron ports. Once the service function is attached to Neutron ports, the ports are included in a "port chain" to allow the service function to provide treatment to the user's traffic. |
|
| 2015-05-05 17:08:50 |
Meni Hillel |
bug |
|
|
added subscriber Meni Hillel |
| 2015-05-06 10:29:00 |
yalei wang |
description |
In current Data Center, the deployment of service chain for a tenant's flow is through static, complex, and rigid configurations since they are tightly coupled with physical network topology and physical resources. The introduction of new services into a network usually requires the reconfiguration of most (if not all)
network elements. This is not acceptable in cloud environment. To reduce the OPEX and increase agility, automatic setup of service chain according to user's service chain requirement specification is needed. There is already a BP submitted on service chain use case ttps://review.openstack.org/#/c/169201/4
Currently Neutron does not support service chaining. To support service chaining, Service VMs must be attached to points of the network and then traffic must be steered between these attachment points.
There are two steps in creating a service chain. First, Services VMs (such as FW VM) need to be created and connected to a Neutron network via Neutron ports. After that, selected traffic flows need to be steered through an ordered sequence of these service VM ports. Current OpenStack already support creation of service VMs and attachment of these service VMs to Neutron network ports. What is missing is an API to specify classification rules of the selected flow and the sequence of service VM ports the selected flow needs to go through so that it can get the desired service treatment. Neutron API can be extended to fill in this gap. This new "port chain" API does not need to know the actual services attached to these Neutron ports since the Service VM creation API already has this information.
In summary, first the service function is instantiated and connected to the network through Neutron ports. Once the service function is attached to Neutron ports, the ports are included in a "port chain" to allow the service function to provide treatment to the user's traffic. |
In current Data Center, the deployment of service chain for a tenant's flow is through static, complex, and rigid configurations since they are tightly coupled with physical network topology and physical resources. The introduction of new services into a network usually requires the reconfiguration of most (if not all)
network elements. This is not acceptable in cloud environment. To reduce the OPEX and increase agility, automatic setup of service chain according to user's service chain requirement specification is needed. There is already a BP submitted on service chain use case https://review.openstack.org/#/c/169201/4
Currently Neutron does not support service chaining. To support service chaining, Service VMs must be attached to points of the network and then traffic must be steered between these attachment points.
There are two steps in creating a service chain. First, Services VMs (such as FW VM) need to be created and connected to a Neutron network via Neutron ports. After that, selected traffic flows need to be steered through an ordered sequence of these service VM ports. Current OpenStack already support creation of service VMs and attachment of these service VMs to Neutron network ports. What is missing is an API to specify classification rules of the selected flow and the sequence of service VM ports the selected flow needs to go through so that it can get the desired service treatment. Neutron API can be extended to fill in this gap. This new "port chain" API does not need to know the actual services attached to these Neutron ports since the Service VM creation API already has this information.
In summary, first the service function is instantiated and connected to the network through Neutron ports. Once the service function is attached to Neutron ports, the ports are included in a "port chain" to allow the service function to provide treatment to the user's traffic. |
|
| 2015-05-28 01:37:45 |
Armando Migliaccio |
neutron: status |
In Progress |
Triaged |
|
| 2015-05-28 02:25:50 |
Armando Migliaccio |
neutron: assignee |
cathy Hong Zhang (cathy-h-zhang) |
|
|
| 2015-09-28 17:54:21 |
cathy Hong Zhang |
neutron: assignee |
|
cathy Hong Zhang (cathy-h-zhang) |
|
| 2015-10-07 04:22:28 |
Armando Migliaccio |
marked as duplicate |
|
1450625 |
|
