The Impact of DAD on Handoff Performance of Mobile

lidnux

The Impact of DAD on Handoff Performance of Mobile IPv6
and Test of MLD-Based DAD Scheme
Sha Liu*        Shoubao Yang**
*Graduate student of Computer Science, University of Science and Technology of China,
NIC, USTC, Hefei, Anhui, 230026, China, liusand@mail.ustc.edu.cn
**Professor of Computer Science, University of Science and Technology of China,
syang@ustc.edu.cn


ABSTRACT
[1]

In Mobile IPv6 especially in Hierarchical Mobile IPv6 (HMIPv6), Mobile Node’s handoff performance is greatly impaired by the Duplicate Address Detection (DAD) procedure for the newly formed Care-of Address. Based on the data gathered from our HMIPv6 test bed, this paper analyzed the origin of such performance degradation. To alleviate the impact of DAD on handoff performance, Greg Daley et al proposed an Internet draft with extended MLD to help finish DAD earlier. My test is based on such a MLD-based DAD idea and our work detailed the draft and verified that it can contribute to much better handoff performance.

Keywords: DAD, MLD, Mobile IPv6, HMIPv6, Handoff
1 INTRODUCTION
As the network technology advances, mobile appliances become more and more popular. Among many mobile technologies, many features of Mobile IPv6 such as huge address space and direct end-to-end connectivity make it surely the standard of the future mobile communication. To provide multimedia in mobile communication, the handoff performance of Mobile Node (MN) is one of the critical issues.
This paper is devoted to alleviate the handoff performance degradation caused by DAD procedure for the newly formed Care-of Address (CoA). In section 2, we brief the DAD procedure, MLD, Mobile IPv6 and HMIPv6 protocol; section 3 describes how the DAD procedure greatly impacts the handoff performance based on data from our HMIPv6 test bed; section 4 introduces the MLD-based DAD scheme proposed by Greg Daley et al; in section 5, we detail the MLD based DAD scheme for implementation, and the following experiments show that the MLD-based DAD scheme performs much better than the traditional one.
2 DAD, Mobile IPv6 and HMIPv6
2.1 DAD Procedure in IPv6
RFC2462 [2] describes the Duplication Address Detection (DAD) procedure to avoid IPv6 unicast addresses conflict on the same link. When assigning an IPv6 address to a node, the Node set the newly assigned address as Tentative, and sends DupAddrDetectTransmits Neighbor Solicitations (NS) to the Solicit-Node Multicast Address with source address be unspecified address and solicit target be the address to assign, each separated by RetransTimer milliseconds. If during this procedure, no NS or NA for the target address is received, the DAD finished successfully. If the first NS is the first message to be sent from the interface, it cannot be sent until a random delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in RFC2462[2] passes to avoid some racing conditions under certain conditions such as after power failure and up.
2.2 MLD
The Multicast Listener Discovery (MLD) [3] for IPv6 is derived from IGMPv2 for IPv4. This protocol is used by an IPv6 router to discover the presence of multicast listeners on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. It uses three messages: Multicast Listener Query, Multicast Listener Report and Multicast Listener Done.
2.3 Mobile IPv6
Mobile IPv6 [4] is a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. When MN moves from home network to a foreign network, it needs to send Binding Update (BU) to its Home Agent (HA) to register its new location. After receiving the Binding Acknowledge (BA) from HA, it can use its home address to communicate with Internet. MN can also send BU to Corresponding Nodes (CN) to optimize the routing between them.
The procedure described above is called handoff. To deploy Mobile IPv6, the handoff performance is one of the critical issues.
2.3 HMIPv6
Hierarchical Mobile IPv6 (HMIPv6) [6] introduces a new function, the Mobility Anchor Point (MAP). The MAP acts as a temporary HA to process the MN’s local registration. MN in a domain managed by a MAP gets two CoAs: Regional CoA (RCoA) and On-Link CoA (LCoA) and registers the RCoA to HA as its current CoA. When MN starts handoff within the domain managed by the MAP, it only changes its LCoA and registers it to the MAP. With such a micromobility technology, the handoff latency caused by the link delay between HA/MAP and MN is shortened and the mobility signal traffic will be greatly reduced.
3 IMPACT OF DAD ON HANDOFF
  We analyze the impact of DAD on handoff performance of Mobile IPv6 through the data we collected from our HMIPv6 test bed. First we introduce our test bed and the test results, and then we move to the analysis of the data.

