Changes between Version 14 and Version 15 of HandoverTestbedSummary
- Timestamp:
- 11/17/15 18:07:35 (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
HandoverTestbedSummary
v14 v15 3 3 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. 4 4 5 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 paper 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. 5 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. 6 7 If you need to cite our solution, please use, 8 9 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. 6 10 7 11 === System Framework === … … 34 38 35 39 === Client Component === 40 36 41 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. 37 42 … … 44 49 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. 45 50 51 === Client-Network Signaling === 52 53 [[Image(tridentcom-sequence.png, 50%, align=center)]] 54 55 Figure 2. Client Open vSwitch interface configuration 46 56 47 57 [[wiki:HandoverTestbed Steps to use the testbed]]
