| 32 | | 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.'' |
| | 32 | The goal of this tutorial is to perform a vertical handoff over WiFi and WiMAX in the Orbit testbed. Let's talk specifics with repect to each Orbit node. As briefly mentioned in the Overview, the experiment will be conducted with three Orbit nodes -- the client, the server, and the AP. Up first, we have the client node. The client is equipped with an Intel 6250 WiFi/WiMAX network adapter and an Atheros 5000 series WiFi network adapter. The Intel 6250 has a limitation – it can support the operation of either WiFi or WiMAX but not both simultaneously. As such, the Intel 6250 will serve as the WiMAX adapter and the Atheros 5000 series will serve as the WiFi adapter on the client. The OpenFlow-based handoff solution will choose which of these network interfaces it would like to use in order to relay messages to the server. Speaking of which, the server is equipped with the same wireless cards as the client. In order to receive packets from the client over both WiFi and WiMAX, the server will listen for the client's traffic over both its WiFi and WiMAX interfaces. To do this seamlessly, the server will also implement an OpenFlow-based solution. More details about how OpenFlow is used in both the server and the client are provided as the tutorial progresses. The third and final Orbit node necessary for this tutorial is the AP. Like the client and the server, the AP also contains both an Intel 6250 and an Atheros 5000 series wireless card; however, it will only use the Atheros card. The Atheros card on the AP is used by the software package hostapd to provide a WiFi network for both the client and the server machines. If you are interested in expanding upon this experiment, it is worth noting that Atheros cards play very well with hostapd-based networks; however, some Intel cards (such as the Intel 6250) are not directly supported. This is the reason we choose to use the Atheros over the Intel 6250 to provide the WiFi network. |
| | 33 | |
| | 34 | Now, in order to provide a seamless handoff, the application should not be aware that the handoff takes place. The "seamlessness" of the handoff is still in development by the SDN team at Clemson. But for starters, from a networking point of view, if a network interface is brought up or is taken down, the IP address will be added to or removed from that network interface. This means the application's network socket will be broken if a break-before-make handoff occurs (which is oftentimes the case). When an application socket breaks, that means the application can no longer communicate over then network with it, and if this happens, the application must have some scheme to recreate the socket, otherwise the connection will be lost. In order to put as little reliance on the application layer as possible, a virtual tap interface is used. All applications will bind to the IP on this tap interface, and since tap interfaces are not physical, the only time it can “go down” is if we as programmers/network administrators take it down ourselves. Thus, it is a reliable way to make sure the application's socket stays “up”. In this tutorial, all application traffic will originate from and terminate at the tap interface. |
| | 35 | |
| | 36 | 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. Now, the metric that decides which interface to use and when to perform the handoff is beyond the scope of this tutorial. Instead, this tutorial is designed to provide a basic framework for a handoff. To conduct the handoff, the Static Flow Pusher API in Floodlight, the OpenFlow controller, is used to insert OpenFlow flows manually, as determined by the handoff decision (e.g. a super-cool metric a GENI experimenter has implemented). A Python script leverages the Static Flow Pusher API to add and remove flows. |
| | 37 | |
| | 38 | The next logical question is where should this Static Flow Pusher insert flow? In order to leverage the capabilities of OpenFlow, we need to have hardware and/or software that supports its use. Hence, OpenVswitch (OVS) is used in this tutorial. OVS is a software package that implements a virtual OpenFlow switch. This tutorial uses a pre-installed OVS network that incorporates the WiFi, WiMAX, and tap interfaces of the client as ports of virtual switches of an OVS network. The following is a picture depicting the general OVS topology used in this tutorial. |
| | 39 | |
| | 40 | |
| | 41 | |
| | 42 | Each physical and tap interface has a corresponding OVS bridge. (In OVS terminology, an "OVS bridge" is essentially an "OpenFlow switch." It is called a bridge rather than a switch, since from the Linux kernel's perspective, the OVS bridge bridges the physical interface it is associated with.) These OVS bridges are linked together as if you actually plugged a physical switch into another with an Ethernet cable. The interfaces of the machine appear as ports on the OVS bridges, as do the internal links between the OVS bridges. |