3.1 HMIPv6 Test Bed
We construct a HMIPv6 test bed to study Mobile IPv6 and to illustrate the topic of the paper. The topology of our test bed is shown in Figure 1.

Figure 1: Topology of HMIPv6

All nodes of our test bed are equipped with PII 350MHz ~ PIII 550MHz CPU, 128MB SDRAM and 100M Ethernet cards. All links are all 100M Ethernet. AR1 and AR2 serve two subnets with different network prefix respectively.
The HMIPv6 protocol stack and user space tools are Linux kernel 2.4.18 and MIPL 0.9.3 [5] patched by HMIPv6 0.2 [6] from Monash University.
The node marked as “NIST Net” uses NIST Net[7] to emulate several WAN environments between HA and MAP.

3.2 Test Scenario and Result
The scenarios of our test is that MN moves from home network to the domain managed by MAP, then roams between AR1 and AR2, with the RTT between MAP and HA be 100ms, 200ms, and 300ms in three independent experiments. We used tcpdump to record the network events related to MN. The test result is summarized in Table 1, including the RTT between MN and its HA, time of sending BU and receiving BA, and time elapsed between the two events.
From Table 1, we observed the network events illustrated in Figure 2. It consumed much more time than the RTT between MN and its HA. In fact, it is easy to notice that the time elapsed between sending BU and receiving BA is equal to (2+RTT) second.

Table 1: Test result on MN’s registration of new CoA
RTT
BU(s)
BA(s)
Time
100ms
4.098
6.197
2.099
200ms
6.020
8.219
2.199
300ms
0.064
2.363
2.299
3.3 Interaction of DAD and BU Registration
When MN detects the movement, it receives the Router Advertisement and configures the new CoA in a stateless manner. MN sends BU to HA/MAP immediately to achieve better handoff performance, despite that the CoA is still tentative. When the BA from HA/MAP reaches AR, and if the AR has not know the MN’s link layer address yet, the AR sends NS to inquire the link layer address of the MN’s CoA. Because of the random delay before the DAD starts, there are two possibilities as illustrated in Figure 2 and Figure 3.

  In summary, the delay between receiving new AR’s RA and receiving BA from HA is:


In this equation, RTTBU/BA means the link delay between MN and HA/MAP, TPreDAD means the random delay before sending the first NS on a new link.
  When in a HMIPv6 MAP domain, if MN moves from one AR to another, the RTTBU/BA is much less than the counterpart in MIPv6. Let RTTMAP and RTTHA denote each respectively, then we get:
4 MLD BASED DAD SCHEME
From the discussion above, we can see that the traditional DAD procedure will greatly impair the handoff performance of Mobile IPv6. To alleviate such performance degradation, Greg Daley et al proposed an Internet draft with extended MLD to help finish DAD much earlier [8]. In this draft, MLD protocol is extended, and two new message types are added. When MN wants know whether there are duplicate addresses on a link, it sends the Response Request Report message as the format in Figure 4.

Type
Code=1
Checksum
Request ID
Reserved
Multicast Address(32bits)
Figure 4: Response Request Report Message Format

  The Code field is filled with 1 which indicates it’s a Response Request Report Message, the Request ID is a random number generated by MN to indicate who has sent the message, and the Multicast Address field contains the Solicit Node Multicast Address of the new CoA. The other fields are the same as normal MLD reports.
  When the AR receives this message, it checks whether the message is the first message to request to join this Solicit Node Multicast group. If it is the first, the AR sends back a Response message to the Solicit Node Multicast Address as formatted in Figure 5 with the Request ID and multicast address received filled in. After MN receives the response, it checks the Request ID. If it equals the one it previously sent, MN is sure that there are no duplicate addresses on the link, and the DAD procedure can be ended successfully and immediately. At this point we can see that an excellent random number generator is necessary.
