| | 1 | = OpenFlow-Based Vertical Handoff over WiFi and WiMAX = |
| | 2 | |
| | 3 | == Overview: == |
| | 4 | This tutorial is designed to give insight into how OpenFlow can be used to conduct network experiments over WiMAX. As background, a vertical handoff is the (ideally seamless) migration of a network connection from one network interface to another of a different technology. An example might be your cell phone transitioning from a WiFi to a 4G connection while streaming a video. Vertical handoffs are traditionally handled by the network infrastructure, providing little-to-no control of the handoff execution at the client. Clemson University and the University of Wisconsin have partnered to develop a client-initiated and controlled vertical handoff. This project is being conducted using GENI resources -- namely Clemson's GENI WiFi and WiMAX testbeds. Development has also been done on the Orbit testbed at Rutgers, which is where this tutorial and GENI experiment will be conducted. |
| | 5 | |
| | 6 | This tutorial will be conducted on the grid testbed at Orbit and will walk you through how to conduct an OpenFlow-based vertical handoff over WiFi and WiMAX. Three Ubuntu Linux images have been prepared for you and are available for this tutorial – (1) a client, which will initiate the handoff, (2) a server, which will serve as a correspondent node for the client, and (3) a WiFi access point (AP), which will provide a WiFi network over which the client and the server can communicate. The grid testbed at Orbit has complete WiMAX coverage via a single WiMAX base station (BS). This BS will provide the WiMAX network over which the client and the server communicate. |
| | 7 | |
| | 8 | Let's talk specifics with repect to each Orbit node. 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. |
| | 9 | |
| | 10 | 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. |
| | 11 | |
| | 12 | [[Image(PCEngine_Diagram.PNG)]] |
| | 13 | |
| | 14 | == Prerequisites: == |
| | 15 | - An Orbit account. Visit www.orbit-lab.org for details on obtaining an account. For the tutorial at GEC18, a tutorial account will be provided for you. |
| | 16 | - A reservation on an Orbit testbed. Sandbox #4 (sb4) can be use for up to eight nodes. The grid testbed can support up to 400 nodes. |
| | 17 | - SSH access to the Orbit testbed. For this, you will need to SSH with the public key associated with your Orbit account. |
| | 18 | - Familiarity with networking, SSH, Linux terminal, OpenFlow, the Floodlight OpenFlow controller, Java, Bash scripting, and Python scripting |
| | 19 | - Familiarity with the Orbit testbed and omf commands (e.g. stat, tell, load, and save) |
| | 20 | |
| | 21 | == Tools: == |
| | 22 | - The Client and Server images on Orbit (we have already installed these items): |
| | 23 | - <Image Names Here> |
| | 24 | - OpenVPN. This tool is used to create the internal tap interface, over which all client applications send and receive packets: http://wiki.debian.org/OpenVPN |
| | 25 | - Floodlight OpenFlow Controller. The Java-based OpenFlow controller used to switch between the WiFi and WiMAX interfaces of the client. |
| | 26 | - Information: http://www.projectfloodlight.org/floodlight/ |
| | 27 | - Installation: http://docs.projectfloodlight.org/display/floodlightcontroller/Installation+Guide |
| | 28 | - OpenVswitch (OVS). The open virtual switch that allows a network interface to be OpenFlow-enabled. |
| | 29 | - Information: openvswitch.org |
| | 30 | - Installation: http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=INSTALL;hb=HEAD |
| | 31 | - Within the AP image on Orbit (we have already installed these items): |
| | 32 | - hostapd. The software package used to create a WiFi access point from an off-the-shelf WiFi card. Information: www.hostapd.org??? Installation: ??? |
| | 33 | |
| | 34 | == Where to get Help: == |
| | 35 | - Questions/help about this tutorial, vertical handoffs, Floodlight: Ryan Izard, rizard@g.clemson.edu |
| | 36 | - Questions/helps about the Orbit testbed: ??? |
| | 37 | - Questions/help about Floodlight projects (Floodlight Developers Group): https://groups.google.com/a/openflowhub.org/forum/?fromgroups=#!forum/floodlight-dev |
| | 38 | |
| | 39 | == Resources: == |
| | 40 | - Floodlight: http://www.projectfloodlight.org/floodlight/ |
| | 41 | - Handoff Code: https://github.com/rizard/openflow-vertical-handoff (ongoing project... check back often) |
| | 42 | |
| | 43 | == Tutorial Instructions == |
| | 44 | |
| | 45 | |
| | 46 | |
| | 47 | {{{ |
| | 48 | #!html |
| | 49 | |
| | 50 | |
| | 51 | <table id="Table_01" height="409" border="0" cellpadding="0" cellspacing="0"> |
| | 52 | <tr> |
| | 53 | <td> |
| | 54 | <a href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/GREESC13/OpenFlowWiMAX/Design-Setup"><img src="http://groups.geni.net/geni/attachment/wiki/GENIExperimenter/Tutorials/Graphics/design.png?format=raw" width="152" height="152" alt="Design/Setup"></a> |
| | 55 | </td> |
| | 56 | <td> |
| | 57 | <ul> |
| | 58 | <li><a href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/GREESC13/OpenFlowWiMAX/Design-Setup">Part I: Design/Setup</a></li> |
| | 59 | <ul> |
| | 60 | <li>Step 1: Design Experiment</li> |
| | 61 | <li>Step 2: Establish Management Environment</li> |
| | 62 | <li>Step 3: Obtain Resources</li> |
| | 63 | </ul></ul> |
| | 64 | </td> |
| | 65 | </tr> |
| | 66 | <tr> |
| | 67 | <td> |
| | 68 | <a href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/GREESC13/OpenFlowWiMAX/Execute"><img src="http://groups.geni.net/geni/attachment/wiki/GENIExperimenter/Tutorials/Graphics/execute.png?format=raw" width="152" height="143" alt="Execute"></a> |
| | 69 | </td> |
| | 70 | <td> |
| | 71 | <ul> |
| | 72 | <li><a href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/GREESC13/OpenFlowWiMAX/Execute">Part II: Execute</a></li> |
| | 73 | <ul> |
| | 74 | <li>Step 4: Configure and Initialize Services </li> |
| | 75 | <li>Step 5: Execute Experiment </li> |
| | 76 | <li>Step 6: Analyze and Visualize Experiment </li> |
| | 77 | </ul></ul> |
| | 78 | </td> |
| | 79 | </tr> |
| | 80 | <tr> |
| | 81 | <td> |
| | 82 | <a href="http://groups.geni.net/geni/wiki/GENIExperimenter/GREESC13/OpenFlowWiMAX/Finish"><img src="http://groups.geni.net/geni/attachment/wiki/GENIExperimenter/Tutorials/Graphics/finish.png?format=raw" width="152" height="114" alt="Finish"></a> |
| | 83 | </td> |
| | 84 | |
| | 85 | <td> |
| | 86 | <ul> |
| | 87 | <li><a href="http://groups.geni.net/geni/wiki/GENIExperimenter/GREESC13/OpenFlowWiMAX/Finish">Part III: Finish</a></li> |
| | 88 | <ul> |
| | 89 | <li>Step 7: Teardown Experiment</li> |
| | 90 | <li>Step 8: Archive Experiment</li> |
| | 91 | </ul></ul> |
| | 92 | </td> |
| | 93 | |
| | 94 | </tr> |
| | 95 | </table> |
