All our experiments were carried out using a modified version of Olsr.org’s OLSR daemon version 0.4.10 [169], which we simply call olsrd. Olsrd imple- ments OLSRv1 [37] plus some extra options such as a link quality extension based on ETX using hello packets. To use the LQA values from ppand, we enabled this link quality extension, but replaced it with our own function- ality that retrieves the LQA values from the ppand. For simplicity, olsrd still sent and handled its own hello messages (link quality-enabled hello mes- sages) as usual. However, the reception (or the non-reception) of the hello messages was only used to determine the neighbor set, but not the link qual- ity. A neighbor was excluded after ten consecutive hello messages were lost. The link quality information came from ppand via the IPC mechanism as explained earlier.
The ppand sent LQA updates for each of its neighboring Personal Nodes to the routing daemon with a frequency of 10 times per second. For obvious reasons, that was not the frequency used by olsrd to further disseminate the quality information. Instead, olsrd sent link quality updates, through OLSR’s topology control messages, once every second for each link and each direction that the OLSR protocol decided to include in the partial link state set. This is a high frequency for OLSR (the standard proposes once per 5 seconds [40]), but was used in our small test bed for testing purposes. Future implementations should use a lower frequency and send additional updates whenever a significant quality change occurs.
Modifications to the link quality message formats were not required, since olsrd already provides message modifications for carrying link quality infor- mation. In olsrd, this information was included in the hello messages and
6.7. SUMMARY 141
the topology control messages using two 8 bits fields, which was enough also for our purposes. The only thing we modified, in addition to the retrieval of the LQA values from ppand, was the extra logging facilities. This was done for debugging and measurement purposes.
6.6.4
Lessons learned
The modifications to the Madwifi driver and olsrd were kept to a minimum and measured only 240 lines of code (LoC) and 190 LoC each. The ppand, where most of the LQA logic was located, measured 1650 LoC. However, that number includes all tested LQA variants in this chapter and repetitions of the same code from the wired LLAL implementation.
The CPU load of our test bed laptops remained at a moderate 10 % during all experiments. Most of the computation concerned the extended logging facilities and the generation and measurement of test traffic.
The LQA functionality was straightforward to implement as soon as we had determined which method to use. Finding the parts to modify and implement the required modifications of both the Madwifi driver and olsrd was relatively easy. The main difficulty was the amount of time required to get used to the code that needed to be modified.
The measurements themselves took a significant amount of effort. We had to try out different approaches and configurations in order to first find out what works and what does not. Then, proper scenarios that could exercise certain issues or trigger certain situations needed to be defined. Also this step could require several attempts. Finally, the actual experiment and the data collection could be carried out, before being compiled and presented.
One of our main challenges in the experiments was to assure that mo- bility experiments were exactly repeated and that fair comparisons could be done between two different experiments. It was not always possible to test two configurations in the same experiment. Instead, two different experi- ment trials were often required and each trial is unique. We tried our best to repeat the exact movements and speed and always averaged over 10 rep- etitions. However, this was done for only one mobile station. With multiple simultaneous mobile nodes, this problem will become more complex.
6.7
Summary
In this chapter, we took a close look at unicast routing within Clusters. There are plenty of unicast routing protocols for networks, such as Clusters, but they only provide a part of the solution. To make sure that the best possible path is selected, the routing protocol needs the best possible information of the quality of the potential links. This problem, we refer to as link quality assessment (LQA) and that was the focus of this chapter.
We investigated several approaches to LQA using available cross-layer information. Collected information came from the hello protocol as well as the data traffic and included data such as delivery ratio and received signal strength. We investigated approaches to combine these information sources in the best possible way to predict the data packet delivery ratio on a link. A few approaches were tested within our PN prototype in a three Nodes test bed. By using more cross-layer information, we could show that better paths were selected.
Further, we discussed general approaches to areas, such as asymmetric link qualities, heterogeneous networks, comparison between links with and without data traffic, and the effect of packet size. The quality of TCP streams over Cluster paths was also discussed.
Finally, we introduced how the prototype was extended with these LQA methods. We used the Madwifi driver, which is an open source driver for Atheros wireless chip-based cards, such as our 3Com OfficeConnect Wireless 108Mbps 11g XJACK PCCards. From the Madwifi driver, we could extract information that is not normally available to the operating system, such as feedback from the data packet retransmissions and acknowledgments. Then, ppand was extended to make use of this and other cross-layer information and perform the LQA calculations. The LQA results were then fed to the OLSR routing daemon, which used them for finding the best routes.
Chapter 7
PN Organization
It is now time to move away from Clusters and personal local communication and look at the personal global communication picture. How can we connect remote Clusters to each other and how do we use the existing communication infrastructure to do that? We call this inter-Cluster communication and that is the topic of this chapter.
As we have explained earlier, a PN typically has multiple Clusters that are geographically dispersed. To form a PN and realize communication between the Clusters, three requirements need to be fulfilled [96]:
1. The Clusters need to have access to a fixed Interconnecting Structure through one or multiple Gateway Nodes.
2. Once access to the Interconnecting Structure is available, the Clusters need to be capable of locating each other in order to establish tunnels between them and thereby form a complete PN.
3. Finally, the Clusters must be able to maintain the tunnels regardless of Cluster or Node mobility.
The discovery and selection of Gateway Nodes that can provide access to the fixed infrastructure, is a Cluster internal issue and is best fulfilled through a Cluster-internal mechanism. For the second requirement to be fulfilled, we introduce the concept of a PN Agent. Clusters that have obtained access to the Interconnecting Structure announce their presence to the PN Agent as shown in Figure 7.1(a). The announcements contain information such as security credentials, current care-of addresses (CoAs) for the Gateway Nodes, and perhaps also the list of Nodes in the Cluster. The PN Agent can communicate this information to other Clusters and their Gateway Nodes, which may trigger the creation of secure tunnels between the Clusters as shown in Figure 7.1(b).
The purpose of the tunnels is twofold. First, they provide secure inter- Cluster communication by shielding the intra-PN communication from the
(a) Gateway Nodes inform the PN Agent
(b) Inter-Cluster tunnels are established
Figure 7.1: Example of PN establishment
outside world. Second, these tunnels are dynamically updated in order to handle the mobility of Clusters.
To handle the mobility, information regarding the availability of Gateway Nodes is propagated and the Gateway Nodes will react by dynamically up- dating the tunnels. When a Gateway Node changes its attachment point to an Interconnecting Structure, existing tunnels are destroyed and new ones are created. In cooperation with PN-wide routing and addressing, this re- sults in a self-organized PN that consists of several Clusters interconnected by dynamic tunnels. This provides security and hides the Cluster mobility and Gateway Node changes from the Nodes in the PN.
This chapter is organized as follows. Section 7.1 introduces important requirements for inter-Cluster communication. Section 7.2 discusses related work. In Section 7.3, we cover PN-wide addressing. Section 7.4 discusses the aspects of infrastructure support. Section 7.5 covers the main functionalities of inter-Cluster tunneling, including mobility handling, tunneling strategies, Gateway Node coordination, and security. In Section 7.6, we continue with the PN routing aspects, including PN-wide broadcasting and QoS. Finally, in Section 7.7, we describe the implementation of the inter-Cluster commu-
7.1. INTER-CLUSTER TUNNELING REQUIREMENTS 145
nication extension to our prototype, before we summarize in Section 7.8.
7.1
Inter-Cluster Tunneling Requirements
For a successful implementation of inter-Cluster communication, it is crucial that the following requirements are met:
1. As much of the communication setup as possible must be automatic. It is unacceptable to require the user to manually bring connections up and down. This must be done automatically and intelligently by the system. However, some user control should be possible, such as permitting the use of access networks that are charged. The user may specify rules by which decisions are automatically made by the system. 2. The inter-Cluster communication must support mobility. This includes horizontal and vertical handovers between access networks as well as handovers between Gateway Nodes, whenever better access networks arise or used ones disappear.
3. As many existing access networks and Interconnecting Structures as possible must be supported. Emerging and future technologies, as long as they can be anticipated, should be supported. This means that current deployment setups must be supported, such as hotspots and digital subscriber lines (DSL) using IPv4, Dynamic Host Configuration Protocol (DHCP) [54], and network address translators (NATs). How- ever, as future deployments evolve (e.g., using IPv6), they must also be supported. Hence, a great deal of flexibility is required.
4. It must not be necessary to change or add functionality to the current Interconnecting Structures. The deployment of PNs must not depend on certain technologies first being deployed in the infrastructure. This is not to say that additional functionalities that can improve the oper- ation of PNs are not wanted, just that such functionalities must not be required.
5. The user’s privacy must be retained, since a PN will carry user-related data. Communication going over various access networks and Intercon- necting Structures must be properly protected offering both confiden- tiality and data integrity.
6. It is also important that inter-Cluster communication can achieve a high QoS whenever required. This implies that the PN must be able to choose the best Gateway Node, access network type, and access point for the communication. The quality of every option should, to some reasonable degree, be monitored or predicted so that a good selection
can be made. The selection may also be based on the needs of the applications active at every moment.
7. The inter-Cluster communication mechanisms should not waste energy and other resources. Unnecessary communication paths that consume energy or resources should be disconnected when not needed. This requirement may be in contradiction with the previous requirement on QoS, so a proper trade-off must be made.
7.2
Related Work
In this section, we list work related to inter-Cluster tunneling, including topics such as network mobility, secure tunneling, NAT-traversal, and packet relaying.
The most important mobility solutions for IP networks are IP Mobility Support for IPv4 (Mobile IPv4) [178] and IP Mobility Support for IPv6 (Mobile IPv6) [103]. They both require every mobile host to have a so- called home agent (HA) on their home network. Any host that wants to communicate with the mobile host sends packets to the home address, which is the address of the mobile host when it is on the home network. The HA intercepts those messages and forwards them in a tunnel to the mobile host, either directly or via a foreign agent (FA). The mobile host updates the HA when it’s care-of address (CoA) changes, by sending a message with the new address. However, packets sent by the mobile host in the other direction are sent directly and not via the HA. This results in triangular routing, involving the corresponding host, the HA and the mobile host. However, in Mobile IPv6, it is also possible to send the CoA to the corresponding host so that all traffic can flow directly between the two hosts, thus avoiding triangular routing.
Mobile IP concerns mobility of single hosts, such as laptops. Hence, each node has its own mobility mechanism. If applied on a Cluster, which is a network of mobile hosts, each node must have its own mobility mechanism. When a Cluster roams together, all nodes need to update their HAs concur- rently when the network changes point of attachment. For this reason, the Network Mobility (NEMO) Basic Support Protocol [49] was introduced. In NEMO, each mobile network has a mobile router (MR). The MR is connected to the infrastructure and has a home agent just as in Mobile IPv6 (NEMO is only specified for IPv6). Instead of a home address coupled to the home location, the MR has a home network prefix coupled to the home network. All the nodes in the mobile network get addresses with that network prefix from the MR via link local IPv6 router advertisements [158]. The nodes in the mobile network do not need to be aware of their mobility when the net- work roams, only the MR needs to take actions. In NEMO basic support,
7.2. RELATED WORK 147
all traffic to and from the mobile network is tunneled via the home agent. However, route optimization has been proposed [161].
NEMO has several limitations and drawbacks. First, the mobile network needs to be a single-hop network since it relies on link local router advertise- ments. Hence, NEMO cannot support multi-hop Clusters without additional functionality. One option would be to use Ananas [33], which makes a multi- hop network behave like a normal single-hop LAN for the IP layer by intro- ducing an intermediate layer. As described in Section 4.2, Ananas is not ideal and hence a better solution is to replace the network prefix advertisements with a solution that works over a multi-hop network. Another problem, not fully solved in neither NEMO nor Mobile IPv6, is multi-homing. Currently, IETF is studying solutions for this problem [149] [160], including soft han- dovers between two access networks as well as multi-homing for increased reliability and load sharing. In NEMO, there is the additional problem of multiple MRs in a single mobile network. If the two MRs have different net- work prefixes, then it becomes difficult for mobile nodes to switch from one MR to the other. Hence, when using NEMO for PNs, all the MRs belonging to the PN need to have the same prefix. Unfortunately, this is difficult to achieve as the HA would not know which MR to forward a packet to when the MRs are no longer in the same mobile network (Cluster). Because of these limitations in NEMO, we do not propose to use NEMO for inter-Cluster communication.
The work in IETF on mobile nodes and networks is currently quite in- tense. An important area being in focus is that of detecting network access (DNA) [36] [157]. Whenever a mobile node discovers access to a new net- work on one of its interfaces, it needs to detect the IP configuration of that network as well. Unfortunately, the IPv6 neighbor discovery protocol (or the DHCP for IPv4) is not very fast and this is what DNA tries to remedy. It is also worth mentioning that timely support from the link layer, similar to our work in Chapter 6, is crucial for achieving smooth handovers. We will discuss this topic in Section 7.6.2. Nevertheless, as soon as DNA is becoming available, Gateway Nodes should be made aware of it and start using it when connecting to the Interconnecting Structures.
Another potential candidate for inter-Cluster communication is the Host Identity Protocol (HIP) [151]. In HIP, each host has at least one fixed iden- tifier called host identifier (HI). The HI may have the same form as an IP address and is used when establishing TCP or UDP sessions. The HI is mapped to a current valid and topologically correct IP address of the host. To initiate a new HIP session, a corresponding host would need to know the host’s HI and its current IP address. This can be discovered if they are direct neighbors on the same network. If not, the host may have a rendezvous server (RVS) [116], which is published together with the HI in, for instance, DNS. Each host will keep its RVS up-to-date by informing it through HIP messages every time it changes address [115]. When a HIP session is established with
another host, a change of the IP address is also communicated to the other host by a HIP message [165]. This will speed up the mobility handling for the ongoing session. Extensions for NAT-traversal also exist [111].
The data traffic of HIP is typically tunneled using IPSec [110] with ESP [109][105], but other alternatives are possible. Furthermore, this is not the only security feature of HIP. For instance, the HI is actually the public part of an asymmetric key. Using this feature, the end hosts can be authenticated and all HIP messages and data traffic can be protected after a four-way handshake between the two hosts. Unfortunately for PNs, HIP has its own security mechanism, which significantly differs from the one proposed earlier for PNs. Hence, for use in PNs, the HIP security mechanisms must be re- placed by the pair-wise keys approach used in a PN. Furthermore, HIP does only do host-to-host communication and not network-to-network communi- cation. Hence, for PN inter-Cluster communication, HIP must be extended with routing over the HIP sessions, which need to become HIP tunnels. How- ever, several other HIP mechanisms can be utilized in one way or another, such as the mobility handling, the RVS mechanisms, and the NAT-traversal. Mobility can also be handled at the transport layer [142][207][12][238] or the application layer [203]. The principles are the same as for the various IP-level mobility solutions. To maintain ongoing sessions, either a proxy is inserted between the two peers as in MSOCKS [142], or redirection messages are sent between the peers as in Migrate [207], STEM [12], and Reliable Sock- ets/Packets [238]. The main difference lies in the implementation, whether both TCP and UDP are supported, and whether modifications are needed to the applications and/or the operating system. To locate a mobile node