(MANET) approaches in a heterogeneous environment

3 downloads 0 Views 388KB Size Report
interworking and Mobile Network Prefix (MNP) ... as a single unit, it can be called as a mobile network .... autoconfiguration, which is an IPv6 prefix used to.
Integration of Network Mobility (NEMO) and Ad Hoc Networking (MANET) approaches in a heterogeneous environment Pekka PÄÄKKÖNEN, Mika RANTONEN, Juhani LATVAKOSKI VTT Technical Research Centre of Finland, Kaitoväylä 1, 90571 Oulu, Finland {Pekka.Paakkonen, Mika.Rantonen, Juhani.Latvakoski}@vtt.fi

Abstract-- The contribution of this paper, is the integration of network mobility (NEMO) and ad hoc networking (MANET) approaches in realized heterogeneous environment. The experimented prototype system applies existing Mobility support for IPv6 (MIPv6), NEMO, Ad hoc On-demand Distance Vector (AODV) routing protocol, and IEEE 802.11b Wireless LAN (WLAN) technologies to enable end-toend connectivity of a mobile ad hoc network. The experiences from Router Advertisement mechanisms and Redirect procedures in single hop end-to-end connectivity environment are provided. The autoconfiguration, AODV address selection, and communication algorithm are prototyped in a multihop connectivity environment. The test bed implementation of the NEMO approach is described. In addition, interworking and Mobile Network Prefix (MNP) delegation mechanisms in a heterogeneous environment are discussed.

I. INTRODUCTION The integration of wireless and mobile cellular access with Internet is currently being realized in commercial markets. In these solutions, usually only the last or first hop is wireless. However, in ad hoc networks, the wireless connections are applied also between the network nodes. Thus an ad hoc network refers to the system, which consists of devices dynamically connected with each other using any wireless media. Communication between the devices, where a direct radio link does not exist, is supported over some other intermediate device(s) by means of the multihopping function. Let’s assume that a set of

devices is dynamically connected with each other using any short-range radio technology. In this case the referred cluster of devices can be called as an ad hoc network. When such an ad hoc network is moving as a single unit, it can be called as a mobile network i.e. a mobile ad hoc network. Environments for mobile ad hoc networks in commercial use could be for example cars, buses, trains and airplanes with consumers inside the vehicles (figure 1). In this research, we have focused into the end-to-end connectivity challenges of such a mobile ad hoc network from the IPv6 addressing point of view. In practice, a problem arises from the different configurations of the interacting nodes, which may or may not support Mobile IPv6 (MIPv6) and Mobile Ad hoc Network (MANET) routing protocol, i.e. have heterogeneous capabilities. MIPv6 provides mobility for IPv6-nodes in the Internet [19]. However, MIPv6 only supports mobility when the node is one hop away from an Access Router (AR). Ad hoc On-demand Distance Vector Routing protocol (AODV) is a MANET routing protocol, which enables on-demand routing in a MANET [20]. Internet connectivity can also be provided for MANET-nodes, which means that nodes multiple hops away from the AR could access the Internet [3]. There are also efforts in developing a network layer solution, which enables mobility for networks (Network Mobility (NEMO) working group of the IETF) [9]. However, any proper solution where the NEMO and MANET type of solutions are integrated in a test bed is not known to be available. In this research, the NEMO, AODV and MIPv6 protocols are applied together to enable end-to-end 57

connectivity of a mobile ad hoc network. End-to-end connectivity means that each node is able to communicate both locally and globally with each other e.g. an ad hoc network node and a Corresponding Node (CN) in the IPv6 Internet can communicate with each other independently from the configuration of each node. Home

CN

IPv6 Internet

End-to-end connectivity AP

AP

AP

Network mobility

Laptop computer

Laptop computer

MANET ad hoc connectivity

Laptop computer

Fig. 1. network.

End-to-end connectivity in a mobile ad hoc

The contribution of this research is the integration of MANET and NEMO approaches, and the experiences gained during the integration and execution of a set of use case scenarios in an experimented environment. The prototype system applies existing NEMO, AODV, MIPv6, and IEEE 802.11b Wireless LAN (WLAN) technologies to enable end-to-end connectivity of a mobile ad hoc network. The executed use cases cover the different configurations, where each node supports or doesn't support MIPv6 or AODV protocols. The experiences from Router Advertisement mechanisms and Redirect procedures in single hop end-to-end connectivity usage scenarios are provided. The autoconfiguration, AODV address selection and communication algorithm are prototyped in a multihop connectivity environment. The NEMO implementation is described as implemented in the test bed. In addition interworking and Mobile Network Prefix (MNP) delegation mechanisms are discussed. The related work is presented in chapter 2. The test bed environment is described in chapter 3. Chapters 46 describe IPv6 addressing issues related to the heterogeneous nodes. Chapter 7 discusses global communication and chapter 8 illustrates how MNP delegation could be accomplished. Chapter 9 concludes the study.

