No major problems were encountered during the implementation. The pro- totype worked smoothly on the laptops we used. The code size is small with only 6500 lines of code (LoC) in the C programming language which also in- cludes the code of the functionality used in Chapter 5 and Chapter 6. Only the security implementation is missing. Hence, we see no major problem on running this on embedded devices. If a device can support IP, then it can support Cluster formation and communication.
We used Ethertap to be able to develop the code in user space instead of kernel space. This was done for simplicity. It made it easier to imple- ment, but more importantly, much easier to test and debug. Because of this,
data packets are passed between user and kernel space several times and one extra time through the kernel routing table. Despite all this, no real perfor- mance degradation could be noticed compared to if the two laptops would communicate without the PN prototype with Ethertap and all.
All applications we tried worked without modifications as long as they support IPv6. This included SSH (secure remote shell), SCP (secure file transfer), Firefox (web browser), and a VoIP Application. Furthermore, we found that a Cluster could become multi-hop without problems when we enabled OLSRd.
A problem discovered during the prototyping was the handling of the maximum transmission unit (MTU). We had to assign a MTU for the virtual Ethertap interface as well. Normally, the MTU specifies the maximum pay- load allowed by a link layer. However, the virtual interface can dynamically select the outgoing interface and the different interfaces can have different MTUs. Hence, it is not clear what the MTU of the virtual interface should be. The best option is probably to assign the MTU to the interface with the largest MTU minus the Cluster-specific headers. However, this may trick the kernel to generate too big packets when another link is chosen and this creates extra signaling in the form of ICMPv6 Packet Too Big messages. However, this is actually quite normal and the kernel or the source Node reduces the packet size when such a signaling message is received.
4.7
Summary
In this chapter, we studied Cluster formation and maintenance. Clusters are nothing more than active Personal Nodes that can communicate with each other using their own communication features and without external support. Clusters are basically ad hoc networks and may therefore consist of multiple heterogeneous wireless technologies and hence be multi-hop networks.
We defined a Cluster as connected network consisting of active Personal Nodes exclusively and argued that this is the best one. It makes intra-PN communication rely on local communication to the largest possible degree. Since we believe local communication will outperform long distance commu- nication most of the time, this should lead to the most optimal solution.
Then we walked through all the necessary mechanisms for Cluster forma- tion and maintenance, such as neighbor discovery, Personal Node authenti- cation, anonymity, and establishment of secure intra-Cluster communication. In the last section, we presented how we implemented a Cluster formation prototype on laptops running Linux. Details were given on how it worked and how it performed. Measurements indicate that only encryption may add any significant overhead to the intra-Cluster communication. Hence, we believe that we demonstrated the feasibility of our Cluster formation and maintenance approach.
Chapter 5
Cluster-Wide Broadcasting
PNs need Cluster-wide broadcasting. For many applications, it is necessary to transmit a packet from one Node to all the others inside a Cluster. How- ever, in a multi-hop Cluster, the range of the source Node does not cover the whole Cluster and therefore needs help from other Nodes to relay the packet to reach all Nodes. This process, we refer to as flooding, which is an important feature for any wireless multi-hop network.
Flooding is used by several unicast routing protocols [179][104] for multi- hop networks to disseminate route requests or link states. Other applications include service discovery, sharing of context information, address autoconfig- uration [30], and network self-organization. In mobile networks, flooding is often a better choice than multicasting due to the frequent topology up- dates [167]. Understanding flooding will help us understand other aspects of multi-hop networks as well.
The simplest flooding mechanism for multi-hop networks is Blind Flood- ing, in which a node always retransmits a received flooding packet after a small random delay (jitter). Each node needs to keep a list of recently re- ceived flooding packets to detect duplicates and avoid retransmitting the same packet twice. However, this is the only mechanism in Blind Flooding that reduces the number of retransmissions.
Several studies of flooding protocols have revealed that it is possible to reduce the number of retransmissions much more [225][231]. This has the benefit of reducing contention, collisions, saving energy, and it may even increase the flooding speed. Such optimized flooding protocols can make use of location information, neighbor information, or observations of the ongoing flooding. Protocols using location information require solutions like global positioning system (GPS) in every node, which is too strong a requirement for most PN devices. Besides, the improvements brought by location information have not proven to be very significant [231], especially if there is mobility. We therefore assume in our research that the nodes do not have such information. This chapter is structured as follows. Section 5.1 introduces the most important requirements for Cluster-wide broadcasting. Section 5.2 lists re-
lated work, including existing flooding protocols suitable for Clusters and previous experiments with flooding. In Section 5.3, we propose a new flood- ing protocol, called Prioritized Flooding with Self-Pruning (PFS) [99], which is an optimization and combination of two existing flooding protocols. We then verify PFS’s performance by a series of measurements in a real wireless multi-hop network, which is introduced in Section 5.4. The experimental network is intended to give us a better understanding of how the flooding protocol behaves. Typical Clusters will look quite different, but the results we obtain using our experimental networks are also directly applicable to any type of Clusters. In Section 5.5, we present and discuss the results of the measurements. We attempt to simulate PFS’ performance in Section 5.6, but conclude that the simple network model used in ns-2 [159] is insufficient for our purposes. In Section 5.7, we introduce how we enhanced our prototype from Chapter 4 to also do optimized flooding within a Cluster. Section 5.8 summarizes this chapter.
5.1
Cluster-Wide Broadcasting Requirements
To achieve satisfactory Cluster-wide broadcasting, we need a flooding solu- tion that fulfills the following requirements:
1. Support for heterogeneous link layer technologies. This is an important requirement, since Clusters can be connected using various link layer technologies simultaneously.
2. The solution must be able to deliver a Cluster-wide broadcasting packet to all Nodes in the Cluster with a very high probability. A Cluster is per definition connected and that means that a flooding protocol must be able to reach all Nodes. Applications should be able to depend on the flooding reaching all Nodes in the Cluster.
3. The amount of resources used, such as the number of transmissions, packet overhead, and computation, should be minimized. Most impor- tantly, unnecessary transmissions should be avoided. This minimizes collisions, contention, and the impact on other traffic.
4. No unnecessary delays should be introduced. Many applications require Cluster-wide broadcasting to be timely.
5. Node mobility within the Cluster must be supported. Since Cluster Nodes are mobile, mobility must be handled without jeopardizing the other requirements.
6. Robustness against errors and security attacks. External as well as internal disturbances, intentionally or unintentionally ones, should be
5.2. RELATED WORK 83
dealt with in an appropriate way while still satisfying the other require- ments.
To meet all requirements is very difficult. Many of them are even contra- dictory. This means that a balance must be achieved. Unfortunately, what is sufficient and what the balance should be is extremely difficult to quantify. In this chapter, we will mainly focus on requirements 2 to 5.
5.2
Related Work
Any flooding protocol for general ad hoc networks is, in principle, applicable also to Clusters, as long as it supports the requirements above. Many different flooding protocols have been proposed in the past. In this section, we only introduce the most common protocols and protocols similar to PFS. For a more extensive survey of flooding protocols, see [231][215]. At the end of this section, we comment on previous experiments with flooding in real networks.