Changes between Version 4 and Version 5 of HandoverTestbedSummary
- Timestamp:
- 09/30/15 20:24:36 (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
HandoverTestbedSummary
v4 v5 7 7 === System Framework === 8 8 9 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. \ref{clemson-geni-handover} 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. \ref{clemson-geni-handover}) 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.9 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. 10 10 11 [[Image :(clemson-geni-handover.png)]]11 [[Image(clemson-geni-handover.png)]] 12 12 13 13 Figure 1. Design of the Clemson Geni Handover Testbed 14 14 15 === Network component === 16 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. 17 18 %floodlight controller role/responsibilities 19 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. 20 21 22 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. 23 24 %role of patches between OVSs on gateways/APs 25 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. 26 15 27 16 28 [[wiki:HandoverTestbed Steps to use the testbed]]
