Context Navigation

Project Objective:

Design and implementation of Multihoming on Mobility First Internet Architecture.

Approach:

The current IP based internet architecture is robust and does not provide multihoming as a native feature. But the next generation internet with Mobility First architecture is GUID based which inherently supports multihoming. Though with the capable hardware and the flexible architecture of Mobility First, we can implement multihoming, but it is a challenge to implement it efficiently to improve the reliability, throughput and load balancing while minimizing the latency. We explored different design aspects including policies of multihoming, its efficient implementation on Mobility First internet architecture and performance vs cost analysis for our implementation. We also analyzed the multipath and multicast capability of Mobility First and showed the enhancement in its performance with multihoming. We looked into different aspects e.g. source driven, receiver driven and network driven multihoming, optimization of the policies based on different metrics of link quality measurement, experiments on wireless testbed emulator for performance evaluation and ultimately implementing it in the protocol stack of mobility first internet architecture.

For receiver driven multihoming, the receiver can set priorities to the available network interfaces. Based on different policies, it can set higher priorities to the interface(s), it wants to connect to. Once the priority is set to the interfaces by the receiver, it has to inform to the sender by some signaling or some mechanism. If the sender does not have different policy, it can choose the interface(s) of higher priority to send the data packets.

Sender driven multihoming is basically similar to anycast with best available interface(s) if no priority is assigned from sender itself. But it also can have some local policies to choose the best path(s) for sending the data. The sender priority can overrule the priority set by the receiver as it chooses the interface just before sending the packet.

Multihoming can be network driven as well. If priority is set by receiver and/or sender and updated to the network routers, the router at the bifurcation point can choose the interface(s) for address binding as per its own policies as well. The routers in the network may belong to different ISPs as well, in which case policies at the network are to be determined carefully, as involvement of multiple ISP will cost more and relevant for large enterprise network only . For smaller user groups, we will focus on choosing multiple access points from the same ISP for the implementation of multihoming.

Results:

Work Log:

Analysis:

As per the current implementation, the client is selecting one Wifi interface and/or one Wimax interface and updates that information to the GNRS database server.

In this project, we are going the provide multiple network interfaces to the network based on some weights and will update on GNRS database server. When the Multihoming application is on, and the client moves from one place to another then the weights of those interfaces might change and will be updated in GNRS accordingly. The network will have some policies based on which the sender (in case of Early Binding) or the Router at the bifurcation point (in case of Progressive Binding) will choose the network interface to forward the packet.

Analysing the existing code where we can provide the list of multiple interfaces to the Main thread of client protocol stack, which in turn can publish it to the GNRS database server.

Experiments:

First, we choose one metric as 'signal strength' based on which we want to provide multiple network interfaces to the network.

We performed emulation of wifi interfaces with varying signal strength using orbit testbed ( Attach configuration method). We set one node as clients and 3 nodes as access points and then scanned the access points from the client. We got a list of 3 access points and then we varied the attenuation between the client and the access points to get varied signal strength.

Manually scan the signal strength of different access points in the WINLAB and get an estimated mapping of distance vs signal strength. Then reproduce those values of signal strength by emulating the attenuation on Orbit Testbed.

[06/11/12]
-- Configured the access points on sb4 nodes of Orbit and then created bridge between the client and access point and also among the clients.
-- Analyzed the code of client protocol stack to understand the existing flow. We found that, as per current implementation, it is doing a scan of access point but after that it is selecting only one wifi interface with predefined mac address configured in xml file.
-- We want to break that chain and provide all the wifi interfaces to the Main thread of the stack which can assign different weights to the interfaces accordingly and ultimately this will be updated in GNRS.
-- Side by side , we are doing the emulation of signal strength vs distance. We will do this with the access points available in WINLAB.