Handover solution for Geni Wireless

The Global Environment for Network Innovations (GENI) is a NSF sponsored effort to create a large scale testbed for network experimentation. One feature of GENI is its use of OpenFlow (OF), a specification implemented by switches or routers that allows the forwarding plane to be modified by a controller in software. Recently, GENI has made strides towards enabling experimentation over wireless resources. It is a priority for GENI to provide mobile hosts with seamless vertical handovers using IPv4-compatible methods within GENI's heterogeneous wireless networks. This feature is desirable to researchers testing network applications as well as vertical handover decision algorithms.

Our contribution to this effort is the design of an OF-based, IPv4-compatible vertical handover testbed for use with GENI wireless networks. In the spirit of GENI, researchers will be able to reserve and utilize the resources in our implementation of this testbed. However, due to the nature of wireless research, we anticipate that other researchers may need an implementation of the testbed on their own campus. Therefore, the majority of this wiki describes the details of how we applied, designed, and implemented the framework to provide a versatile testbed. An understanding of the challenges and issues we encountered and resolved will provide insight and guidance to other researchers who plan on implementing this testbed on their campus.

If you need to cite our solution, please use,

Izard, Ryan, et al. "An openflow testbed for the evaluation of vertical handover decision algorithms in heterogeneous wireless networks." Testbeds and Research Infrastructure: Development of Networks and Communities. Springer International Publishing, 2014. 174-183.

System Framework

The system framework utilizes OF to achieve IP mobility and application-transparent handovers. It is designed to be easily deployed to universities that have OF-enabled campuses or that can provide a subnet or VLAN for handover experimentation. The framework was developed and implemented at Clemson as a part of the GENI WiMAX project. Fig. 1 provides a general overview of how our testbed is constructed and how it integrates with the large-scale GENI testbed. At the architectural level, the framework allows OF-enabled mobile devices to roam across any OF-enabled wireless network. It requires a root OF switch as the testbed ingress/egress, as well as OF switches at each edge network. The challenge in building a testbed based on the framework is the required integration with existing network infrastructure at the campus. The testbed allows a mobile device to roam from wireless Network X (as illustrated in Fig. 1) to Network Y, preserving end-to-end socket connections that the device has with other hosts located either on the campus network or in the Internet. With these minimal assumptions, the testbed can be as simple or as complicated as desired. The design of our testbed can be divided into two major components: the network-level and the client-level.

Figure 1. Design of the Clemson Geni Handover Testbed

The network-level component is required to manage and maintain client IP addresses, as well as the routing of client packets within the the testbed network. Both of these tasks are performed with a Floodlight (FL) OF controller, which maintains a global IP address pool and handles migration events within the testbed. To maintain the global IP address pool, a custom DHCP server module is integrated into FL. The FL controller is designed to be extensible to support other use cases; for example, in a HaaS framework, the FL controller could also make the handover decisions for the mobile devices in the network [1]. A key component of the network-level is an OF-enabled switch or Open vSwitch (OVS) located at the root, such that all IP mobility-enabled networks on the edge are descendants of this root. As descendants of the root switch, other OF switches or OVSs are deployed on the network-level in order to both route client packets and detect migration events. From a network operations point of view, benefits of this tree-like design include (1) a single point of integration with the campus infrastructure and (2) the requirement of no specialized hardware in the case where OVS is used in favor over physical OF switches.

The client-level component of the testbed exists entirely on-board the client and is responsible for both switching the active physical interface and maintaining all client sockets during such a handover event. To maintain active sockets, a default virtual network interface (VNI) is installed on the client. All applications send and receive packets through this VNI, and by nature of a virtual interface, it is not impacted by physical interface states. The client is also equipped with OVSs and its own FL OF controller. This controller is responsible for routing packets from the VNI's OVS, through the client-level OVS network, and then to the physical interface of choice as determined by a handover decision.

client OVS design

Figure 2. Client Open vSwitch interface configuration

Network component

Within our testbed, the network component has the responsibility of maintaining the IP address pool for every mobility-enabled network. The network-level FL controller acts as a DHCP server, using DHCP requests as a trigger for migration. In the event of a migration, this Floodlight controller is also responsible for efficiently and quickly updating the client's location and thus the flow of its application packets.

The detection of a client connection and migration within the testbed is achieved through the use of OVSBs and OF flows (flows). These flows detect, encapsulate, and redirect client DHCP packets (on UDP destination port 67) to the network-level FL controller. This controller contains an integrated DHCP server module which, unlike traditional DHCP servers, associates an IP address lease with multiple MAC addresses. Each of these MAC addresses corresponds to a participating network interface (NIC) on the client. When processing a DHCP packet, the controller cross-references the MAC address of the DHCP packet with all available MAC address lists. Upon a successful match within a MAC address list, the controller assigns the client who initiated the request the corresponding IP. Then, upon a mobile host's initial connection or migration to a foreign network, flows are inserted in OVSBs starting at the testbed root and along every hop to the client's current location. These flows direct packets to and from the mobile client within the testbed. When a client migrates away from this network, any existing flows associated with the client are removed and replaced with flows along the path from the root to the newly-migrated foreign network. The use of a root switch and tree hierarchy allows the network-level controller to avoid undesirable triangle-routing in the event of a migration.

