Performance Measurement of Real-Time Mobile Communication in an IPv6 Testbed Nobuyasu Nakajima Toshiba America Research, Inc POBox 136 Convent Station, NJ 07961, USA Abstract This paper presents some experimental results on the performance of real-time mobile communication in an IPv6 testbed For real-time multimedia communication, we adopt Session Initiation Protocol (SIP) as signaling protocol and Mobile IPv6 (MIPv6) to support seamless connectivity While performance measurement of real-time mobile communication consists of several factors, we focus here on the handoff delay due to a node configuration in a typical IPv6 environment In particular, we measure the delay incurred when a mobile node moves to a new location and performs Stateless Address Autoconfiguration and Duplicate Address Detection (DAD) during configuration We also present a detailed analysis and delay measurements with and without DAD for real-time communication I INTRODUCTION The proliferation of wireless devices along with the rapid growth of the Internet is forcing the Internet Community to move from Internet Protocol version 4 (IPv4) [1] to Internet Protocol version 6 (IPv6) [2] The major motivations behind this are the limitation of IPv4 address space Although Network Address Translator (NAT) is widely used to circumvent the address space problem, it does not provide the global routability On the other hand, IPv6 is designed to solve these problems Expanded address space of IPv6 will enable us to assign global routable IP addresses to every possible device willing to connect to the Internet Commercial and non-commercial IPv6-based Internet services are becoming popular Many standard bodies are considering IPv6 for their next generation networks and services For example, 3GPP mandates IPv6 for IP Multimedia Subsystem (IMS) including Voice over IP (VoIP) in Release 5 [3] Operating systems, routers, and other network elements are starting to support IPv6 It is anticipated that all future wireless devices will have built-in IPv6 stack Therefore, wireless service providers are interested in IPv6 based services Apart from data communication, such as file transfer and web browsing, they are more interested in offering real-time services, such as voice and video However, careful investigations are needed regarding the IPv6 performance issues for real-time communication since it has different features than IPv4 In this paper, we discuss some such issues and measure the performance of real-time multimedia communication in our IPv6 laboratory testbed Although several documents such as [4] already mentioned DAD s drawback in the handoff delay, performance measurement is hardly available Reference [5] discusses an IPv6-based mobile communication testbed using SIP and Mobile IP However, measurement or analysis of performance such as delay Ashutosh Dutta and Subir Das Telcordia Technologies, Inc 445 South Street Morristown, NJ 07960, USA was not reported in that paper We are also building our IPv6 testbed in the laboratory using SIP and Mobile IP in order to measure the performance of real-time mobile communication which include various delays, disruptions, packet loss, and even media quality test In this paper, however, we give emphasis on handoff delay due to Duplicate Address Detection (DAD) performed by the mobile node while visiting a new network The rest of the paper is organized as follows Section II briefly presents the IPv6 and its mobility protocol, Mobile IPv6 While Section III describes our testbed configuration, Section IV deals with the handoff delay and in particular the delay caused by DAD Section V depicts the handoff delay measurement and its analysis Finally, conclusion is presented in Section VI A IPv6 II IPV6 AND MOBILE IPV6 The major difference between IPv4 and IPv6 is the length of address field While the address length of IPv4 is 32 bits, that of IPv6 is 128 bits It is anticipated that this huge address space of IPv6 will solve the address space limitation of IPv4 and will enable us to assign global unique IP address to every device in the network Many new features other than address length are available in IPv6 specifications One such interesting feature is Stateless Address Autoconfiguration [6] While DHCP is also available in IPv6 [7], this mechanism allows an interface to assign an IPv6 address automatically, based on the network prefix advertised by the router and the unique information of the interface, eg, MAC address Security is also integrated into IPv6 For example, IPSec [8] is mandatory in IPv6 node while it is an option in IPv4 This gives a secure data communication as well as an authentication of each packet transmitted B Mobile IPv6 Mobile IPv6 (MIPv6) [4] provides a mechanism to support mobility in IPv6 It is already accepted by the industry and is expected to be an IETF standard in the near future In MIPv6, each Mobile () has its home network and is assigned unique IP address called home address The prefix of this address is the same as that of the home network gets a new IP address when it moves to a network other than the home network This new address is called care-of address (CoA) and essentially provides the s current point of attachment to the network Another node called Home Agent () is located in s home network and is responsible for maintaining the
Home Network Mobile () Correspondent (CN) Testbed Backbone Home Agent () 2 1 4 Binding Update to CN IPv6 A IPv6 B E1 Home Network E2 Visited Networks E3 Binding Update to Mobile Visited Network 1: data path when at home () 2: data path without route optimization when away from home 3: tunnel from to at CoA 4: route optimized path between and CN Fig 1 3 Mobile IPv6 s current point of attachment Fig 1 shows the basic operation of Mobile IPv6 In the base protocol, when an is in its home network, sent by the Correspondent (CN) which uses s home address as a destination address reaches directly When moves to a network other than its home network, will reach via after completing following two steps: i) once gets a new CoA in the visited network, it sends a Binding Update (BU) to in order to inform of its current CoA, ii) upon receiving a BU, captures destined for and forwards them to s new CoA However, can also send BUs to CNs directly while sending BUs to Assuming CNs have the capability to process these BUs it can send directly to an using s new CoA This technique is popularly known as route optimization It is important to note that while route optimization is an option for MIPv4, it is now specified within MIPv6 III TESTBED FOR REAL-TIME MOBILE COMMUNICATION USING IPV6 We extended our existing IPv4-based multimedia testbed [9] to support IPv6-based mobile multimedia communication While our IPv4 testbed has been built using IEEE 80211b network and has capabilities such as, rapid auto-configuration, mobility support in various layers, QoS and user/device authentication and authorization, IPv6 testbed presently has limited capabilities such as, Stateless Address Autoconfiguration, Mobile IPv6 (MIPv6) and SIP for signaling A Testbed Configuration and Components Fig 2 shows the configuration of our experimental IPv6 testbed It consists of two routers ( A & B), an,, and CN A has two ethernet segments: one for the home network and another for the B On the other hand, B has three ethernet segments; two for visited networks and one for the connection to A We use Linux 249 kernel in our testbed Additionally, a patch for better conformance with IPv6 specification developed CN Fig 2 H31 H12 s movement H23 Experimental testbed configuration by USAGI projects [10] is applied to the kernel We also integrate MIPL Mobile IPv6 [11] code to support mobility This includes the MIPv6 s Mobile, Home Agent, and Correspondent functionalities Stateless Address Autoconfiguration [6] is introduced for s IPv6 address configuration As mentioned earlier, we use Session Initiation Protocol (SIP) [12] as a signaling protocol which is also used for multimedia sessions in the Internet In the testbed, both the and the CN are equipped with SIP User Agent (UA) which establishes Voice over IP session In fact, Columbia University s SIP UA implementation [13] is used in our testbed However, we modified it to comply with IPv6 specification We also use RAT [14] to support media application program It is a voice communication tool over IPv4 as well as IPv6 Because mobility is supported by MIPv6, SIP messages as well as media are sent to the even when the moves to the visited network IV NDOFF DELAY A Components of Handoff Delay Fig 3 depicts the sequence of handoff process and its delay components in details We define handoff delay (D) as the delay when a mobile node changes its location and attaches to a new subnet so that it is capable of communicating with other nodes such as and CN It essentially consists of three components: i) lower layer switching delay (D 1 ), ii) delay for detecting a new router (D 2 ), and iii) MIPv6 registration delay (D 3 ) Therefore, D = D 1 + D 2 + D 3 (1) In particular, D 1 is the layer-2 switching delay D 2 pertains to the detection of the new access router In IPv6, this is achieved by means of Advertisement (RA) By listening to a new RA, determines the subnet change In fact, maximum value of D 2 can be one RA interval Finally, D 3 refers to MIPv6 registration delay It works as follows: after receiving the new RA, configures its interface with new CoA and informs and/or CNs of the new CoA via Binding Update
detachment from old access medium attachment to new access medium handoff detection DAD completion D handoff completion D1 D2 Advertisement Binding Update Binding Acknowledgement C Analysis of Duplicate Address Detection Delay Fig 4 depicts the delay caused by DAD In the figure, a random delay D rand between 0 to a certain maximum value (D rand,max ) has been chosen and is applied before sending out NS for DAD event We also denote the number of transmissions of NS and the interval of the transmission of the two consecutive NSes as N and D ret In our testbed, all these variables are configurable system parameters The average delay caused by DAD is therefore D DAD = D rand + N D ret, (2) Fig 3 Handoff flow (BU) message In reply, sends Binding Acknowledgement (BA) to process It should be noted that BA from CN is optional in MIPv6 Although D 1 and D 2 are equally important to the delay performance in a real-time mobile communication, in this paper, we measure D 3 and analyze it However, we believe that D 1 is specific to link layer and can be reduced For example, D 1 can be considered zero for link layer technologies supporting soft handoff On the other hand, D 2 depends upon the frequency of router advertisement and could be large in a bandwidth constraint environment in which D DAD and D rand denote the average of D DAD and D rand, respectively In our testbed, D rand,max is 1000ms, N is 1, and D ret is 1000ms, which are also default values in [6] Since D rand is uniformly distributed, D DAD = 1500ms (3) Although DAD is mandatory in [6], Mobile IPv6 suggests that one may use new IPv6 address while performing the DAD in parallel with MIPv6 signaling or without performing the DAD If DAD can be avoided, one can eliminate the delay, D DAD, and as a result handoff performance will be improved Following this approach in our testbed, we can reduce the average handoff delay by 1500ms B Duplicate Address Detection The purpose of Duplicate Address Detection (DAD) is to confirm the uniqueness of the IPv6 address on the link In fact, DAD plays an important role in MIPv6 registration delay It is performed between an RA and a BU (Fig 3) Before an assigns a new address (also known as tentative address) to its interface, it sends out a (NS) on the local link This is to verify whether any other node on the link is having the same address When the pre-determined transmission time expires and does not receive a reply, assumes that no other node on the link has this tentative address and finally assigns this to its interface as a valid address According to [6], a tentative address is not allowed to be used by a node before completing the DAD This means that the cannot send with a tentative address as a source IPv6 address and has to discard all inbound during DAD phase This may cause the delay in sending out a BU and also receiving a BA On the other hand, in order to achieve a fast handoff, should inform of the change of CoA as quickly as possible by sending a BU In fact, this should happen just after the listens to the new RA and generates its new CoA address However, until DAD is done, cannot send a BU carrying the new CoA and therefore adds a substantial delay to the component of D 3 We refer here D DAD as the delay due to DAD and is measured as the time between the router advertisement and DAD completion In the next subsection, we analyze D DAD and it turns out that D DAD is a significant component of D 3 V NDOFF DELAY MEASUREMENT A Measurement Procedure The effect of DAD on the performance of handoff delay was discussed in the previous section In this section, we present our measurements on handoff delay in our testbed for two cases: i) using DAD, and ii) without using DAD We modified IPv6 stack not to perform the DAD but to accept and process other The handoff delay was measured by monitoring the in the testbed for both the cases Although we have already installed IEEE 80211b access points in our IPv6 testbed, we used wired ethernet for this measurement in order to eliminate additional errors related to wireless technologies such as, packet error, packet loss, processing handoff detection DAD completion Drand Fig 4 DAD delay Advertisement
delay in the wireless access points Handoff is emulated by disconnecting the s Ethernet cable and connecting the cable to the new hub attaching to the new router As seen in Fig 2, starts from its home network, E 1, and then moves to E 2 and E 3, two visited networks in our testbed, and finally returns back to its home network, E 1 In short, goes along the following path during one measurement; E 1 E 2 E 3 E 1 The handoff from E 1 to E 2, E 2 to E 3, and E 3 to E 1 are labeled as H 12, H 23, and H 31, respectively Handoff delay was measured by analyzing the tcpdump output gathered at the Table I shows the average handoff delay measured 10 times for each handoff case In Table I, we see a substantial performance improvement of the handoff delay for H 12 and H 23 without DAD While the average handoff delays with DAD for H 12 and H 23 are 19099ms and 20123ms, respectively, those without DAD are 15ms and 20ms It should be noted that during our measurement does not perform DAD when returning to its home network This happens only when returns to its home network before the expiry of current binding This behavior is reflected in Table I for the case of H 31 with DAD Moreover, the home address should always be retained for the regardless of its location In order to protect the s home address against other nodes performing DAD, should act as a proxy on behalf of and perform the DAD while is away from the home network Now we will analyze these results in the following subsections B Analysis of Measured Delay with DAD An example of message flow in the case of the handoff, H 12, with DAD is shown in Fig 5, which was collected mainly at the The time in the left hand side of each message represents the relative time which begins at the reception of Advertisement (RA) ((a), in Fig 5) and is measured in milliseconds RA also indicates the starting point of measurement of D 3 According to this implementation of MIPv6, a Binding Update (BU) ((b), in Fig 5) from the occurs immediately after receiving the RA ((a), in Fig 5) Due to DAD, however, the does not use the new CoA generated by Stateless Address Autoconfiguration based on the prefix in the RA This implementation of Mobile IPv6 picks the s home address instead of CoA as a source address Since this messages does not carry the care-of address it fails to perform the Binding Update function TABLE I AVERAGE NDOFF DELAY FOR EACH NDOFF CASE with DAD without DAD H 12 19099 ms 15 ms H 23 20123 ms 20 ms H 31 N/A 10 ms 0 ms 07 ms 728 ms 10728 ms 15029 ms 15033 ms 15034 ms 15035 ms 15233 ms Fig 5 CN (a) RA (d) DAD completed (g) NS (h) NA (f ) BA (j) BU (c) NS for DAD (e) BU with CoA (f) BA tunnel (b) BU with Home Address Example of the message flow with DAD (i) UDP (k) UDP After a random time, which is 728ms in this particular measurement shown in Fig 5, the sends a (NS) ((c), in Fig 5) for the purpose of DAD Although this is not a signaling message, the symbol (d) in Fig 5 represents the completion of DAD and occurred in 1000ms after sends out the NS, ((c), in Fig 5) We see the behavior of DAD in Fig 5 is the same as discussed in subsection IV-C When the does not get a Binding Acknowledgement (BA) in reply to the initial BU, it retransmits the BU ((e), in Fig 5) which occurred in approximately 1500ms after it sent the initial BU Due to the completion of DAD, the second BU at this time can carry the correct CoA to the Thus the can send the BA, ((f), in Fig 5) After exchanging Neighbor Solicitation ((g), in Fig 5) and Neighbor Advertisement ((h), in Fig 5) with the router for address resolution, receives the BU ((f ), in Fig 5) at 15035ms, and it also indicates the end point of the delay measurement Thus from Fig 5, we see D 3 is 15035ms, which is too long for real-time communication The also sends another BU ((j), in Fig 5) to the CN Before receiving this BU, CN is not aware of the change of s IP address and accordingly (as referred to (i), in Fig 5) from the CN would go via the Once CN receives the BU it starts sending to the directly (referred to (k), in Fig 5) instead of It should be noted that the Binding Update retransmission is managed by Mobile IPv6 module which is independent of the DAD process in this implementation In Fig 5, BU is retransmitted in 1500ms after the initial BU However, in this MIPv6 implementation, another BU retransmission is required after 1000ms ie, 2500ms in our measurement scale, if the DAD phase is not finished On the other hand, DAD in this IPv6 implementation completes between 1000ms to 2000ms
as discussed in subsection IV-C Considering both the DAD and BU retransmission conditions the correct BU which carries the new care-of address can be sent in either 1500ms or 2500ms after receiving an RA The variance is due to the fact that it depends upon DAD completion time, which is uniformly distributed Thus, we can infer that the average handoff delay is 2000ms which very well matches with our measurement as shown in Table I C Analysis of Measured Delay without DAD Fig 6 shows an example of message flow in the case of the handoff H 12 without DAD In Fig 6, message (a) represents the new RA, which is the starting point of the measurement of D 3 Since DAD is not performed here, BU ((b), in Fig 6) has the correct CoA also sends a BA ((c), in Fig 6) immediately and it ends the delay measurement Before the router forwards the BU to the, the router and the have to exchange NS ((d), in Fig 6) and NA ((e), in Fig 6) for address resolution However, the delay added to D 3 by these two messages is very small Our measured delay is 17ms in this particular example Table I shows the average handoff delay, which is 15ms for H 12 and 20ms for H 23, respectively The measurement results show that avoiding DAD improves the delay D 3, since D DAD becomes almost negligible Also in Fig 6, another BU ((h), in Fig 6) is sent to the CN As we see with earlier result, avoiding DAD also improves the delay in sending the BU to the CN Address Detection (DAD) We performed extensive measurement on delays with and without the DAD It shows that for real-time applications DAD related delays are substantial and it will improve the performance a great deal if we can avoid the DAD phase Although avoiding DAD improves the handoff delay, we face the risk of not detecting the IP address collision The probability of the address duplication in the case of Stateless Address Autoconfiguration seems to be negligible if the uniqueness of lower layer address is guaranteed However, we still have the possibility of address duplication, because any IP address can be freely assigned to interfaces with or without any prior intention This may cause some vulnerability in the network from security perspective, which is an open issue Given the delay sensitive real-time applications, we would suggest to avoid the DAD phase, however, additional policy enforcement or mechanism may be necessary to guarantee uniqueness of IPv6 address As a future work, we would like to perform more experiments on several other issues which are critical for the performance of real-time mobile communications in an IPv6 environment ACKNOWLEDGMENTS The authors greatly appreciate the interesting and helpful discussions by ITSUMO project members Ashutosh Dutta would like to acknowledge Prof Henning Schulzrinne for many helpful discussion VI CONCLUSION In this paper, we describe some experimental results on realtime mobile communication in an IPv6 laboratory testbed We integrate SIP and MIPv6 in order to support real-time multimedia communication and seamless roaming Several modifications and changes were made to the publicly available IPv6, MIPv6, and Columbia University SIP User Agent code While several components in an s handoff delay are discussed in this paper, we give emphasis on the delay related to Duplicate 0 ms 07 ms 16 ms 17 ms 17 ms 638 ms Fig 6 (a) RA (b) BU (d) NS (e) NA (c ) BA (g) BU (c) BA tunnel CN Example of the message flow without DAD (f) UDP (i) UDP REFERENCES [1] Jon Postel (Editor), Internet Protocol, RFC791, September 1981 [2] S Deering and R Hinden, Internet Protocol, version 6 (IPv6) specification, RFC2460, December 1998 [3] 3rd Generation Partnership Project, Technical specification group services and system aspects, 3rd Generation mobile system Release 5 specifications, 3GPP TS 21103, work in progress [4] D B Johnson and C Perkins, Mobility support in IPv6, draft-ietfmobileip-ipv6-15txt, July 2001, work in progress [5] P Flykt and T Alakoski, SIP Services and Interworking with IPv6, Second International Conference on 3G Mobile Communication Technologies, March 2001, pp186-190 [6] S Thomson and T Narten, IPv6 stateless address autoconfiguration, RFC2462, December 1998 [7] J Bound, M Carney, C Perkins, T Lemon, B Volz, R Droms, Dynamic Host Configuration Protocol for IPv6 (DHCPv6), draft-ietf-dhc-dhcpv6-23txt, February 2002, work in progress [8] S Kent and R Atkinson, Security architecture for the Internet Protocol, RFC2401, November 1998 [9] A Dutta, J-C Chen, S Das, M Elaud, D Famolari, S Madhani, A McAuley, M Tauil, S Baba, T Maeda, N Nakajima, YOhba, and H Schulzrinne, Implementing a testbed for mobile multimedia, Proceedings of IEEE Globecom 2001, San Antonio, Texas, USA, November 2001 [10] http://wwwlinux-ipv6org [11] A J Tuominen and H Petander, MIPL Mobile IPv6 for Linux in HUT campus network MediaPoli, Proceedings of Ottawa Linux Symposium 2001, Ottawa, Canada, June 2001 [12] M Handley, H Schulzrinne, E Schooler, and J Rosenberg, SIP: Session Initiation Protocol, RFC2543, March 1999 [13] http://wwwcscolumbiaedu/ hgs/software/sipc [14] V Hardman, M A Sasse, M Handley, A Watson, Reliable audio for use over the Internet, Proceedings of INET 95, Honolulu, Hawaii, June 1995