Implementing Mobile IPv6 for Multimedia *

Transcription

1 Implementing Mobile IPv6 for Multimedia * Joe Finney and Andrew Scott Computing Department Lancaster University Lancaster, UK {J.Finney, A.Scott}@Lancaster.ac.uk Abstract Recent trends show an increasing proportion of portable computing devices in the market today, ranging from laptop PC s to machines the size of a credit card. Most of these devices have the ability to internetwork with other machines over a variety of both wired and wireless media, and dynamically change between these media. If such devices wish persistent connectivity over such a range of networks, a mobile aware routing protocol is required, such as Mobile IP. In this paper we present our experiences, designing, building and evaluating our Mobile IPv6 implementation, which is geared toward providing efficient, low latency handoffs for use in real time distributed multimedia applications. 1. Introduction In recent years, not only have we seen an increase in the popularity, power and diversity of mobile terminals, but we have also seen a merging of concepts from both the networking and telecommunications fields [Katz 98]. Recent advances in mobile computing include the notion of a hierarchical layering of networks, ranging from ATM to cellular telephone networks and satellite communications, known as a wireless overlay network [Stemm 96]. Roaming within overlays is known as a horizontal handoff, and is realised by internal handoff mechanisms, such as the IEEE standard for wireless LANs. Roaming between overlays, e.g. wired Ethernet to wireless LAN, is referred to as vertical handoff, and is achieved by an internetwork roaming protocol, such as Mobile IP. To verify that this approach is a valid one, we created a Mobile IPv6 [Perkins 96,Mobile IPv6] implementation for the Linux operating system, which is highly optimised for low latency handoff. IPv6 was chosen for several reasons. Primarily, this new version of the Internet Protocol is likely to replace the current version of IP within a similar time frame to mobile services becoming widely used on the Internet. Further, more technical, reasons are outlined in the following section. The rest of this paper is organised as follows. Section 2 provides a comparison of Mobile IPv4 and IPv6 concepts, and enabling services. Section 3 discusses optimisations used to achieve high speed network detection, and our performance testing and results is given in sections 4. Future work and conclusions are discussed in section Comparison of Mobile IPv4 and IPv6 Mechanisms While the principle behind both Mobile IPv4 [Mobile IP] and IPv6 is the same, the mechanisms by which this principle is realised are quite distinct. Figure 1 outlines the major differences between the two systems. Note that the Mobile IPv6 system reuses far more standard services than its IPv4 counterpart, for example the use of IPv6 router advertisements [ndisc] for movement detection and address configuration [addrconf]. This negates the need for the presence of a foreign agent on off-site networks, thus allowing a mobile node the ability to roam to any standard IPv6 network. Mobile IPv6 home agents execute as an integral part of an IPv6 router they no longer run on any host on a network. As a result of this, Mobile IPv6 control messages (binding updates, etc.) are carried inside an * J. Finney is in the final year of his PhD work, which has been fully funded by BT Labs UK.