II. RELATED WORK A lot of research has been conducted relating to the merging of MANET functionality with MIP-protocols to enable global IP mobility support for ad hoc networks. [27] describes the co-operation of Mobile IPv4 (MIPv4) and Dynamic Source Routing (DSR) protocols to enable Internet connectivity for ad hoc nodes with heterogeneous interfaces, and uses a reactive MANET-protocol for the discovery of a MIPv4 foreign agent. The downside of the reactive approach is the overhead of MANET related messages as the number of nodes in the ad hoc network increases, and foreign agent discovery and mobility management difficulties. On the other hand proactive approaches avoid the downsides of reactive solutions and provide good connectivity, but increase the MIP overhead by flooding agent advertisements to the ad hoc network [4] [5]. A hybrid approach has also been suggested to find an optimal solution between the two approaches, by using TTL scoping of agent advertisements, eavesdropping and caching of agent advertisements [26]. In [6] it was noticed that when a large percentage of traffic is short and web-based, a proactive approach, which uses a gateway as a default router, results in better performance with lower latency, fewer routing table entries and manageable control overhead. When traffic locality is high, a reactive scheme results in better performance, low control overhead and higher throughput. A few papers have also considered the usage of MIPv6 with ad-hoc routing [7] [8]. [8] describes handoffs between WLANs and MANETs by using the Optimized Link State Routing (OLSR) protocol as a proactive MANET-protocol. The handoffs are facilitated with automatic WLAN mode-detection and switching capability and mobility across WLANs and MANETs is achieved by using MIPv6. [7] discusses gateway discovery, routing and addressing of a multihop ad hoc network with Internet connectivity. Different kind of routing models within a MANET have also been studied. The flat routing model doesn’t use subnet information to aid routing in the ad hoc network. When multiple MANETs overlap spatially, the route discovery packets spread across the entire network consisting of the MANETs. To prevent this, hierarchical routing could be used to separate ad hoc networks into subnets, by restricting the propagation of route discovery messages into a single MANET/subnet. In this case the routing between nodes in different MANETs is achieved by routing via 58

the Access Routers of the different MANETs. The downside of the hierarchical model is that the most optimal route to the destination in a different MANET could be achieved by using the flat routing approach, if the peers are positioned close to each other [7]. This problem could be avoided if the source uses a special flag in the RREQ, which enables the RREQ to propagate directly to the destination’s MANET [27], or with a prefix cache in the intermediate node, which collects prefixes of neighboring subnets, and uses it to forward packets between the MANETs [7]. The Network Mobility (NEMO) working group in the IETF [9] is currently working on basic support for network mobility [10] [11]. The essence of the solution is a Mobile Router (MR), which attaches the mobile network to the Internet by routing the packets between the static infrastructure and the mobile network. The approach is to use bi-directional tunneling between the MR and its Home Agent (HA) to hide the mobility of the network from the nodes behind the MR. The MR uses a Mobile Network Prefix (MNP) on its ingress interface for address autoconfiguration, which is an IPv6 prefix used to identify the mobile network in the Internet topology. The MR's HA uses the MNP to route traffic from the Internet destined to IPv6 addresses created from the MNP towards the MR's Home address or Care-of Address (COA) depending on whether or not the MR is at home or in a foreign network. The MR uses another tunnel towards the HA to route traffic from the mobile network to the Internet, when away from home. The approach requires a few modifications to the MIPv6 functionality of the MR and its HA. Other drawbacks are IPv6 encapsulation and unoptimal routing via the HA, when the mobile network is away from home. In case of nested mobile network topologies (the whole mobile network consists of multiple networks), the IPv6 encapsulation overhead and unoptimal routing via the HA is multiplied by the number of nested levels, if specific route optimization support isn't used [21] [22]. Despite these research and standardization efforts, there hasn't been research, which focuses on the merging of the NEMO approach with MANET ad hoc functionality. Especially end-to-end connectivity in such a mobile ad hoc network with heterogeneous nodes is not known to be enabled in a realized test bed.

