The Gateway Node implementation

The Gateway Node implementation is much more complicated. The main difference is that in addition to keeping the PNDB and handling signaling packets, it needs to do data packet handling and information gathering re- garding available local TEPs and the Cluster Node membership. The latter two have only partly been implemented. Figure 7.10 shows how the imple- mentation was done with the arrows indicated two not yet implemented and one only partially implemented. Despite these missing links, it has been possible to extensively experiment with the inter-Cluster communication im- plementation.

Except for some setup configuration scripts, all inter-Cluster communi- cation functionalities were implemented in one program named gwd. Gwd is similar to ppand in the sense that it also creates a virtual interface (called pn1 in Figure 7.10) and opens a UDP port for communication with other Gateway Nodes and the PN Agent. In addition to this, gwd also maintains the PNDB. It is responsible for all inter-Cluster signaling as well as data packet encryption and tunneling. Further, it needs to interact with the op- erating system to retrieve information about available network connections and their status. This information flow is, together with the inter-Cluster signaling traffic, indicated by arrow 1 in Figure 7.10. Arrow 2 indicates the information exchange between gwd and the OLSRd routing daemon. The

OLSRd routing daemon provides gwd with the Cluster member Node list, which it gathers from the intra-Cluster routing messages. In return, gwd pro- vides OLSRd with quality parameters regarding its current connections to the Interconnecting Structures. OLSRd propagates that information through the whole Cluster so that every Node can use the best connected Gateway Node.

On a Gateway Node that has the best connection to the Interconnecting Structures, a data packet from an application on the Node itself or from other Nodes in the Cluster (also other Gateway Nodes) will be forwarded to the pn1 virtual interface as indicated by 3 in Figure 7.10. The kernel will forward the packet to gwd (arrow 4) in the same way it forwards packets arriving on ppan1 to ppand. If gwd has a valid tunnel that can be used for forwarding the packet to its final destination, it will encrypt and forward the data packet over the local interface associated with that tunnel according to arrow 5. The data packet is encapsulated in a UDP packet with the two TEPs of the tunnel as source and destination addresses and ports. If gwd does not have any tunnel that can be used, it will consult its PNDB for information on how it can establish such a tunnel. Since the PNDB may be incomplete, it may need to query the PN Agent. In that case, the data packet will be enqueued by gwd until further information is retrieved and a tunnel can be established.

The gwd application does not discover connections to the Interconnect- ing Structures on its own, but expects the operating system to do so. This decouples the PN functionalities from the access networks discovery tech- nologies. It minimizes the impacts on existing legacy applications and also makes it possible for the PN communication to leverage the current and future developments in access networks.

Currently, most operating systems use DHCP [54], IPv6 router solicita- tions and advertisements [158], DNAv6 [157], or similar techniques for access network discovery. The most commonly used technique, DHCP, is typically handled by a user space program that reconfigures the routing table and other network-related settings in the operating system. Unfortunately, most DHCP clients will replace routes instead of keeping all alternatives. Because of this, we need to slightly modify the DHCP client.

Further, gwd needs to be informed when a new access network is discov- ered or an existing one disappears. On Linux, network settings like these can be accessed through the netlink socket interface [71]. Through that interface, user space applications, such as gwd, can retrieve and modify the network interface table as well as the current routing table. Furthermore, it is possi- ble to subscribe to update events for those tables, which gwd should do. It is then updated as soon as a DHCP client finds a new connection and may then update its TEP list based on the new information. However, all of this together with connection quality detection has not yet been implemented in our prototype.

7.7. THE PROTOTYPE 171

7.7.5

Lessons learned

The Python implementation of the inter-Cluster communication measured a total of 3200 lines of code (LoC), including comments. That includes 625 LoC for the PN Agent implementation, 1725 LoC for the Gateway Node functions, and 850 LoC for the common PNDB parts. Since this code was written in Python, which usually requires less LoC for the same amount of functionality, it is difficult to compare with the ppand implementation in Chapter 4, 5, and 6. However, the total code for the gwd implementation, which includes the most crucial parts of the inter-Cluster communication functions, is quite moderate.

This time around, we noticed performance degradation when using inter- Cluster communication. The round trip time increased by 1.5 ms when mea- suring between two Gateway Nodes using the same laptops (Intel Celeron M 1.6 GHz with 512 MB RAM) as in the earlier prototype experiments. Also the CPU load increased which caused the throughput to significantly de- grade. A large part of the performance degradation can be attributed to Python. Since the per-data packet handling of gwd is not heavier than that of ppand, the two should perform about the same. Hence, we strongly believe that an optimized gwd implementation in C will achieve similar performance as ppand. However, with encryption, the throughput dropped even further while the delay increased by an additional 20 ms. Since the encryption im- plementation is done in C, this performance degradation cannot really be attributed to the non-optimized implementation. Instead, it demonstrates the importance of using hardware encryption.

