Context Navigation

1. Design the Experiment

The end-user will use the virtual tap interface (created by OpenVPN) for network connections, while the handoff execution will handle which physical interface to use. The Static Flow Pusher API in Floodlight allows for flows to be inserted manually, as determined by the handoff decision. A Python script leverages the Static Flow Pusher API to add and remove flows. Detailed instructions are as follows. It should be noted that these instructions are executed inside the VM image with the exception of the very first instruction below.

2. Establish the Environment

Before booting into the VM, create three network interfaces -- two host-only interfaces and one control NAT interface. If you are using VirtualBox, you must also enable promiscuous mode for each of the two host-only interfaces.

Remove the Forwarding module from the Floodlight OpenFlow controller. Floodlight uses what it calls a module loading system, where the user can write modules to perform a certain task or set of tasks. Each module can register for certain events. For example, the Forwarding module registers for PACKET_IN events where the controller is sent a packet from a connected switch. Upon such an event, the Forwarding module will send the packet out the correct port(s) depending on the destination. This module essentially implements a standard learning switch function where the OpenFlow-enabled switch behaves as if it were a standard network switch. We do not want this functionality, since we would like to have control over which port(s) our packets get forwarded.

Open the Root Terminal by browsing to Applications-->Accessories-->Root Terminal. The password is password.

Launch Eclipse by running eclipse in the Root Terminal.

The module loading system maintains a list of the modules to be loaded at runtime. To remove the Forwarding module from this list (and thus disable it), open the floodlight/src/main/resources/floodlightdefault.properties file and remove the line net.floodlightcontroller.forwarding.Forwarding,\.

By default, Eclipse automatically builds the Floodlight project, so we do not need to do so manually.

Note the subnets and names given to each of the network interfaces. Recall, when the VM was initialized, we configured 1 NAT interface and 2 host-only interfaces. The two interfaces on the same subnet are the host-only interfaces. Make notes of each interface name and its IP and subnet mask.

With this information, to the setup script directory:

$ cd /root/06-03-13
$ ls
... system_setup.sh ...

Open the script with the text editor of your choice (vi, gedit, pico, nano, etc):

$ gedit system_setup.sh

There are numerous user defined variables at the top of the script. These are placeholders for commonly used system and configuration specific information throughout the script. We need to change a few of them to suit our needs for this tutorial. Modify the physical interface names for IFACE_wlan0 and IFACE_wimax to match those names of the host-only interfaces noted from ifconfig. Also, modify the IFACE_tap_IP variable to be an IP in the same subnet of the host-only interfaces (e.g. 192.168.193.155 would work for the host-only subnet 192.168.193/24). Note that you might not need to change anything depending on what virtualization software you are using and how you set up your VM's network preferences.

Now, it is sometimes desirable to automate the start of Floodlight; however, for the purposes of this tutorial, we will launch it from within Eclipse. Make sure the following lines of the system_setup.sh script are commented out:

Now, we need to take down any pre-existing OVS bridges. The OVS database is persistent between OVS executions. This is great if you want to retain your previous OVS configuration; however, if you want to start fresh or redo a particular aspect of your topology, you will want to remove the necessary bridge(s).

At this point, we're ready to set the patch ports between the OVS bridges. These create links between the OVS tap bridge and the OVS WiFi and WiMAX bridges in order to facilitate the flow of packets from the tap bridge to the physical interface of choice. A physical analogy to patch ports is an Ethernet cable interconnecting two OpenFlow-enabled switches.

Now, we need to assign each OVS bridge a unique ID (DPID or Datapath Identifier) and point them to the address of the Floodlight controller. Floodlight will be run on the localhost (i.e. on our VM), so the loopback address is used and defined within the variable OVS_controllerIP.

Now, the second-to-last thing to do in the setup script is to configure our network connections. We need to revoke the IPs from our physical interfaces and assign them to the OVS bridge interfaces corresponding to each interface. This will allow us to inject data/packets into and out of our OVS network. We also need to configure our OVS tap bridge with an available IP address in the same subnet as our VM's host-only network (noted earlier with ifconfig). And finally, we need to disable IP forwarding.

The tc command allows us to add a simulated delay on a particular interface. So we can see the handoff when it occurs, we will add a 100ms delay to the br_wimax interface. Make sure this line is uncommented in order to enable the delay.

Save system_setup.sh and close your text editor.

Examine the kernel routing table, and create a script to automate adding and removing of IP routes.

Configure the script to remove all routes except a single default route via the br_tap interface. We can only control the interface packets use if they are sent into our OVS network. When a user application sends a packet, Linux will send it to the appropriate network interface according to the routing table. As such, we need to make sure the default route and route for each handoff-participating interface is via the tap OVS bridge, not via the physical interfaces. Note, until the system_setup.sh is executed, there will be no OVS bridge interfaces present. As such, this script should not be run until after system_setup.sh. (There is no harm in running it now, though. If an attempt is made to add or remove a non-existent route, a error message will be displayed and the script will continue.)

Save the delete_route.sh script and exit the text editor.

Warnings

Be on the lookout for typos in your scripts!

Notes

Write down your interface names, IP addresses, and subnet masks.
All subnets must be the same for a Layer-2 handoff.