Open Stack

Hi,
Yes , I am thinking of Service VM chaining by Neutron.


The below  figure explains  the service-VMs hosted in the OpenStack cloud. Service Layer can be part of OpenStack controller or NFV Director Service Layer.

This Service Layer  will maintain the list of service to be chained for the traffic in the data path. Service Layer will populate Tenant and Service information to both the Openstack Controller and Service-VMs. Based on this information Service VMs will create the Logical Information and corresponding Service Instances.

Service Layer will provide following information for every service to OpenStack-controller and Service-VMs.

1.       What was the Previous Service (which the tenant Traffic get passed through) .  What will be Next Service (which the tenant Traffic will get forwarded).

2.       Tag value (Q) that needs to be attached for the tenant traffic after current Service is processed for the packet. (This tag will added by the service-VM for every tenant  packet.)

3.       Next Service to be invoked for each Q value. This information will be provided to OpenStack controller, which intern provisions the Open Virtual Switch (OVS) residing on the compute node. (Tenant packet will processed in the OVS and packet will forwarded to next Service accordingly).

[cid:image004.png at 01CFF9DD.3BDF91F0] [cid:image007.png at 01CFF9DD.3BDF91F0]


In the above figure  Service-VM1 and Service-VM2 hosts multiple Logical Instances. Service-VM1 hosts both vNAT and vDPI service within the same service-VM whereas Service-VM2 hosts only vIPSEC.

When the packet with destination marked as prefix-P1 comes from external world,

*         Will be looked into OVS. Then it will be forwarded to Service-VM1 by tagging  P1Q1 (packet + vlan tag)

*         Service-VM1 knows to handle tag Q1 and it will forward to vNAT functionality. Once the vNAT functionality is finished based the Service-Layer information , packet P1 will be tagged with P1Q2  so that it will get forwarded to vDPI with in that service-VM.

*         Once vDPI functionality is done, Service-VM1  will add the tag Q3, to generate packet P1Q3 and place it back to compute node.

*         Compute Node will look into OVS accordingly it will modify the tag so that P1Q3 will modified to P1Q4. P1Q4 packet will be forwarded to Service-VM2 for processing vIPSEC functionality.

This is my idea on chaining the Services using neutron.
Please let us know others opinion on this.

Thanks & regards,
Keshava


From: Tidwell, Ryan
Sent: Thursday, November 06, 2014 1:15 AM
To: OpenStack Development Mailing List (not for usage questions); Singh, Gangadhar S
Subject: Re: [openstack-dev] openstack-dev] [neutron] [nfv]

Keshava,

This sounds like you're asking how you might do service function chaining with Neutron.  Is that a fair way to characterize your thoughts? I think the concept of service chain provisioning in Neutron is worth some discussion, keeping in mind Neutron is not a fabric controller.

-Ryan

From: A, Keshava
Sent: Tuesday, November 04, 2014 11:28 PM
To: OpenStack Development Mailing List (not for usage questions); Singh, Gangadhar S
Subject: [openstack-dev] openstack-dev] [neutron] [nfv]

Hi,
I am thinking loud here, about NFV Service VM and OpenStack infrastructure.
Please let me know does the below scenario analysis make sense.

NFV Service VM's are hosted on cloud (OpenStack)  where in there are  2 Tenants with different Service order of execution.
(Service order what I have mentioned here is  just an example ..)

*         Does OpenStack controls the order of Service execution for every packet ?

*         Does OpenStack will have different Service-Tag for different Service ?

*         If there are multiple features with in a Service-VM, how Service-Execution is controlled in that  VM ?

*         After completion of a particular Service ,  how the next Service will be invoked ?

Will there be pre-configured flows from OpenStack  to invoke next service for tagged packet from Service-VM ?

[cid:image008.png at 01CFF9DD.3BDF91F0]

[cid:image005.png at 01CFF9D3.8342EA10]


Thanks & regards,
keshava


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141106/a9ebd1a4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.emz
Type: application/octet-stream
Size: 9770 bytes
Desc: image001.emz
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141106/a9ebd1a4/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 32398 bytes
Desc: image005.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141106/a9ebd1a4/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.emz
Type: application/octet-stream
Size: 50640 bytes
Desc: image006.emz
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141106/a9ebd1a4/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oledata.mso
Type: application/octet-stream
Size: 18220 bytes
Desc: oledata.mso
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141106/a9ebd1a4/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 20396 bytes
Desc: image004.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141106/a9ebd1a4/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 25494 bytes
Desc: image007.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141106/a9ebd1a4/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 15612 bytes
Desc: image008.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141106/a9ebd1a4/attachment-0007.png>