Type(TBA)
Code
Checksum
Request ID
Reserved
Multicast Address(32bits)
Figure 5: MLD Report Response Message Format
5 IMPLEMENTATION AND TESTOF MLD BASED DAD SCHEME
  To verify the efficacy of the MLD based DAD scheme, we implemented it on our HMIPv6 test bed. In this section, first some implementation strategies are introduced.
5.1 Implementation Strategies
  The MLD based DAD draft lacks some details. When we do the implementation, we found it is necessary to make it more detailed. In the paper We will present some of them below:
5.1.1 When to Send Code 1 Report
  In normal Linux IPv6 implementation, the MLD report is sent as soon as the node joins the Solicit Node Multicast group. But as we know, Ethernet is a naturally multicast enabled media, so before nodes send the MLD report, it can listen on that multicast address. Furthermore, RFC 2461 requests that the first message to be sent on a link should first be delayed a random time, so current Linux implementation does not conform to the principle.
Therefore, in our consideration, the MLD report should also be delayed. In our implementation strategy, the MLD report sending is triggered by receiving NS for the new CoA. This strategy used the RTT between MN and HA as its random delay before sending first message. From our test results, we found that this strategy performs almost the same as sending MLD report without delay.
5.1.2 When to Send NS for DAD
  As the strategy used on MLD Report sending, the NS for executing DAD is also triggered by receiving the NS from other nodes.
5.1.3 Send NA Immediately after DAD Success
  The reason is rather obvious, from Figure 2 we can see the performance degradation is caused partly by failing to send NA immediately after finishing DAD.
5.1.4 How about Traditional DAD
  As mentioned while visiting MLD based DAD scheme, we found that the Request IDs from different MNs can coincide. Although we can use a perfect random number generator to alleviate this problem, we can not eliminate it. So we decided to let the traditional DAD procedure continue while using the new CoA to correct mistakes under such situations.

5.2 Test Scenario and Results
  The test scenario in which the test on the MLD based DAD scheme is performed is the same as our previous test above. From the results in table 2 and theoretical analysis, we concluded that the delay between receiving new AR’s RA and receiving BA from HA is

,
and in comparison of HMIPv6 and Mobile IPv6, the performance ratio is
The MLD based DAD with our implementation strategies and adapts all scenarios perfectly. The equations above are expressed this way to emphasize the performance improvements.

Table 2: Test results of handoff using MLD based DAD
RTT
Send BU(s)
ReceiveBA(s)
Time(s)
100ms
2.937
3.039
0.102
200ms
10.087
10.289
0.202
300ms
7.917
8.219
0.302

The behavior of handoff when using MLD based DAD scheme can be concluded in Figure 6 and Figure 7.
6 CONCLUSION AND FUTURE WORK
From the analysis and test results above, we can see that traditional DAD procedure will greatly impair the handoff performance of Mobile IPv6, while using MLD based DAD scheme can lead to excellent results.
  Today many optimized DAD schemes are being discussed and evaluated simultaneously, we will try to integrate them to accommodate recommended fast handover schemes in our future work.

REFERENCES
[1] T.Narten et al, Neighbor Discovery in IP Version 6 (IPv6), RFC2461, Dec 1998.
[2] S.Thomson et al, IPv6 Stateless Address Autoconfiguration, RFC2462, Dec 1998.
[3] S.Deering et al, Multicast Listener Discovery (MLD) for IPv6, RFC2710, Oct 1999.
[4] D.Johnson et al, Mobility Support in IPv6, Internet Draft, June 2003.
[5] MIPL,
http://www.mipl.mediapoli.com/
.
[6] Hesham Soliman, Flarion et al, Hierarchical Mobile IPv6 Mobility Management, Internet Draft, June 2003.
[7] NIST Net,
http://snad.ncsl.nist.gov/itg/nistnet/
.
[8] Greg Daley et al, Duplicate Address Detection Optimization using IPv6 Multicast Listener Discovery, Internet Draft, Feb 2003.
[1]
The work reported in the paper was supported by the National 863 Projects.


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/17895/showart_201383.html