2 IPv6 destination option. This allows these messages to be sent either out of band (as with Mobile IPv4) or in band, at the head of a packet which is already carrying other protocols, such as ICMP, TCP or UDP. Mobile IPv4 Mobile IPv6 Mobile IP Control Messages Carried by UDP, to a well known port number. In/Out of band IPv6 Destination Option Home Agent Location Any host on home network Intrinsic module of IPv6 router Movement Detection From Foreign Agent / observation of broadcast traffic IPv6 Router Advertisement Home Address Configuration Statically Assigned Statically / Automatically Assigned Foreign Address Configuration IP Encapsulation Mechanism Ingress Filter Avoidance Strategy Authentication Protocol From Foreign Agent / DHCP IP in IP tunnelling, using GRE/Minimal encapsulation Reverse Tunnelling MD5 cryptographic hash (broken) IPv6 stateless address autoconfiguration IPv6 in IPv6 tunnelling / IPv6 Routing Header Home Address Option IPv6 Authentication header, IPSec Work In Progress Figure 1 - Comaparison of Mobile IPv4 and Mobile IPv6 Mechanisms Note also the introduction of a Home Address option for Mobile IPv6. This destination option is to be implemented by ALL IPv6 nodes, and provides a solution to ingress filtering problems. The home address option is added to the IPv6 header of every packet sent by a mobile node, and contains that node s permanent home address. On receipt of a home address option, the mobile node s home address is extracted, and replaces the source address of the packet before any transport level processing takes place. This leaves the mobile node free to use one of its care-of-addresses as a source address for it s IPv6 traffic, thus bypassing ingress filtering. This is generally more efficient than the Mobile IPv4 solution of reverse tunnelling, which involves the mobile node forwarding packets via its home agent, which again leads to triangular routing. 2.1 Mobile IPv6 route optimisation To improve the performance of the base Mobile IPv6 protocol, extensions have been defined which avoid triangular routing. These extensions require extra processing on behalf of, not only the mobile node, but also any correspondent nodes with which communication is currently taking place. The advantages of route optimisation, however, can be substantial. Route optimisation under IPv6 is achieved by the mobile node maintaining a list of all nodes with which it is communicating, the binding update list. This list is constructed by monitoring the source address of any encapsulated packets received via its home agent. Any source address that is not currently in the binding update list is added, and a binding update message sent to that address. Whenever the mobile node roams to a different network, another binding update message is sent to each node in the list, informing it of the mobile nodes new location. This ensures every correspondent node has up to date location information. Binding update messages can also be acknowledged to guarantee delivery. On receipt of a binding update, the correspondent node updates the relevant entry in its binding cache, creating one if necessary. The next time a packet destined for the mobile node is to be sent, a lookup is

3 performed on the binding cache and the packet routed directly to the node s care-of address, thus avoiding triangular routing. This is achieved by the use of an IPv6 type0 routing header [IPv6]. 3. Movement Detection While the Mobile IPv6 specification states that movement detection be employed by monitoring unsolicited Router Advertisement messages, other techniques can be used to lower the time taken for a mobile node to detect a change in its surroundings. The effectiveness of using router advertisement messages alone is solely dependent on the rate at which these messages are sent by the foreign router. While Mobile IPv6 specifies that the interval between these messages can be lowered to one second, default intervals of up to 5 minutes are not uncommon. At best, a one second granularity can be achieved. To improve the performance of this detection, our system provides feedback to the IPv6 stack from PCMCIA card services, and device drivers. We use a minimal version of the Linux PCMCIA services, which has been optimised to operate with our Mobile IPv6 system. On insertion of a network card, the relevant driver is loaded into the kernel (as a kernel loadable module), and a single system call invoked, to bring up the new interface. The rest of the configuration is managed in kernel space. This system call is trapped by the IPv6 address autoconfiguration module, which then broadcasts a router solicitation message. On receipt of a router solicitation, an IPv6 router responds with a router advertisement. This process results in an event driven equivalent of the passive monitoring process described earlier. Other sources of information can also be used to detect when a movement may have take place. We have added extra functionality into the Lucent Technologies WaveLAN driver. This modified driver informs the networking stack when a handoff between WaveLAN cells has taken place. This may also constitute roaming to a foreign subnet. This, again, pre-empts a router solicitation, and the mobile node can verify its location. We are also investigating a similar process based on Ethernet link integrity, to further improve the efficiency of movement detection. Figure 2 - IPv6 Testbed

