Changes between Version 1 and Version 2 of 2012/Projects/Multihoming


Ignore:
Timestamp:
Aug 7, 2012, 12:49:50 PM (5 years ago)
Author:
saburhb
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • 2012/Projects/Multihoming

    v1 v2  
    33 
    44== Approach: == 
    5 Implement Multihoming on Sender and Receiver side of Mobility First. 
    65 
    7 - Sender side Multihoming will be similar to anycast with some exceptions. 
     6The 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. 
     7- 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.  
    88 
    9 - Receiver side Multihoming will be based on user priority metric. When multiple interfaces are available, the user can set priority to the interfaces based on available signal strength, battery usage, available data plan etc. This priority information will be informed to the network by some means of signalling or GNRS database update. Then the Sender or router can choose the interface(s) while binding the Network address based on some policies. 
     9- 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. 
     10 
     11- 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. 
    1012 
    1113