III. TESTBED ENVIRONMENT The environment of the test bed in which the use cases were performed can be seen in figure 2. The NEMO-MANET-network may contain heterogeneous nodes. Nodes with only IPv6 functionality might be present, which don't have MIPv6 capabilities. Also MIPv6 enabled nodes might be present, either MIPv6 Corresponding Nodes (MIPv6_CN) or MIPv6 Mobile Nodes (MIPv6_MN). MIPv6_CNs have a route optimization (RO) capability, but don't support mobility of the MIPv6_MNs [19]. MIPv6_CNs are able to optimize the route to the Care of Address of the MIPv6_MN, but IPv6-nodes always have to communicate via the Home Agent (HA) of the mobile node. Also multihop connectivity might be supported with AODV. IEEE 802.11b WLAN was used as the radio access technology in the testbed. WLAN may function in either the infrastructure mode or the ad hoc mode. In the infrastructure mode a WLAN access point controls the radio access. In the ad hoc mode an access point is not needed, and peer-to-peer radio connectivity between the nodes is possible. The ad hoc mode was used in the test bed, because a fixed infrastructure i.e. access points may not always be available when ad hoc systems are used. The construction of the test bed and execution of the use cases were motivated by the different problems related to IPv6 addressing in a mobile ad hoc network. First of all the ad hoc mode of the WLAN radio access creates problems when the nodes are mobile. A node might be able to communicate via a direct radio connection with its local peer or traffic has to be routed via a router. This is a problem for a node without dynamic routing protocol capabilities, because the source doesn't know if the destination is directly reachable. Local connection establishment between MANET nodes and standard IPv6 nodes is also challenging due to the different capabilities of the nodes. Also address autoconfiguration and AODV address selection are issues, which need to be solved in order to achieve an autonomous implementation. The MNP used in the mobile network must be known by the MR and its HA for network mobility to be possible. The MNP should naturally be able to be dynamically delegated to the MR, instead of manual configuration.

59

HA_MN

CN IPv6 Internet

HA_MR Global communication

Access point MR

MNP delegation

WLAN ad hoc mode

IPv6-node

Single hop connectivity

AODVnode Multi hop connectivity

acted as the HAs of the MR and any mobile node in the test bed environment. The MIPv6 implementation developed in HUT (MIPL) was used with an AODV implementation which supported autoconfiguration and global connectivity for multihop nodes. A DHCPv6 open source implementation was used with MIPL to validate MNP delegation functionality [25].

MIPv6_MN

Interworking MIPv6-enabled AODV-node

Fig. 2. Test bed environment.

In this paper the beforementioned issues are handled with in a step-wise manner. At first end-toend connectivity related to local communication between an IPv6-node, a MIPv6_CN and a MIPv6_MN is dealt with (single-hop connectivity of figure 2). Secondly multihop communication between MANET protocol equipped nodes is focused on. Thirdly the interworking between these heterogeneous nodes is depicted. Finally the connectivity between a node of the NEMO-MANET network and a Corresponding Node (CN) of the Internet is discussed (NEMO/global connectivity). End-to-end connectivity in a NEMO-MANETnetwork consists of all the mentioned different local and global communication scenarios between the heterogeneous nodes. In practice use cases related to all these scenarios were executed to study the IPv6 addressing issues related to the end-to-end connectivity. Also dynamic MNP delegation was experimented by running the Dynamic Host Configuration Protocol (DHCPv6) over MIPv6 between the MR and its HA. In the test bed the Red Hat Linux distribution of the Linux operating system was used as a mobile platform. Each node in the NEMO-MANET network had an Orinoco WLAN network card configured to the ad hoc mode. The MR had two WLAN interfaces: one as the ingress interface towards the NEMOMANET network and the other towards its home agent as the egress interface. Two desktop computers

IV. SINGLE HOP CONNECTIVITY Single hop connectivity means that connections are established by using the neighbor discovery protocol [2]. The protocol defines a sending algorithm for IPv6 nodes, which is a based on four conceptual data structures: neighbor cache, destination cache, prefix list and default router list. The neighbor cache has entries about neighbors to which traffic has recently been sent. The entries include the link-layer address of the destination (IP address -> link-layer address). The prefix list contains IPv6 prefixes, which are considered as ON-link. It is updated based on Router Advertisement (RA) messages sent by routers. The default router list contains a list of routers to which traffic may be sent, and is also updated based on the information from received RAs. The conceptual algorithm based on these data structures may be implemented by using a variety of techniques for example by using a routing table. Figure 3 describes single hop connectivity related to nodes without MANET-protocol support. Because WLAN was used in the ad hoc mode, nodes are capable of peer-to-peer radio connections. However, because the nodes are mobile, direct radio connectivity may not be possible and routing via the MR is needed. In this networking environment, the sending of RA and Redirect ICMP messages by the MR has an effect on the sending algorithm functionality of the nodes i.e the end-to-end connectivity. A. Advertisement issues The MR may use either stateful or stateless methods for address autoconfiguration. In this paper stateless address autoconfiguration has been focused on [23] [30]. In that case the MR has to advertise itself as a default router by sending Router Advertisement (RA) ICMP messages to the connected nodes. To enable default routing, the Router Lifetime field of the RA has to be non-zero [2]. When the nodes receive a RA with a non-zero Router Lifetime field, an entry is added to the default router list [2]. On Linux platform 60

in practice a Routing Table (RT) entry is created for the MR's link-local address (::/0 -> MR's link-local address). If the Router Lifetime would be zero, default routing would be disabled for the nodes, and outside communication with a CN of the Internet would not be possible. RA Router Lifetime > 0 { MNP L-flag = 1|0 } OFF-link model MR Routing table: MNP -> eth0 Routing table: Node2