4 4. System Configuration and Performance Testing Performance tests of the Mobile IPv6 (MIPv6) system were tested using our local IPv6 testbed, as illustrated in Figure 2. The IPv6 routers are Intel P166 based PCs and the mobile node a P133 laptop. All machines have 32Mbytes of RAM. The circled numbers on the diagram indicate points where the correspondent node, amazon, was placed for performance testing, and are referenced throughout the rest of this section. The circled MN shows where the mobile node was placed for testing. The subnet corresponding to position 1 is also the home subnet of the mobile node. 10Mbps Ethernet was used as the network medium throughout the course of the experiments. Three separate experiments were carried out, to observe the effects of Mobile IPv6 on effective throughput and round trip times, on both the base implementation and the route optimising system. Profiling tests were also carried out to discover the time taken to complete a vertical handoff, and identify which subsystems were the most heavyweight. 4.1 Throughput tests Throughput was evaluated by a simple datagram based test application. This application sends a stream of UDP packets, each 512 bytes in length, to the mobile node. The mobile node keeps a running total of the amount of data received, and time-stamps the first and last packet. The effective bitrate can then be easily calculated. The transmission bitrate is varied between 1 and 10 Mbps, and is kept accurate by a credit based flow control mechanism, similar to that found in most VoD servers. Each test ran for one minute, and the results were averaged over four runs. As a control for these experiments, the same test was also performed using the mobile node s care-of-address directly, thus bypassing Mobile IPv6. The results from location 1, where the correspondent node is situated on the mobile node s home subnet, provides us with a valuable comparison of the packet processing overheads of MIPv6. From this data, we can conclude that, even in an optimal situation, where triangular routing does not apply, route optimised MIPv6 still slightly outperforms base MIPv6, due to its smaller header size, and simpler packet construction. Figure 3a illustrates these results. The second configuration, where the correspondent node was situated at location 2, highlights a different situation. In this case, base MIPv6 shows substantially worse performance than route optimised MIPv6. This is due to network resource contention at the home agent. In base MIPv6, every packet sent to the mobile node is routed to its home agent, which in turn forwards the packet to the correct destination. In this case, the home agent is forwarding the packets back along the same route as they came from. This results in massive network contention at the home agent, as illustrated in Figure 3b. Route optimised MIPv6 sees no such problem, as the packets are correctly routed at the source. This situation is likely to become exemplified, as IPv6 address allocation [Hinden 95] is hierarchical, this leads to hierarchical routing topologies. Such topologies would amplify this upstream congestion problem. Mobile IPv6 Throughput (1) Mobile IPv6 Throughput (2) Rx Bitrate (Kbps) Control Avg Tunnel Avg Optim Avg Rx Bitrate (Kbps) Control Avg Tunnel Avg Optim Avg Tx Bitrate (Mbps) Tx Bitrate (Mbps) Figure 3a Figure 3b

5 4.2 RTT tests Measuring the round trip time (RTT) between two nodes is an accurate measure of the latency of the network between those nodes. This figure is not only a measure of the time spent on the wire but also reflects the efficiency of the network stack creating, forwarding, and processing the packets. Here we use the RTT to compare the efficiency of the route optimised Mobile IPv6 with basic Mobile IPv6. Figures 4a and 4b show the results of a simple ping test averaged over 30 seconds, from locations 1 and 2. This confirms the discovery made in the throughput experiments, that the overhead in creating route optimised packets is less than that of base Mobile IPv6 tunnelled packets. In fact, route optimised MIPv6 takes 37% less processing overhead than base MIPv6, at location 1, in comparison to control IPv6 stack. Mobile IPv6 RTT (1) Mobile IPv6 RTT (2) RTT (ms) RTT (ms) Control Avg Tunnel Avg Optim Avg 1 Control Avg Tunnel Avg Optim Avg Figure 4a Figure 4b 4.3 Handover tests This experiment measures the time taken for a vertical handoff, using the event driven movement detection procedure for PCMCIA card services, described in section 3. Both the Mobile IPv6 stack and the PCMCIA services were profiled to log the system time at strategic points during the configuration, thus allowing the most heavyweight procedures to be identified Figure 5 shows a timeline of an average vertical handoff. This timeline was generated under a situation we call cold handoff, i.e. where the network device is initially totally unconfigured. Note that the majority of the time is spent initialising the device driver, before any network configuration can take place. Once the device driver is running, it still takes time for the interface to become operational. This is due to the architecture of the PCMCIA card services, which has a user level component to enable the interface. Once the interface is enabled, the IPv6 stack is notified and stateless address autoconfiguration begins to find the mobile node s new care-of address. 160ms later, an address has been acquired, and binding update messages are transmitted from the node. On our local area testbed, binding acknowledgements are received within 5ms. This makes a total latency of 650ms, from card insertion to complete network access. This latency drops to 165ms under warm handoff, where the device is already configured at the link layer, and only dynamic address autoconfiguration and binding update transmission is required. Handoff times of approaching 5ms can be achieved during hot handoff, whereby multiple interfaces are run in parallel, and care-of addresses can be acquired before the handoff takes place. Figure 5 Mobile IPv6 Handoff Overhead To complete the test suite, the MIPv6 stack was tested against a real multimedia application a VoD system, which was developed in parallel. This application provides high quality video streams over an IPv6

