We have under development an OpenFlow testbed.

Current implementation

This is the current implementation of the testbed based on Openvswitch

Exposing the testbed for experimentation

The following image shows how the testbed is exposed for experimentation. The testbed is exposed via OpenLab tools (ie PTM, resource adapters and Teagle GW)

Accessing the testbed

The testbed can be accessed by the FSToolkit with the uop plugin enabled. The following displays how to request resources of the infrastructure.

Controlling resources

Resource of the experiment can be controlled by the GUI of FSToolkit.

For more complex user scenarios or better granularity of experiment's environment, an experimenter can use pure Java code to control the experiment. This is done through the FCI API

Here is a view of the testbed installation in our lab

Some charecteristics of the testbed

- Access Switches via Public IPs

- Install user software in VMs

- Experiment with user’s own Openflow controllers

- Access testbed via elastic public IP

- SFA enabled to integrate with other resources (i.e. PlanetLab)

- Affect experimentation environment of user’s System Under Test

Future plans

The final targeted openflow testbed is separated in three distinct clouds of openflow switches:

1.       A cloud of NetFPGAs acting as OpenFlow switches, running the OpenFlow reference.

2.       A cloud of machines (physical or virtual) running OpenFlow.

3.       A cloud of commercial switches running OpenFlow.

These three clouds will be connected with a controller (probably running NOX) and will be interconnected with each other, as shown in the following figure:

Some indicating testing could be:

1.       Create complex datapath patterns.

2.       Make some OpenFlow switches act as simple Routers.

3.       Add a Flowvisor controller to slice the testbed and provide access to users.