Internet Draft Hong-Yon Lach draft-lach-nemo-experiments-overdrive-01.txt Christophe Janneteau Expires: April 2003 Alexis Olivereau Alexandru Petrescu Motorola Tim Leinmueller Michael M. Wolf DaimlerChrysler Markus Pilz University of Bonn October 2003 Laboratory and "Field" Experiments with IPv6 Mobile Networks in Vehicular Environments Status of this Nemo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document gives a short high-level overview of experiments performed with IPv6 mobile networks using Mobile IPv6-based NEMO extensions in the context of the IST OverDRiVE project. Laboratory experiments include simple and nested mobile networks in a pure IPv6 environment while "field" experiments demonstrated continuous IPv6 vehicular connectivity over two publicly deployed IPv4 networks: 2.5G (GPRS) and Wireless LAN 802.11b deployed around and inside a metropolitan area. Lessons learned included the necessity for Route Optimization protocols for mobile networks, NAT traversal and IPv4-to-IPv6 transition protocols in public access wireless networks. Lach, et al. Expires April 2003 [Page 1] Internet Draft OverDRiVE Experiments 23 June 2003 Table of Contents Status of this Nemo................................................1 Abstract...........................................................1 Conventions Used in this Document..................................2 1. IST OverDRiVE Project...........................................2 2. Laboratory Experiments..........................................3 3. "Field" Experiments.............................................6 4. Conclusions and Future Work....................................10 Acknowledgements..................................................10 References........................................................11 Authors' Addresses................................................12 Changes...........................................................12 Copyright Notice..................................................13 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 1. IST OverDRiVE Project Work Package 3 of the European research project OverDRiVE [3] aims at developing IPv6 protocol mechanisms to support mobility of hosts, as well as of networks, that are deployed in vehicular environments. The scenarios envision that future vehicular environments in trains, ships or vehicles provide on-line information to the driver and passengers; provide even access to the vehicular communication components from the outside world (e.g. allow for software downloads be pushed to car computers). All electronic devices deployed in a vehicle (PCs, head screens, engine computers and sensors) are connected together with IPv6 protocols, and to the IPv6 Internet; the connection is realized either directly or through other IPv4 tunneling and gatewaying means. The project has defined a set of scenarios which should be supported by a mobility (and security) solution [8]. The following two major characteristics are valid for all scenarios: - Session continuity while changing the point of attachment to the Internet. - Reachability of the mobile nodes regardless of the current point of attachment. Thus, several functional scenarios become relevant: - Moving of an Intra-Vehicular Area Network (IVAN): the IVAN moves homogeneously (network entities stay together) using a mobile router to provide the Internet connectivity for nodes within the IVAN. - Moving into an IVAN with a mobile device. The mobile host moves into an IVAN and changes its WMAN connection to a WLAN connection, or its UMTS connection to a Bluetooth connection. - Moving within an IVAN: in a larger IVAN (e.g. in a train) topological hierarchies might be used, involving more than one fixed (with respect to IVAN) or mobile router. Mobile nodes can move around inside the IVAN connecting to the appropriate access router inside the IVAN. Lach, et al. Expires April 2003 [Page 2] Internet Draft OverDRiVE Experiments 23 June 2003 2. Laboratory Experiments Several laboratory experiments in a pure IPv6 network were performed with mobile hosts and mobile networks. In some scenarios, more than one Local Fixed Node and one Correspondent Node were used; for example, in some scenarios there is an additional Mobile Host, or there are two mobile networks each hosting a Local Fixed Node. During all experiments, the mobility management messaging (between MR and HA, or between MH and HA) was not interrupting the end-to-end communication between these entities, even if several changes in Care-of Address were occuring. The end-to-end communications were happening between the LFN and the CN, or between two LFN's, or between one MH and one LFN, or between one MH and one CN. The CN's used were local video streaming servers and other servers connected on other parts of the worldwide IPv6 Internet. A simple mobile network is composed of one Mobile Router and one Local Fixed Node, see Figure 1. The mobile network is initially attached at home and moves subsequently to Access Router AR1 and AR2. ---- CN link --| BR1|------ ---- / ---- | | HA | / ---- ---- ----------/ | CN | | ------- | | ---- ----------------| BR |---| Network |-------------- | home link ------- | | | ---- ----- ----------\ | | MR | | LFN | \ | ---- ----- \ | | | ------ ------ --------- | AR1 | | AR2 | mobile net link ------ ------ | | Figure 1: Simple Mobile Network Figure 2 depicts another setting with one Mobile Router, one Mobile Host, same Home Agent. In a first scenario, the mobile network starts at home and then moves under AR1 and AR2. The Mobile Host stays at home. Lach, et al. Expires April 2003 [Page 3] Internet Draft OverDRiVE Experiments 23 June 2003 Related to the same figure, another scenario is that the mobile network and the mobile hosts are first placed at home and then the mobile host moves under the mobile network. Subsequently the mobile network moves together with the mobile host under AR1 and AR2. And still with the same figure, yet another scenario; every entity is at home, then MH moves under AR1, then the mobile network moves too under AR1; then MH moves towards the mobile network and, finally, the mobile network moves to AR2. ---- CN link --| BR1|------ ---- ---- / ---- | | HA | | MH | / ---- ---- ---- ----------/ | CN | | | ------- | | ---- ----------------| BR |---| Network |-------------- | home link ------- | | | ---- ----- ----------\ | | MR | | LFN | \ | ---- ----- \ | | | ------ ------ --------- | AR1 | | AR2 | mobile net link ------ ------ | | Figure 2: Mobile Router and Mobile Host at Home Figure 3 shows a setting where the mobile router and the mobile host have different Home Agents. Various movements were performed. ---- --| CN | ---- / ---- ---- ---- | HA1| / | HA2| | MH | ---- ----------/ ---- ---- | ------- | | ------- | | ----------------| BR |---| Network |-----| BR |-------------- | home link ------- | | ------- ---- ----- ----------\ | MR | | LFN | \ ---- ----- \ | | ------ --------- | AR1 | mobile net link ------ | Figure 3: Mobile Network and Mobile Host with Different Homes In figure 4, the Mobile Host and the Mobile Router have two different Home Agents, both situated on the same home link. Various movements were performed. Lach, et al. Expires April 2003 [Page 4] Internet Draft OverDRiVE Experiments 23 June 2003 ---- CN link --| BR1|------ ---- ---- ---- / ---- | | HA1| | HA2| | MH | / ---- ---- ---- ---- ----------/ | CN | | | | ------- | | ---- -------------------| BR |---| Network |-------------- | home link ------- | | | ---- ----- ----------\ | | MR | | LFN | \ | ---- ----- \ | | | ------ ------ --------- | AR1 | | AR2 | mobile net link ------ ------ | | Figure 4: Home Agents on the Same Home Link In figure 5, one Home Agent is placed in the mobile network. Various movements were performed. ---- CN link --| BR1|------ ---- / ---- | | HA1| / ---- ---- ----------/ | CN | | ------- | | ---- ----------------| BR |---| Network |-------------- | home link ------- | | | ---- ----- ----------\ | | MR | | LFN | \ | ---- ----- \ | | | ------ ------ --------- | AR1 | | AR2 | | | ------ ------ ---- ---- | | | HA2| | MH | ---- ---- Figure 5: Home Agent in the Mobile Network An additional range of laboratory experiments were performed and reported in section 2.4 of [8]. Examples include: -a single Home Agent and two similar mobile networks, each composed of one Mobile Router and one Local Fixed Node. -two Home Agents and two Mobile Routers (one Home Agent for one mobile network), but still one home link. -two Home Agents and two Mobile Routers (one Home Agent for one mobile network), but on different home links. -a Home Agent placed inside a mobile network serving another mobile network attached to the first. Lach, et al. Expires April 2003 [Page 5] Internet Draft OverDRiVE Experiments 23 June 2003 The descriptions in section 2.4 of [8] include details of tunnel setup procedures and illustrations of MN-HA encapsulations, as well as packet paths between various entities. The laboratory experiments helped highlighting several areas for protocol improvement of the basic support of network mobility: -Excessive tunnelling ("thick" tunnels): when MH attaches to the mobile network there are two MRHA encapsulating tunnels involved in the CN-MH path. Several levels of mobile networks induce excessive tunnelling that can lead to serious packet loss and worsen stack behaviour due to excessive fragmentation/reassembly. This is especially true in wireless environments. -Crossover tunnels happen when the path between one tunnel's endpoints includes only one of the other tunnel's endpoints . A situation leading to crossover tunnels is depicted in Figure 16 of [8], where a HA is deployed inside a mobile network. The initial configuration is in diagram a and diagrams b, c and d represent snapshots of the movement scenario. The MR2HA2 tunnel setup procedure corresponding for the diagram d is practically impossible to perform. -Externally influenced intra-aggregation communication (or disconnected operation problem): in the MH and MR with same HA case, depicted in diagram c of Figure 12 of [8], the LFN-MH communication (intra-aggregation) is influenced by the communication between MR and AR1 (external). If MR looses connection to AR1, then LFN looses connection to MH, a fact that, as paradoxical as it may seem, is a veritable side effect of tunnelling itself. -Under-optimal paths: when comparing the length of the CN-MH communication path depicted in top-left diagram of Figure 13 of [8] to the CN-MH communication in Figure 15 of [8], it is clear that the path taken by packets is much longer than the optimal. The first diagram can be considered as an ideal to be attained, and the only optimal path that can be achieved is CN-AR-MR-MH (eliminating the BR-HA-BR additional segment). This is not the ideal path (since MH is not physically home) but represents an achievable goal, if employing Route Optimization techniques. -Asymmetric communication paths: outgoing communication paths have different lengths than incoming communication paths, between the same two entities. See example in Figure 14 of [8]. 3. "Field" Experiments "Field" experiments were performed in a typical deployment of wireless networks. An overall picture of the experiments is described in Figure xx. Three wireless access networks are depicted: the home network (hosting the Home Agent), the Orange network (an European Telecom operator for mobile phones) and the Wixos network (a WiFi HotSpot network deployed in a large city). Lach, et al. Expires April 2003 [Page 6] Internet Draft OverDRiVE Experiments 23 June 2003 The three networks are inter-connected at Internet level. The Mobile Network, pictured at the bottom, was obtaining Internet access via one of the three Wireless Access Networks. ------------ ----------- | Internet |-----------| Web Server| /------------\ ----------- / | \ / | \ / | \ -------- -------- ------- |Home Net| | Orange | | Wixos | -------- -------- ------- | | | Wireless Access WLAN GPRS | | ---------- |Mobile Net| ----------> ---------- Figure xx: Overall Picture of Field Experiments 3.2 Mobile Network The mobile network used in the field experiments is a very simple wireless segment (802.11b in ad-hoc mode) linking together an IPv6 Mobile Router and a Local Fixed Node running user applications (notably an http client). In addition, the mobile network contained two boxes helping interconnect the MR to the wireless access networks (FrontBoxes). Inside the mobile network, IPv6 protocols are used exclusively; the Mobile Router runs an implementation of Mobile IPv6 Mobile Router in implicit mode [2]. However, both Orange and Wixos offer IPv4 access exclusively. FrontBoxes help solve this problem. Front boxes are entities connected to the Mobile Router that help differentiate between mobility management tasks and particular link layer/tunnelling functionalities. The GPRS Front Box establishes a GPRS connection (i.e. establishes a PPPv4 connection, through a PDP Context to the GPRS SGSN), configures an IPv4 interface and establishes a UDP tunnel through a NAT box to the home IPv6 network, all over its egress interface. The ingress interface of the FrontBox is assigned an IPv6 address and prefix (deduced from the IPv6 prefixes of the home network); the FrontBox sends IPv6 Router Advertisements over its ingress interface towards the Mobile Router. Tunnelling IPv4 packets into UDP IPv4 streams in order to traverse NAT is proposed in [12]. In these experiments, IPv6 packets were tunneled instead. Similarly, the Wireless LAN Front Box offers native IPv6 connectivity towards the Mobile Router, when the mobile network attaches to the Wixos WiFi HotSpot network. Lach, et al. Expires April 2003 [Page 7] Internet Draft OverDRiVE Experiments 23 June 2003 3.3 Home Network The home network is connected to both IPv4 and IPv6 Internets. It hosts an IPv6 Home Agent, a 6to4 Gateway and a Udptun Gateway. The Home Agent runs Mobile IPv6 with NEMO implicit mode [2]. The Udptun Gateway constitutes the UDPv4 tunnel endpoint for both the GPRS and WLAN FrontBoxes. In addition, the home network offers two WLAN access points towards the mobile network. One of the AP's is connected to the home link (where HA resides); the other AP is attached to another link of the home network. Both AP's offer native IPv6 connectivity towards the Mobile Router; when the MR connects to the home network AP's, it does by bypassing the FrontBoxes. 3.4 Orange Wireless Access (GPRS) The GPRS access system offer IPv4 access with a private addressing scheme. It distributes private non-routable addresses (10.x.y.z) over a PPP connection, addresses being assigned by DHCP servers. This network is connected to the Internet with NAT boxes. 3.5 Wixos Wireless Access (WLAN) Wixos is an 802.11b Metropolitan Area Network. During June 2003, the Wixos network was available for public experimentation. For more information about the Wixos network see [6]. Disclaimer: none of the participants in the IST OverDRiVE project are affiliated, or represent, in any legal or other way the Wixos Network. The Wixos network was used as a public access network. The network offers IPv4 access in several "hotspot" areas. Most of the hotspots are not overlapping (in terms of wireless coverage). The IPv4 network offers private non-routable IPv4 addresses. The network was not using, at the time of testing, any form of Mobile IPv4; an address acquired in one WiFi hotspot is not valid under another WiFi hotspot of the same Wixos network. 3.6 Scenarios and Results In one scenario, the mobile network was first connected to the home network outside the metropolitan area, then moved onto the highway, then entered a metropolitan area hotspot, then went out of the hotspot and entered again another hotspot. During all this trajectory, a continuous IPv6 connection was maintained between the Local Fixed Node and a Correspondent Node (web server kame.net, placed in Japan) connected on the IPv6 Internet. In another scenario, the Local Fixed Node running exclusively IPv6 protocols, browsed an IPv4 web server. This could be accomplished by configuring a "proxy" server on the LFN client. The proxy server is connected to both the IPv6 and IPv4 Internets; it is physically placed at University of Bonn. The proxy server converts http IPv6 requests into IPv4 requests, forwards the request to the IPv4 Internet, and forwards the received IPv4 reply back to the IPv6 client of the LFN. Lach, et al. Expires April 2003 [Page 8] Internet Draft OverDRiVE Experiments 23 June 2003 The first mobility scenario (mentioned above) involved a dynamic change of IP addresses (both v4 and v6) to the Mobile Router. However, the IPv6 address of the LFN was not changing and, as such, the applications running on the LFN were not interrupted. Hiding the change of IP address was performed at two levels of different granularity. The dynamics of address assignment to the Mobile Router and FrontBoxes is depicted in figure xx. AP1 AP2 BS1 BS2 shadow BS3 AP3 BS4 AP4 \______/ \_______|_______/ | | | | No ad ad1 ad2 ad3 ad4 ad5 | | \_______|_______________/ | | | AD1 AD2 AD3 AD4 AD3 AD4 Figure xx: Dynamics of IPv4 and IPv6 Address Assignment The first line in figure xx depicts the sequence of WLAN Access Points and GPRS Base Stations to which the Mobile Router and FrontBoxes attach. AP1 and AP2 are both in the home network (AP1 connects HA). BS1 and BS2 are deployed along the highway segment, and the "shadow" area depicts an uncovered segment along the highway (a tunnel). BS3 is deployed at junction zone between highway and city. AP3 and AP4 are the hotspot areas, separated by BS4. Dynamics of IPv4 address change show a high level of granularity (fine-grained). The IPv4 addresses distributed either by GPRS or by WLAN are pictured on the second line, lower case. When the mobile network connects to the home network, no IPv4 address is assigned. Under BS1 and BS2, the mobile network is assigned IPv4 address ad1. Switching between these two BS's does not incur a change in the IPv4 address, ad1 is kept. Due to the presence of the shadow area (the uncovered tunnel), the mobile network will be assigned a new IPv4 address (ad2) under BS3. Even though GPRS ensures the same IPv4 address assigned to a mobile, there exists no mechanism to assign the same IPv4 address to the same mobile following a short disconnection. Dynamics of IPv6 address change show a lower level of granularity (coarse-grained). Assignment of IPv6 addresses to the Mobile Router (the Care-of Addresses) is pictured on the bottom line. At home, IPv6 addresses AD1 and and AD2 are assigned to the Mobile Router, AD1 being the Home Address. Whenever the GPRS FrontBox is conneted to a BS, AD3 is assigned to the Mobile Router (BS1-4). Whenever the WLAN FrontBox is connected to an AP (AP3-4), AD4 is assigned to MR. Less change in the IPv6 address of the MR reduces the number of binding information exchanges with the Home Agent. For example, when there is a change ad1-ad2, the corresponding address AD3 Care-of Address is stable, no need to inform the Home Agent. During the experimentation, the dynamics of encapsulation (v6-in-v6 and v6-in-v4) was also observed. For further information and lessons learned, see [10]. Lach, et al. Expires April 2003 [Page 9] Internet Draft OverDRiVE Experiments 23 June 2003 4. Conclusions and Future Work This report described laboratory and field experiments with an IPv6 mobile network. A wide range of laboratory experiments showed the viability of NEMO-based network mobility protocols to support scenarios with simple mobile networks, nested mobile networks, and mobile HA's. At the same time, the experiments helped proving the analytical expectations (such as excessive encapsulations) and also raised new problems (such as crossover tunneling). Solving these problems involves developping new protocols for Route Optimization for mobile networks. Field experiments involved accessing two publicly-deployed wireless access systems (GPRS and WLAN) and showed the need for NAT traversal and IPv6 transition mechanisms. These mechanisms were separated from Mobile IPv6 mobility management by means of FrontBoxes. Delivering multicast traffic to hosts inside the mobile network is an important work item identified within the project. Several schemes are currently being considered (home and remote subscriptions). A DVB-T FrontBox would allow the Mobile Router to receive high-speed (broadband) Internet flows (larger bandwidths than with GPRS or WLAN). Developing a DVB-T FrontBox is one of the potential future work items. Acknowledgements This work has been performed in the framework of the IST project IST-2001-35125 OverDRiVE (Spectrum Efficient Uni- and Multicast Over Dynamic Radio Networks in Vehicular Environments), which is partly funded by the European Union. The OverDRiVE consortium consists of Motorola, DaimlerChrysler, France Telecom, Ericsson and Radiotelevisione Italiana as well as Rheinisch-Westfälische Technische Hochschule RWTH Aachen, Universität Bonn and the University of Surrey. The authors acknowledge the contributions of their colleagues in the OverDRiVE consortium. o Lach, et al. Expires April 2003 [Page 10] Internet Draft OverDRiVE Experiments 23 June 2003 References [1] S. Bradner. Key Words for Use in RFCs to Indicate Requirement Levels. RFC 2119, BCP 0014, IETF. March 1997. [2] V. Devarapalli, R. Wakikawa, A. Petrescu and P. Thubert. Nemo Basic Support Protocol (work in progress). Internet Draft, IETF. draft-ietf-nemo-basic-support-00.txt. June 2003. [3] IST OverDRiVE project on the World Wide Web: http://www.ist-overdrive.org, accessed June 23rd 2003. [4] T. Ernst and H.-Y. Lach. Network Mobility Support Terminology (work in progress). Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt. May 2003. [5] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6 (work in progress). Internet Draft, IETF. draft-ietf-mobileip-ipv6-22.txt. May 2003. [6] Wixos Wireless LAN Network on the World Wide Web: http://www.wixos.net, Accessed June 22nd 2003. [7] C. Janneteau, ed., "Scenarios, Services and Requirements", OverDRiVE Deliverable D03, September 2002. [8] M. Ronai, ed., "Concept of Mobile Router and Dynamic IVAN Management", OverDRiVE Deliverable D07, March 2003. [9] A. Petrescu, ed., "Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bi-directional Tunnel (MRHA), draft-petrescu-nemo-mrha-03.txt, (Work in Progress), October 2003. [10] A. Petrescu and H.-Y. Lach, "MR-HA Bidirectional Tunnelling for Network Mobility", Motorola Labs internal tech report, October 2003. [11] H.-Y. Lach, C. Janneteau and A. Petrescu, "Network Mobility in Beyond-3G Systems", IEEE Communications Magazine, July 2003. [12] H. Levkowetz, S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, Proposed Standard, IETF. May 2003. Lach, et al. Expires April 2003 [Page 11] Internet Draft OverDRiVE Experiments 23 June 2003 Authors' Addresses Hong-Yon Lach Christophe Janneteau Motorola Labs Motorola Labs Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 France France Phone: +33 1 69352536 Phone: +33 1 69352548 Hong-Yon.Lach@motorola.com Christophe.Janneteau@motorola.com Alexis Olivereau Alexandru Petrescu Motorola Labs Motorola Labs Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 France France Phone: +33 1 69352516 Phone: +33 1 69354827 Alexis@motorola.com Alexandru.Petrescu@motorola.com Tim Leinmueller Michael M. Wolf DaimlerChrysler AG DaimlerChrysler AG Research Telematics and E-Business Research Telematics and E-Business Communication Systems (RIC/TC) Communication Systems (RIC/TC) HPC: U800 HPC: U800 P.O. Box 2360 P.O. Box 2360 89013 Ulm / Germany 89013 Ulm / Germany Phone: +49 731 505 2379 Phone: +49 731 505 2379 Tim.Leinmueller@daimlerchrysler.comMichael.M.Wolf@daimlerchrysler.com Markus Pilz University of Bonn pilz@cs.uni-bonn.de Changes From version 00 to 01: -improved presentation. -added conclusive remarks of laboratory experiments. -enhanced the section of field experiments. -improved the conclusions section. -changed addresses and affiliations of some authors. Lach, et al. Expires April 2003 [Page 12] Internet Draft OverDRiVE Experiments 23 June 2003 Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Funding for the RFC editor function is currently provided by the Internet Society. Lach, et al. Expires April 2003 [Page 13]