6 infrastructure. A 1.5Mbps MPEG1 video clip was streamed to the home address of the mobile node, which was connected to its home subnet via Ethernet. A cold handoff was then performed to a 2 Mbps wireless LAN, connected to a different IPv6 subnet. The route optimised handoff completed with a short (~0.5 sec) break in audio, and little visible effect on the video. A similar phenomenon was observed on a handoff back to the home subnet. 5. Future Work The work described above only begins to solve the problems of distributed multimedia applications in a mobile environment. Application adaptation is an essential component in any scaleable mobile system [Inouye 97], and mobile middleware platforms designed to support these applications are growing in popularity [Fitzpatrick 98]. These platforms and applications could benefit from timely network level feedback on the state of the node s connectivity. Future work will include evaluating the best model for this user level interaction, and observing effects this feedback can have on existing adaptive applications. The communication between network stack and applications need not be unidirectional. Adaptive applications may wish to specify how their data is treated. For example, when a mobile node is away from home, it has a choice of addresses to use as its source address [Cheshire 96]. By default, its home address is used, giving any connections using that address a level of persistence. However, short lifetime, stateless connections would not be able to effectively use route collapsing. Such connections would perform better if Mobile IPv6 were bypassed completely. Examples of such applications include DNS lookups, and, to some extent, WWW browsers. The application must decide the level of persistence required on a per connection basis, as for example, browsing the WWW may not require a persistent connection, but an ftp download initiated within that browser may. The software described in this paper is freely available via anonymous ftp. This includes the Mobile IPv6 implementation, adapted PCMCIA services, our testing software and IPv6 video on demand system. The test data that was gathered is also available on request. References [Addrconf] Thomson, S., and T. Narten, IPv6 Address Autoconfiguration, RFC [Cheshire 96] Stuart Cheshire, Mary Baker, Internet Mobility 4x4, Proc. ACM SIGCOMM 96 [Fitzpatrick 98] Fitzpatrick, T., Blair, G.S., Coulson, G., Davies, N., Robin, P., Supporting Adaptive Multimedia Applications through Open Bindings, To appear in Proc. ICCDS'98, Annapolis MD, USA, May 98. [Hinden 95] R. Hinden, S. Deering, IP Version 6 Addressing Architecture RFC [Inouye 97] Jon Inoyue, Jim Binkley, Jonathon Walpole, Dynamic Network Reconfiguration Support for Mobile Computers, Proc. Mobicom 97. [IPv6] S. Deering, R. Hinden. Internet Protocol, Version 6 Specification, RFC [Katz 98] Randy H. Katz, Beyond Third Generation Telecommunication Architectures: The convergence of Internet Technology and Cellular Telephony. ACM Mobile Computing and Communications Review, Apr. 98 [Mobile IP] C. Perkins, IP Mobility Support, RFC [Mobile IPv6] David B. Johnson, Charles E. Perkins, Mobility Support in IPv6 IETF draft mobileipipv6-05 WORK IN PROGRESS [ndisc] T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for IPv6 RFC [Perkins 96] Charles E. Perkins, David B. Johnson, Mobility Support in IPv6 Proc. Mobicom 96. [Stemm 96] ACM Mobile Networking (MONET), Special Issue on Mobile Networking in the Internet, summer 1998.