ON-link model

Node1

::/0 -> MR's link-local address MR's link-local address -> eth0 MNP -> eth0 Neighbor cache:

Redirect Node2's IP address { Target link-layer address- option}

Node2 -> link-layer address of node2

Fig. 3. Single hop connectivity.

The MNP may be advertised as ON-link by setting the L-flag in the Prefix Information -option [2] of the RA. When a node considers the MNP to be ON-link an entry in created to the prefix list [2]. On Linux platform a RT entry is created for the MNP towards the interface of the MR (MNP -> ethx). This RT entry causes the nodes to send packets to the network interface for destinations, which have configured an IPv6 address from the MNP (local destinations). If the L-flag is not set, it "conveys no information concerning on-link determination and MUST NOT be interpreted to mean that addresses covered by the prefix are off-link" [2]. This causes the nodes to use the default router for all destinations. For clarity in this paper the ON-link model is used, when the L-flag is set, and the OFF-link model is used, when the Lflag is not set. When the MR advertises the MNP with the ON-link model, it causes the communicating nodes to send packets directly to each other (to the interface). If the nodes are not within the WLAN communication range of each other because of mobility, communication between the nodes isn't possible. When the MR advertises the MNP as OFF-link, it causes the peers to always communicate via the MR. B. Redirect ICMP-message When a source sends packets via a MR to a local CN in the OFF-link model, the MR discovers that the destination is in fact on the same link as the source,

and sends a Redirect ICMP message to the source. The Redirect-message contains the link-layer address of the destination in the target link-layer address option. It causes the source to send packets directly to the destination (to the interface) instead of routing via the MR, because the source updates the link-layer address of the destination’s IP address in the neighbor cache [2]. If the peers are not within the WLAN communication range of each other and MR routes the packets between the peers, communication ceases between the peers. The Redirect ICMP-messages have an effect on the node when they are received from the next-hop to the destination. This means that Redirectmessages don't affect link-local communication, because link-local packets are never sent via a default router. C. Experiences When the ad hoc mode of WLAN is used, the MNP should be advertised with the OFF-link addressing model, because end-to-end connectivity is enabled via the MR even when the peers are not within a direct radio communication range. Routing via the MR is also the downside of the OFF-link model, because of unoptimal routing, when the peers are in the WLAN communication range of each other. The routing also creates additional load on the MR, which becomes a significant factor, when the number of nodes and local connections increases. The ON-link model affects MIPv6 communication. MIP Care-of Addresses (COA) can’t be used for communication, when the peers aren't in each other’s communication range as mentioned earlier in chapter 4.1. If in the same situation home addresses would be used for communication as source addresses, the MIPv6 Reverse Routability (RR) -test [19] wouldn't succeed, because the Care-of Test Init, Care-of Test and Binding Update messages would need to be sent to the interface based on the RT entry of the ON-link model. This would disable the use of MIPv6 Route Optimization (RO) between the peers [19]. Because the sending of Redirect-ICMP messages disables communication in the OFF-link addressing model when the peers are not within the communication range of each other, the sending of Redirect-messages should be disabled in the MR when the ad hoc mode of WLAN is used.

61

V. MULTI HOP CONNECTIVITY Multihop connectivity means that a node uses the route discovery procedure of the MANET-protocol in order to find a route to the destination. This procedure is executed before any packets are sent to the destination. Because of the MANET capabilities, the IP address autoconfiguration, address selection and communication algorithm are different for a multihop node compared to a standard IPv6 node. A. Autoconfiguration Performing the Duplicate Address Detection (DAD) and global connectivity procedures achieve the IP address autoconfiguration for a MANET-node. 1) Duplicate Address Detection

The main purpose of the DAD procedure is to guarantee the uniqueness of the IPv6 address to be used in the MANET. The uniqueness test messages (Address Request (AREQ), Address Reply (AREP)) have to disseminate over the MANET, because of the lack of servers [12]. Therefore some improvements have been implemented for minimizing the dissemination of the DAD messages compared to the proposed DAD procedure for MANETs [12]. A detailed description of the procedure and packet formats can be found in [13]. The DAD procedure consists of the generation of an interface-ID, uniqueness test of the interface-ID, assignment of the address and releasing of the assigned address. The procedure starts when a node creates an AREQ message [13], which contains the requested address. The requested address is created by concatenating the MANET_PREFIX [12][13] with the generated interface-ID. The interface-ID and an AREQ identification number are generated by using a wellinitialized random number generator. If the requested address, in fact some other node has reserved the interface-ID, the source of the AREQ will receive an AREP [13]. In that case, the DAD procedure has to be initiated again i.e. a new address and AREQ identification number have to be generated. The AREQ message is sent three times to ensure that the message dissemination will reach all nodes in the MANET. When the AREQ message is received by the MANET-nodes, the requested address is added to the routing table with a temporary flag or if the requested address is found from the routing table, an AREP is sent. As mentioned above, the IPv6 address comparison is done only for the interface-ID part of the MANET-

