What is this project about ?

This a fork of Open vSwitch, with additional interface to load 3rd party / external / customer DPI engine on top of Open vSwitch. This project is part of my MS Thesis (BITS).

Why DPI + OVS ?

By definition, DPI – Deep Packet Inspection means, determining the application (Ex Youtube, Skype etc) by analyzing the Ethernet frames. Advantage of DPI is that, enterprise level decisions can be made based upon the analyzed data. (Ex. Boost the bandwidth, Determine the application level network usage etc.)

It is important to understand that, DPI is not, merely a packet analysis, but it also provides capabilities for network steering upon the data it receives from the network. Though the traffic analysis can be made centralized in the controller plane, the effective classification of packet can be done, only at the switch level.

If you look at the present scenario in traditional networking ecosystem, DPI is performed by highly specialized hardware with proprietary DPI techniques. This makes sense, as long as the network is made of traditional hardware oriented set ups. Industry had started to embrace the SDN ecosystem, where-in, any commodity hardware can be used to virtualize network functions (NFV). Hence DPI in specialized hardware doesn’t make sense anymore. DPI has to be even virtualized.

DPI in OVS

Presently there is no DPI enabled soft switch, especially in the SDN ecosystem. The aim of this project ( part of my MS Thesis in BITS) is to provide DPI functionalities as part of Open vSwitch, so that any controller can take advantage of the DPI information and leverage the DPI functionalities to upper management layers.

High level design

The following fig, gives high-level overview on how DPI engine can be integrated.

• packet_clone for DPI is very much necessary to create a new packet, as not all packets, reach ovs upcall handler due to flow cache that is maintained in kernel.
• Opaque DPI Interface clearly abstracts Open vSwitch to outside world. So dynamically, any 3rd party / external / customer DPI engine can be hooked with OVS seamlessly.

Packet flow with new DPI plugin

As you can see, for every incoming packet (green), corresponding DPI packets (black) will be cloned. As per existing logic, some packets (blue) will reach userspace for special processing, however all DPI packets (black) will reach DPI handler in userspace. This is very much necessary for any DPI engine. More packets == More data to analyse == Better results.

Project highlights

• A new interface dpi_plugin.h which integrates OVS with any 3rd party / custom / DPI plugin.
• Kernel datapath modified to clone all the incoming packets to send it to userspace with special label fpr DPI
• A new DpiWriteLog() function, which enables plugin developers to log their contents directly into OVS logging framework. A handly tool for debugging & maintenance.
• A sample DPI plugin kspviswa-nDPI-plugin that will demonstrate the power of dpi-enabled-ovs
• * This plugin comes with its corresponding web-based application to view the DPI info at business application level.

Sample DPI plugin

Inorder to demonstrate the power of DPI enabled OVS, I wrote a sample plugin, that will collect the DPI data directly via OVS, powered by nDPI engine. Then with help of Google charts API, I wrote a sample visualization application (analogous to business application on controller side) to harness the DPI information.

Mode of deployment

I had introduced a command-line switch to dynamically load any DPI plugin. Here is the syntax

sudo ovs-vswitchd --dpi-engine=<path to plugin>

High level design

Here is the high level design of the plugin

Demo Output

Here is the output from the business application.

Further development & contact

This project is part of my MS thesis. Feel free to contact me if you wish to take this project to next step, want to know how to deploy / enhance etc.