The mobility testbed includes many OVSBs within the network. As discussed previously, the network-level OVSBs connect to the network-level FL controller / DHCP server. These OVSBs are used in the detection of client migrations and the routing of client packets into and out of the testbed. Specifically, the OVSBs on the testbed edge detect client migration by intercepting DHCP request packets, while the OVSBs in the core direct the flow of client packets from the testbed root to the client on the testbed edge.

Each network-level node with OVSBs also uses OVS patch ports (OVSPPs). To ensure proper routing of packets destined for an IP not routable by a foreign network, OVSPPs are used to connect the external and internal facing OVSBs installed on the gateways/APs. This allows independent subnets to operate within the testbed. The OVSPPs, combined with flows that utilize these OVSPPs, force client packets to bypass Linux routing on each hop, thus supporting cross-subnet compatibility upon migration from the home network.

Client Component

Any mobile device should be able to connect to a network in our testbed and maintain an IP through a vertical or horizontal handover. However, if the handover is to be truly seamless to an application, there needs to be a persistent VNI for the application to use. The VNI abstracts the handover from the application and provides the application with an interface that is persistent for the duration the client is active. In addition to the VNI, the client should also be able to switch between interfaces in a manner that is simple and straightforward to the experimenter utilizing the testbed.

Similar to the network-level design, OVSBs are also utilized in the client to achieve a seamless handover. These client-level OVSBs are used in conjunction with a client-level FL OF controller and are installed for each mobility NIC on the client, as shown in Fig. 2. The local FL controller inserts flows in each OVSB via the integrated Static Flow Pusher. These flows route application packets from the client VNI to the NIC of choice. When a decision is made to switch NICs, the client will issue a DHCP request egress the new interface, which will then trigger the aforementioned events in the network-level. As a result, these OVSBs with FL-inserted flows allow the client to seamlessly switch from one network to another. All client-level tasks are encapsulated in shell scripts to provide testbed experimenters with a simple and single command to execute a handover.

Each client-level OVSB also contain OVSPPs. To ensure proper routing of packets from the VNI to the NIC of choice, OVSPPs are used to connect the VNI OVSB with the OVSB of each participating NIC installed on the client. (as seen in Fig. 2). The OVSPPs, combined with flows that utilize these OVSPPs, serve to link the VNI to each NIC's OVSB. These flows define the route (and thus the NIC) used by application packets.

The use of a VNI introduces a problem when associating with networks and routing packets to the client from the network-level. The MAC address of the VNI must be the same as that of the NIC, otherwise WiFi APs and other access mediums will not accept packets from or know how to route packets back to the client's VNI at the link layer. It is not reasonable to require the modification or "spoofing" of each NIC's MAC address to that of the VNI. The client-level solution to this problem is to perform MAC-rewrite within the client OVSBs. When an application generates packets, they are routed out of the client via flows on each OVSB. These flows contain actions to rewrite the source MAC address of all egress packets from that of the VNI to that of the NIC. The flows also contain actions to rewrite the destination MAC address of all ingress packets from that of the NIC to that of the VNI. This rewrite process allows the client to send and receive packets from its VNI with any associated network on the link layer. Due to a limitation of OF, ARP packets cannot be rewritten with flows; they must be processed instead by a controller. Thus, the client-level FL controller contains a custom module to rewrite all ARP packet MAC addresses within the controller itself. Although out-of-band processing of packets is inefficient as compared to in-band, ARP packets are not frequent, so an occasional rewrite within the controller is a compromise made in our client-level implementation.

Client-Network Signaling

Figure 3. Sequence Diagram of Client-Network Signaling

  1. Client establishes L2 connection with the network and issues DHCP discover
  2. Floodlight intercepts packet, allocates IP and responds with an offer
  3. Client responds to offer by sending DHCP request
  4. Floodlight intercepts request, triggers migration event and DHCP acks
  5. Client receives DHCP ack, establishing L3 connectivity. Meanwhile, the network-level FL controller inserts flows at the root and gateway OVSBs and removes any existing flows belonging to the client.

Steps to use

HandoverTestbed Steps to use the testbed?

[1] Xu, K.; Izard, R.; Yang, F.; Wang, K.-C. & Martin, J. Cloud-Based Handoff as a Service for Heterogeneous Vehicular Networks with OpenFlow Research and Educational Experiment Workshop (GREE), 2013 Second GENI, 2013, 45-49

Last modified 3 years ago Last modified on 11/17/15 18:14:37

Attachments (3)

Download all attachments as: .zip