address, which enables minimization of the DADprocedure, and guaranties that the interface-ID is unique in the MANET. The DAD procedure has to be performed only during the initial address assignment. When the AODV-node creates a global address by using the global connectivity procedure as defined in chapter 5.1.2., DAD doesn't have to be performed again. 2) Global connectivity

After the DAD the AODV-node has a site-local MANET-address. To enable global connectivity for an AODV-node, the AODV-node must have a globally unique address and maintain connectivity to the Internet. This functionality is enabled with MNP discovery and route refresh sequences. MNP discovery is used to create a globally unique address for the AODV-node, and the route refresh procedure maintains reachability of the AODV-node from the MR i.e. from the Internet. The MNP discovery sequence begins when the AODV-node sends a RREQ with the I-flag set to the ALL_MANET_GW_MCAST-multicast address from its configured site-local MANET-address [3] (step1 in figure 4; AODV-node->Int-node->MR). The MR returns the MNP by sending a RREP with the I-flag set to the AODV-node's MANET-address (step2; MR>Int-node->AODV-node). When the AODV-node and intermediate nodes receive this RREP, a RT entry for the default router and MR towards the next-hop towards the MR is created (step3). The MR's address is a global address configured on the ingress interface of the MR. After this the AODV-node attaches the MNP to the interface-ID configured during MANETrelated DAD to create a unique global IPv6 address. This enables global connectivity for the AODV-node. In the route refresh sequence the AODV-node sends a RREQ with the I-flag set to the default router's address from its configured global IPv6 address (step4). When the MR and intermediate nodes receive the RREQ, they create an entry for the AODV-node's global address towards the next-hop towards the AODV-node (step5; AODV-node->Int-node->MR). This enables AODV-node's reachability from the Internet. Finally the MR sends a RREP in response to the RREQ with the I-flag set (step6; MR->Int-node>AODV-node).

62

MR Global-prefix:interface-ID

1.RREQ (I-flag)

RT: Int.node ->eth0 5.AODV-node -> Int.node

2. RREP (I-flag) 4.RREQ (I-flag) 6. RREP (I-flag) Int.node 1.RREQ (I-flag)

3. AODV-node ->eth0 5. MR -> eth0 3. ::/0 -> MR

2. RREP (I-flag) 4. RREQ (I-flag) 6. RREP (I-flag)

MANET-Prefix:interface-ID Global-prefix:interface-ID

3. MR ->Int.node 3. ::/0 -> Int.node Int.node -> eth0

Fig. 4. Global connectivity procedure.

In [3] it has been proposed to implement default routing via the global address of the MR. In that kind of configuration the furthermost AODV-node of figure 4 would require three RT entries (::/0 -> MR ; MR -> next-hop towards MR ; next-hop -> ethx) for default routing. This isn't implementable on the Linux platform, because the next-hop router must have a RT entry towards the interface as described in figure 4, i.e. recursive RT lookups are prevented. This is the reason default routing had to be provided via a nexthop. The AODV-node has to execute the route refresh sequence in certain time periods in order to maintain reachability from the MR [3]. If the route cannot be refreshed i.e. the AODV-node loses reachability to the MR, the AODV-node has to return to using the sitelocal MANET-address, because the MR might not be present anymore to provide default routing. B. AODV address selection If the AODV-node has MIPv6 capabilities, it may choose whether or not to use the configured address as a home address or a COA. This could be done by comparing the received MNP to the home network prefix similarly as the IPv6 prefixes advertised with RAs are used for movement detection in standard MIPv6 nodes. However a solution for AODV and MIPv6 merging still remains to be standardized. The AODV-node may use either a site-local address or COA/home address configured via MNP discovery as a MANET-address. If the site-local address is used as a MANET-address, Internet communication is not possible, because packets with a site-local source address cannot be routed to the Internet. This means also that it is not possible to communicate with local AODV-nodes, which are away from home and use