We tried the same set of applications as we did for the intra-Cluster com- munication. Still, all worked without modifications, which should not be a surprise. While an extra round trip delay of 1.5 ms is hard to notice, we could easily notice the throughput degradation when performing large file transfers. Mobility events were hardly noticeable as long as only soft han- dovers between two different interfaces took place. Hard handovers, where an interface changes from one access point to another, will certainly be notice- able. Significant handover delay will be introduced, but most of it consists of link layer handover latency and DHCP reconfiguration latency. Due to the implementation limitations explained earlier, we were not able to test this.

One last requirement not yet addressed by this implementation is ro- bustness to loss of signaling messages. In our test environment, virtually no packet loss occurred. In real Interconnecting Structures, packet loss may oc- cur and this sometimes requires signaling messages to be retransmitted. The only real measure against this problem taken by our implementation was the priorities introduced on the interface queues. Signaling traffic was given higher priorities than other traffic, avoiding signaling packets to be dropped at the Gateway Node itself. This was done in exactly the same way as was done for ppand.

7.8

Summary

This chapter focused on communication between a person’s Clusters. To implement this, secure intra-Cluster tunnels are established and maintained. The purposes of the tunnels are to protect the intra-PN traffic as well as transparently handle Cluster mobility. That is, the encrypted inter-Cluster tunnels are dynamic and updated when a Cluster changes its attachment point to the Interconnecting Structures.

Depending on the amount of infrastructure support that can be expected, we proposed several approaches to inter-Cluster tunneling. The best trade- off seems to be to rely on a server located somewhere in the Interconnecting Structures. This server, we refer to as a PN Agent and is constantly updated with the current locations of the Clusters and how they can be contacted. When tunnels must be established or updated due to mobility, the Gateway Nodes in the Clusters may query the PN Agent for assistance. Enough information is then shared to effectively establish or maintain the tunnels.

Other approaches were also studied, such as a solution where access routers in the Interconnecting Structures can support the mobile Clusters with PN-specific functionality. We also sketched a solution where no extra support from the infrastructure can be expected, including entities such as PN Agents. For such scenarios, a PN is best implemented using peer-to-peer technology between the Gateway Nodes.

We also looked at the routing issue over the inter-Cluster tunnels. A rout- ing approach integrated with the dynamic tunneling was proposed. It makes use of the PN Agent; the Cluster Node member lists are also communicated to the PN Agent. When a Gateway Node needs to transmit a packet to a Personal Node not in its Cluster, it may query the PN Agent to find out which tunnel to use or whether a new tunnel is needed. The benefits of this approach are mainly lower overhead and the ability to establish and maintain tunnels on demand.

An almost complete prototype of the proposed solution was made. The only missing functionality relates to the interaction with the operating system and the routing daemon with respect to retrieving the list of available access networks and the latest Cluster Node member list. The code was written in the Python programming language and showed the feasibility of the proposed inter-Cluster tunneling approach that we proposed.

Chapter 8

Foreign Communication

In the concept of PN, Nodes are divided into Personal Nodes and Foreign Nodes based on Trust Relationships determined by the owners. In the pre- vious chapters, we have only discussed communication among the Personal Nodes themselves. Communication between a Personal Node and a Foreign Node, which we call foreign communication, is obviously also required. For many applications, a PN needs to interact with other PNs as well as PN- unaware devices. This includes using Services from other PNs as well as offering them Services. Whenever access to the Internet exists, a PN must be able to communicate with any Internet host, such as for surfing the web, reading emails, etc. It must also be possible to locate remote PNs when their locations are unknown and initiate communication with them. Hence, we need to enable foreign communication and that is the topic of this chapter.

Foreign communication is a topic very specific to PNs. The way a PN is defined makes it necessary to also define solutions for foreign communication. However, the foreign communication problem can be divided into two parts. One part concerns the mechanisms within the PN and those mechanisms are tightly coupled and specific to the PNs. The other part concerns the protocols between the edge of the PN and the Foreign Nodes. In the latter, existing standards are crucial. We cannot expect Foreign Nodes to understand one or a few specific protocols. Instead, we must build our solutions on widely adopted protocols. Given these limitations, the target of this chapter is to demonstrate that foreign communication is possible and how to achieve it.

This chapter is structured as follows. Section 8.1 introduces the most important requirements for foreign communication, while Section 8.2 lists re- lated work. In Section 8.3, we start the description of foreign communication by investigating how to establish foreign communication. In Section 8.4, we go on to investigate how to connect the PN-internal networking with external networks, while we look at mobility aspects in Section 8.5. Authentication and anonymity for foreign communication is covered in Section 8.6 and in Section 8.7, we will discuss group foreign communication under an approach known as PN federations. Finally, in Section 8.8, we briefly look into how

Figure 8.1: Types of foreign communication

our PN prototype could be extended with foreign communication capabilities, before we summarize in Section 8.9.