1 / 45

Using OpenFlow and Orbit to Achieve Mobility in a Heterogeneous Wireless Network

Using OpenFlow and Orbit to Achieve Mobility in a Heterogeneous Wireless Network. Ryan Izard rizard@g.clemson.edu GREE-SC2014 Iowa State University. Outline. A brief overview of software defined networking (SDN) and OpenFlow (OF)

ember
Download Presentation

Using OpenFlow and Orbit to Achieve Mobility in a Heterogeneous Wireless Network

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Using OpenFlow and Orbit to Achieve Mobility in a Heterogeneous Wireless Network Ryan Izard rizard@g.clemson.edu GREE-SC2014 Iowa State University

  2. Outline A brief overview of software defined networking (SDN) and OpenFlow (OF) OF controller and OF switch software components and interaction The Floodlight (FL) OF controller Achieving IP Mobility with OF Tutorial / Walk-through

  3. What is Software Defined Networking and OpenFlow?

  4. What is SDN? • Physical separation of network control plane from forwarding/data plane • Network control • Centrally managed • Directly programmable • Network infrastructure • Abstracted from applications

  5. How Does SDN Work? API Feature A API Feature B API Feature C Network Operating System Packet Forwarding Packet Forwarding PacketForwarding Packet Forwarding Packet Forwarding

  6. What Is OpenFlow? • Link between SDN control and infrastructure layers • OF-enabled infrastructure communicates with an OF controller via the OF protocol

  7. How Does OF Work? User Applications Network Services Custom Services APIs OpenFlow Controller Packet Forwarding Packet Forwarding PacketForwarding Packet Forwarding Packet Forwarding

  8. Basic SDN packet handling example OpenFlow Controller

  9. Basic SDN packet handling example OpenFlow Controller User 2 User 1

  10. Basic SDN packet handling example OpenFlow Controller User 2 User 1

  11. OpenFlow Switches and Controllers

  12. Bottom-Up: An OF-Enabled Switch Power On Bootloader OF-Enabled OS time Control Path OpenFlow Data Path / Switching Hardware Flow Table

  13. OF Switch Connection to Controller Controller Network Services Custom Services APIs OpenFlow Controller (e.g. Floodlight, NOX, etc.) OS (e.g. Linux, Mac, Windows, etc.) Control Path OpenFlow Data Path / Switching Hardware Flow Table Hardware

  14. OF Switch Connection to Controller • Switch probes for controller • Configured with controller IP/port (6633/6653) • Connection established via TCP/TLS • Standalone or secure modes • Controller can learn topology • Packet-out LLDP • Devices and other participating OF switches discovered and mapped

  15. Application Connection to Controller Controller Application Requesting Controller Service(s) OpenFlow Controller (e.g. Floodlight, NOX, etc.) Interface to Controller (e.g. REST) OS (e.g. Linux, Mac, Windows, etc.) OS (e.g. Linux, Mac, Windows, etc.) Network Services Custom Services APIs Hardware Hardware

  16. Application Connection to Controller • Controller-dependent • Floodlight provides REST API • JSON • Modify or query running configuration • Expandable with custom modules • Options are vast with open-source • Customize controller APIs and behavior • User-application-independent (e.g. a transparent network service like SOS)

  17. The Floodlight OpenFlow Controller Open-source OF controller Sponsored and supported by Big Switch Networks Written in Java and easily used with Eclipse Modifiable and expandable to suit any application via modules Large developer community and support group

  18. Floodlight Modules • What is a Floodlight (FL) module? • FL service that reacts to switch/controller events, manages running switches, and/or manages controller configuration • Java package • FL ships with many modules, but custom modules are supported • Modules can work collaboratively and be chained to achieve desired results

  19. Floodlight Architecture Execute Parse module list Load modules Start REST service Start FL Provider Service (Core) time FL Modules (e.g. Forwarding, DHCP, Your_Module, etc.) REST Service FL Provider Service

  20. Floodlight Architecture

  21. Customizing Floodlight Behavior • Off-the-shelf, the FL controller mimics traditional learning switch behavior for all connected switches • Custom modules allow for advanced SDN applications/behaviors • SOS, HetNet Mobility, GENI Cinema, etc. • Add your custom modules here too! • REST API allows third party apps to query and modify the running configuration of FL

  22. How can Software Defined Networking and OpenFlow be Used to Achieve a Vertical Handover?

  23. Part I: Design/Setup • Use OpenFlow to perform L2 handoff • Part II: Execute • Configure and initialize software and scripts • Execute handoff experiment • Part III: Finish • Determine results • Kill processes • Shutdown node and logout

  24. Mobility Over Heterogeneous Networks • Provide mobility for clients over IPv4 • Entirely SDN and OF-based solution • Network-level • Migration detection • IP address assignment and management • Packet routing • Client-level • Packet routing • Interface switching • Transparent service to application

  25. Mobility Over Heterogeneous Networks • Network-Level, Mobile IP: • Home/Foreign Agents OpenFlow Controller • Mobile IP tunnelsOpenFlow flows • DHCP server on OpenFlow controller • Client-Level, Vertical Handoff: • Change physical interface  broken socket • Open vSwitch + Floodlight OF controller • Manage the physical interfaces via SDN • End-user sees “always-up” virtual interface

  26. Client Connects to WiMAX Client-Level

  27. Client Connects to WiMAX Controller and DHCP Server Network-Level

  28. Client Uses WiMAX Network Controller and DHCP Server Network-Level

  29. Client Migrates Controller and DHCP Server Network-Level

  30. Client Switches to WiFi Interface Client-Level

  31. Network Responds to Handover Controller and DHCP Server Network-Level

  32. Client Connection Rerouted to WiFi Controller and DHCP Server Network-Level

  33. Mobility Over Heterogeneous Networks Client-Level

  34. Part I: Design/Setup • Use OpenFlow to perform L2 handoff • Part II: Execute • Configure and initialize software and scripts • Execute handoff experiment • Part III: Finish • Determine results • Kill processes • Shutdown node and logout

  35. Configure Experiment • Experiment is a simple ping to demonstrate a vertical handoff between a WiFi and a WiMAXinterface on a node in the Orbit grid testbed • Detailed instructions: • http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/WiMAXOpenFlow • GREE-SC2014 group and node assignments: • http://tinyurl.com/greesc2014-d7-node-info

  36. Configure Experiment • Enable WiMAX for your GENI project • Login to GENI at portal.geni.net • Scroll down to the Tools section and select WiMAX • Select the button to enable WiMAX for your project (GREESC14) • Click Submit • Note your username

  37. Configure Experiment • You should be able to login to the Orbit testbed for your project • eval`ssh-agent –s` • ssh-add /path/to/private/key • Open two separate terminal windows and in each SSH to Orbit • sshusername@console.grid.orbit-lab.org

  38. Configure Experiment • Load AP image onto node • omfload -o 1200 -i rizard-greesc2014-ap.ndz -t node11-11 • Load Server image onto node • omf load -o 1200 -irizard-greesc2014-server.ndz -t node10-10 • Load Client image onto node • omf load -o 1200 -irizard-greesc2014-client.ndz -t <client-node> • Power off and boot nodes • omf tell -a offh -t node11-11,node10-10,<client-node> • omf tell -a on -t node11-11,node10-10,<client-node> Do NOT Complete at GREE-SC2014 It’s Already Been Done For You

  39. Configure Experiment • Setup AP node (Already done for GREE-SC2014) • ssh root@node11-11 • Start: ./gec20_setup_ap.sh • Setup Server node (Already done for GREE-SC2014) • ssh root@node10-10 • Start: ./StartupScripts/gec20_setup.sh • ARP: ./StartupScripts/arp_add_list.sh • Setup Client node – Your Turn! • ssh root@<client-node> • Disable Floodlight’s forwarding module • Configure startup and switching scripts • Start: ./StartupScripts/gec20_setup.sh

  40. Part I: Design/Setup • Use OpenFlow to perform L2 handoff • Part II: Execute • Configure and initialize software and scripts • Execute handoff experiment • Part III: Finish • Determine results • Kill processes • Shutdown node and logout

  41. Execute Experiment • WiFiflows are installed as “initial flows” when setup script is run. • In a new terminal, start a ping to the server IP, 10.41.105.105. The packets will be switched out the WiFi interface. • Run the WiMAX switching script. The ping packets will be switched out the WiMAX interface. ./SwitchingScripts/gec20_switch_to_wimax.sh • You’ve performed a handoff! Want proof? View the flows and packet counts on each OVS bridge before and after an interface-switch. • Alternate inferfaces and switch back to WiFi. ./SwitchingScripts/gec20_switch_to_wifi.sh

  42. Part I: Design/Setup • Use OpenFlow to perform L2 handoff • Part II: Execute • Configure and initialize software and scripts • Execute handoff experiment • Part III: Finish • Determine results • Kill processes • Shutdown node and logout

  43. Teardown Experiment • When the experiment is done, on the Client node stop the Floodlight controller, stop OVS: ./StartupScripts/gec20_teardown.sh • On the Server node: ./StartupScripts/gec20_teardown.sh • Exit all SSH connections to nodes and power off resources: omf tell -a offh -t all • Exit Orbit console SSH connections.

More Related