their home address as the source address for local communication. In practice the site-local addresses could be used in multiple sites, but the address itself doesn't contain an indication about a particular site. This kind of ambiguousness presents problems to the application developers and multi-sited routers. This has led the IETF to deprecating the site-local address [15], and search for alternative solutions [16]. This discourages further the use of site-local addresses instead of global addresses. It remains to be seen how the alternative addressing solution could be used with AODV [16]. C. AODV communication algorithm The communication algorithm of the test bed used hierarchical addressing for COAs and flat routing for site-local addresses: 1. If destination is a site-local MANET-address or the destination's IPv6-prefix is equal with the MNP => execute route discovery 2. Otherwise send packets via the default router The flat routing approach has to be used for the site-local addresses, because site-local addresses don't contain any information about a specific subnet. The need for route discovery to COAs prior to communication was based on the MNP. In this case the packets between multiple MANETs using COAs would flow via the MRs of the different MANETs. The implementation of the algorithm required communication of the user space AODV-protocol and Linux kernel. In [3] it has been defined that the AODV-node may use route discovery always when sending packets whether or not the destination is in the Internet or not. If in this case the CN is in the Internet and no answer to the RREQ is received, the CN is deduced to be outside the MANET, and the default router is used. The algorithm presented in this paper uses the default router immediately, when packets are sent to local nodes or CNs in the Internet. This means that the initial route discovery phase is not needed, which results in faster initial communication initiation with the peer compared to the solution presented in [3]. There is also no need to add destination entries to the routing table via the default router, (destination -> default-router) which are needed, if route discovery is used always when initiating communication with a random node at the first time. The downside of the 63

algorithm used in the test bed is that it doesn't support multiple MANETs and doesn't adapt to the changes in the network.

IPv6-node

VI. INTERWORKING BETWEEN HETEROGENEOUS MR

NODES

