Changes between Version 8 and Version 9 of HandoverTestbedSummary


Ignore:
Timestamp:
11/17/15 17:15:25 (6 years ago)
Author:
ljw725@gmail.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • HandoverTestbedSummary

    v8 v9  
    1717The 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.
    1818
     19[[Image(new-client.png)]]
     20
     21Figure 2. Client Open vSwitch interface configuration
     22
    1923=== Network component ===
    2024Within 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.
     
    2933Each 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.
    3034
     35== Client Component==
     36Any 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.
     37
     38
     39Similar 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.
     40
     41
     42Each 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.
     43
     44The 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.
     45
    3146
    3247[[wiki:HandoverTestbed  Steps to use the testbed]]