Changes between Version 2 and Version 3 of GENIExperimenter/Tutorials/WiMAXOpenFlow/Design-Setup


Ignore:
Timestamp:
10/26/13 23:10:27 (10 years ago)
Author:
Ryan Izard
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIExperimenter/Tutorials/WiMAXOpenFlow/Design-Setup

    v2 v3  
    3434Now, 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.
    3535
    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.
     36The 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 novel and super-cool metric a GENI experimenter has implemented). A Python script leverages the Static Flow Pusher API to add and remove flows.
     37
     38The next logical question is where should this Static Flow Pusher insert the flows? In order to leverage the capabilities of OpenFlow, we need to have hardware and/or software that supports its use. Hence, Open vSwitch (OVS) is used in this tutorial. OVS is a software package that implements a virtual OpenFlow switch. This tutorial uses a pre-installed and pre-configured OVS network that incorporates the WiFi, WiMAX, and tap interfaces of the client as ports of virtual switches. The following is a picture depicting the general OVS topology used in this tutorial.
     39
     40[[Image(PCEngine_Diagram.PNG)]]
     41
     42Each 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. With OVS, one can build a vitual network contained entirely within a single entity -- namely the client and server nodes of this tutorial. Each will employ internal OVS networks to alter the default behavior of the kernel with regard to networking. In essence, OVS allows the experimenter to circumvent the networking kernel and allow OpenFlow flows to route and modify packets instead.
    4343
    4444== 2.  Establish the Environment ==
    4545
    46    1.  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.
    47 
    48    2.  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.
    49       a.  Open the Root Terminal by browsing to Applications-->Accessories-->Root Terminal. The password is '''password'''.
    50       b.  Launch Eclipse by running '''eclipse''' in the Root Terminal.
    51       c.  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,\'''.
    52       d.  By default, Eclipse automatically builds the Floodlight project, so we do not need to do so manually.
    53    3.  Customize the setup script. This script is designed to (1) define user variables, (2) configure the tap interface with OpenVPN, (3) start Floodlight, (4) initialize and start OpenVswitch, and (5) configure Linux networking.
     46   1.  Using the Orbit images for the client, server, and AP, load each onto a separate node in an Orbit testbed. Make sure the node supports the hardware requirements for the experiment (Intel 6250 WiMAX and Atheros 5000 or 9000 series for the client and server, and Atheros 5000 or 9000 series for the AP). Boot these images after they are loaded and SSH into each machine.
     47
     48   2.  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 exclusive control over which port(s) our packets get forwarded.
     49      a. In the client and the server nodes, remove the Forwarding module.
     50      b. 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 '''/root/floodlight-0.90/src/main/resources/floodlightdefault.properties''' file and remove the line '''net.floodlightcontroller.forwarding.Forwarding,\'''.
     51      c. Browse to the root directory of the Floodlight project -- /root/floodlight-0.90. Execute '''ant''' in the terminal. ant is a Java-based build tool to build and compile Java projects. Upon success, ant will produce an updated executable jar file in the /root/floodlight-0.90/target directory named '''floodlight.jar'''.
     52   3.  Customize the setup script '''gec18_setup.sh''' in /root/StartupScripts. This script is designed to (1) define user variables, (2) configure the tap interface with OpenVPN, (3) start Floodlight, (4) initialize and start OpenVswitch, and (5) configure Linux networking.
    5453      a.  In the Root Terminal, open a new tab by browsing to File-->Open Tab.
    5554      b.  In the Root Terminal, execute '''ifconfig''':