The different capabilities of the multihop and singlehop nodes bring challenges to the address autoconfiguration and end-to-end connectivity in the NEMO-MANET network. Figure 5 describes the configuration of the test-bed to enable such interworking between MANET-nodes and standard IPv6-nodes. Standard single hop related DAD guarantees that the interface-ID of the IPv6-address is unique on a link [23]. The nodes discover the MNP via the RAs sent by the MR, which is attached to the interface-ID to configure a unique IPv6 address. Also a link-local address is created by attaching a well-known linklocal prefix (fe80::/64) to the interface-ID [23][24]. The MANET-address related DAD guarantees that the interface-ID is unique in the MANET. The MNP is received via MNP discovery, which is attached to the MANET related interface-ID to create a unique IPv6 address. It is possible that equal interface-IDs are configured in a multi-hop NEMO-MANET-network with heterogeneous nodes, because the scope of the DADprocedures related to the interface-IDs overlap. To guarantee unique global IPv6 addresses, the MNPs advertised in the different autoconfiguration procedures have to be different. The single hop capable nodes send packets for the multihop capable nodes via their configured default router (::/0 -> MR's link-local address). The MANETnodes also use the default router for communication with the single hop node (::/0 -> next hop towards MR), because the single hop nodes are not capable of answering to route discovery messages. Global addresses have to be used always when a default router is used, in case the CN would be in the Internet instead of being a local node.

RT: ::/0 -> MR's link-local address MR's link-local address -> eth0

MNP -> eth0 RT: AODV-node2 -> AODV1 AODV1 -> eth0

AODVnode1 RT:

AODVnode2

::/0 -> MR MR -> eth0 AODV2 ->eth0

RT: ::/0 -> AODV1 AODV1 -> eth0

Fig. 5. Interworking between heterogeneous nodes.

VII. NETWORK MOBILITY Network mobility requires bi-directional tunneling between the MR and its HA, when the mobile network is away from home. Figure 6 describes how NEMO tunneling was implemented in the test bed. The HA of the MR had a routing table entry for the MNPs used in the mobile network towards the home address of the MR (MNPx -> MR). When the MR is away from home, a binding cache entry of MIPv6 directs the traffic to the COA of the MR i.e. an IPv6 tunnel is used. The used IPv6 implementation of Linux didn't support routing via the link-local address of a router. Because of this, a default RT entry towards the current router's global address had to be applied in the MR. When the MR was at home, the RT pointed towards the current router's global address (::/0 -> router). When the MR was away from home, a RT entry for the destination IPv6 prefix towards the home tunnel directed traffic from the mobile network towards the HA tunnel (destination-prefix-> ip6tnl1). The default prefix (::/0) couldn't be used, because the destination was an interface (ip6tnl1). The MR provided default routing for the connected single hop nodes via its linklocal address configured on the ingress interface. A global address was used for the connected MANETnodes. The traffic, which the MR originated, was sent as defined in MIPv6 specification [19] and as implemented in [14], and is not described here. The bi-directional tunneling created overhead to the Internet communication of the connected nodes. If either the CN of the Internet or the node in the mobile network is away from home and supports MIPv6 route optimization, the route will be optimized between the nodes. If however either node is an IPv6-node, routing and tunneling via the MIPv6_MN's HA is required. 64

This causes overlapping tunnels between the MR and MR's HA, if the mobile network is away from home. It should be noticed that this occurs even if the mobile network has only a one level topology as in the constructed test bed.

Fig. 6. Network mobility implementation.

VIII. MNP DELEGATION The MR has to somehow obtain the MNPs for address autoconfiguration in a NEMO-MANETnetwork. The MNPs have to be either statically configured to the MR or dynamically delegated from a server in the Internet. MR's HA also has to know the MNPs the MR advertises in order to enable routing for the mobile network. This information can be provided to the HA from the MR with either the implicit, explicit network modes defined in the Basic NEMOprotocol [10]. In the implicit mode the MR doesn't include any information about the MNPs in the Binding Update (BU), and the HA can use any unspecified method of determining the MNPs used in the mobile network, for example via manual configuration. In the explicit network mode the MR includes information about one or more MNPs used in the mobile network to the BU by using a new Mobile Network Prefix -option in the BU. Even though the MNP can be indicated dynamically to the HA, the dynamic MNP delegation for the MR is an open issue to be solved. One possible solution for the MNP delegation could be the use of IPv6 Prefix Options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [17][18][31]. With these extensions it is possible to delegate a MNP by using an existing solution

(DHCPv6). Still some configuration is required to enable the use of DHCP over MIPv6, when the MR is at home or in a foreign network. When the MR is at home it can use link-local addressing to communicate with a DHCPv6 server in its home network. The MR sends DHCP packets to the DHCP server's All_DHCP_Relay_Agents_and_ Servers-multicast address and the DHCP server sends packets to the MR's link-local address [18]. When the MR is away from home, it can similarly use link-local addressing with the DHCP server in the foreign network. If the MR wishes to delegate MNPs from the DHCP server in its home network, it has to use the bidirectional tunnel to exchange the DHCP messages so that the link-local addresses are used as before, but inside the encapsulating headers of the bi-directional tunnel (see figure 7). To enable this the MR must have a RT entry for the All_DHCP_Relay_Agents_and_Servers-multicast address to point to the tunnel interface, and the DHCPv6 server i.e. HA must have a RT entry for MR's link-local address towards the tunnel interface. Also both the MR and the HA must have a link-local address configured on the tunnel interface for the tunneling to be possible. The addresses from the normal interface (eth0) may be used for this purpose, because an IPv6 address only has to be unique on a link. According to the MIPv6 specification [19] it is not allowed for the HA to route packets to the linklocal address of a MN, which means that the DHCPv6 server or relay agent must be co-located with the HA. In this way the HA/DHCPv6 server originates DHCPv6 packets to the link-local address of MR, but doesn't route them. The described methods for MNP delegation for the MR and MNP indication to the HA from the MR contain overlapping functionalities. For example if the MNP will be initially delegated from the HA to the MR, there is no point in informing the MNP to the HA as described in [10] after the delegation. However, these mechanisms can co-exist, and MNP delegation should be used, when the MNP isn't manually configured in the MR.

65

It seems that the Quality of Service of the MANETrouting algorithm, security and roaming are issues for future research.

Internet

Accessrouter inforeignnetwork eth0 Homeaddress COA link-local addressof MR ip6tnl1 link-local addressof MR

Routingtable: All_DHCP_Relay_Agents_and_Servers-> ip6tnl1

Bi-directional tunnel

MR/ DHCPclient

MR->HA

eth0 HAaddress link-local addressof HA

ip6tnl1 link-local addressof HA Routingtable: link-local addressof MR-> ip6tnl1

IPheaders IPsource: COA

IPdestination:

HAaddress

HAaddress

IPsource:

IPdestination:

IPdestination:

COA

[1] [2] [3]

[4]

link-local address of MR All_DHCP_Relay_Agents_and_Servers

HA->MR

IPheaders IPsource:

REFERENCES

HA/DHCPv6server

[5] IPsource:

IPdestination:

link-local addressof HA link-local address of MR

Fig. 7. DHCPv6 over MIPv6. [6]

IX. CONCLUDING REMARKS The integration of MANET and NEMO approaches enabled the end-to-end connectivity of a mobile ad hoc network. The executed use cases cover several different configurations, and it is pointed out that the complexity of addressing drastically increases when heterogeneous nodes are added into the system. When going into details, the experiences indicate that, the ad hoc mode of WLAN and mobility of the nodes require the MR to advertise the IPv6 prefix for address autoconfiguration with the OFF-link addressing model to enable single hop communication. Also in order for the MR not to prevent routing, the MR should not send ICMP Redirect-messages on the ingress interface. The IP address autoconfiguration, AODV address selection and communication algorithm of a MANET-node was presented as implemented in the test bed. The interworking between the heterogeneous nodes is achieved by routing via a default router. To enable unique global addressing, the MR must not advertise equal IPv6 prefixes in the autoconfiguration procedures of the heterogeneous nodes. Network mobility was enabled with the NEMO approach of the IETF and its implementation is described as implemented in the test bed. The bi-directional tunneling of the NEMO approach creates additional overhead when the corresponding node resides in the Internet. Dynamic MNP delegation for mobile networks could be implemented by using DHCPv6 prefix delegation extensions over MIPv6 as described in the paper.

[7]

[8]

[9] [10]

[11]

[12]

[13]

[14] [15]

[16]

[17] [18] [19]

[20]

66

Mobile Ad-hoc Networks working group IETF, URL: http://www.ietf.org/html.charters/manet-charter.html. T. Narten, E. Nordmark, W. Simpson "Neighbor Discovery for IP Version 6 (IPv6)" IETF, RFC 2461. R. Wakikawa et el. "Global connectivity for IPv6 Mobile Ad Hoc Networks", IETF draft, work in progress, November 2002. Y. Sun, E. M. Belding-Royer, C.E. Perkins "Internet Connectivity for Ad-Hoc Mobile Networks" International Journal of Wireless Information Networks special issue of Mobile Ad hoc Networks, pages 75-88, April 2002. U. Jönsson, F. Alriksson, T. Larsson, P. Johansson, G.Q. Maquire Jr. "MIPMANET- Mobile IP for Mobile Ad Hoc Networks" In proceedings of the 1st Workshop on Mobile Ad hoc Network and Computing (MobiHoc '00), pages 75-85, Boston, Massachusetts, August 2000. Y. Sun, E.M. Belding-Royer "Application-Oriented Routing in Hybrid Wireless Networks" In proceedings of the International Conference on Communications, Anchorage, Alaska, May 2003. J. Xi, C. Bettstetter "Wireless Multihop Internet Access: Gateway Discovery, Routing, and Addressing" In Proceedings of International. Conference on Third Generation Wireless and Beyond (3Gwireless), San Francisco, CA, USA, May 28-31, 2002. L. Lamont, M. Wang, L. Villasenor "Integrating WLANs & MANETs to the IPv6 based Internet" In proceedings of the International Conference on Communications, Anchorage, Alaska, May 2003. Network Mobility working group, IETF, URL: http://www.ietf.org/html.charters/nemo-charter.html. V. Devarapalli et al. "Nemo Basic Support Protocol" , IETF draft, work in progress, December 2003. H. Lach C. Janneteau, A. Petrescu "Network Mobility Support in Beyond-3G Systems" IEEE Communcations Magazine, pages 52-57, July 2003. C. E. Perkins, J. T. Malinen, R. Wakikawa, and E. M. Belding-Royer. "IP Address Autoconfiguration for Ad Hoc Networks" , IETF draft, work in progress, November 2001. M. Rantonen, J. Keisala "IP Address Autoconfiguration with DAD minimization for Ad Hoc Networks" , IETF draft, work in progress, August 2003. MIPL Hut home page, URL: "http://www.mipl.mediapoli.com/". C. Huitema, B. Carpenter "Depracating Site Local Addresses" , IETF, work in progress, March 2004. R. Hinden, B. Haberman "Unique Local IPv6 Unicast Addresses", , IETF draft, work in progress, February 2004. O. Troan , R. Droms "IPv6 Prefix Options for DHCPv6", IETF RFC 3633. R. Droms et al. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" IETF, RFC 3315. D.B. Johnson, C. Perkins, J. Arkko "Mobility Support in IPv6" , IETF draft, work in progress, June 2003. C. Perkins, E. M. Belding-Royer, S. Das "Ad hoc On-Demand Distance Vector (AODV) Routing" IETF, RFC 3561.

[21] P. Thubert, M. Molteni "IPv6 Reverse Routing Header and its application to Mobile Networks", , IETF draft, work in progress, Feb 2004. [22] K. Lee et al. "Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation", , IETF draft, work in progress, Feb 2004. [23] S. Thomson, T. Narten "IPv6 Stateless Address Autoconfiguration", IETF, RFC 2462, December 1998. [24] R. Hinden, S. Deering "IP Version 6 Addressing Architecture" , IETF draft, work in progress, October 2003. [25] DHCPv6 open source implementation home page, URL: "http://dhcpv6.sourceforge.net/". [26] P. Ratanchandani, R. Kravets “A Hybrid Approach to Internet Connectivity for Mobile Ad Hoc Networks” In proceedings of Wireless Communications and Networking conference, (WCNC

2003), Volume 3, New Orleans, Lousiana, USA, March 2003. [27] J. Broch, D.A. Maltz, D.B. Johnson “Supporting Hierarchy and Heterogeneous Interfaces in Multi-Hop Wireless Ad Hoc Networks” In proceedings of the Workshop on Mobile Computing held in conjunction with the ISPAN, Perth, Australia, June 1999. [28] P. Nikander, J. Kempf, E. Nordmark “IPv6 Neighbor Discovery trust models and threats” , IETF draft, work in progress, October 2003. [29] J. Arkko et al. “SEcure Neighbor Discovery (SEND)” , IETF draft, work in progress, October 2003. [30] T. Narten "Neighbor Discovery and Stateless Autoconfiguration in IPv6" IEEE Internet Computing Magazine, pages 54-62, August 1999. [31] C.E. Perkins, J. Bound "DHCP for IPv6" In Proceedings of the Third IEEE Symposium on Computers and Communications, pages 493497, Athens, Greece, June 1998

67