not share the same operating system (e.g., Linux, Windows ... MANETs, and therefore the development process of rout- ..... a single timer per application.
Optimizing the implementation of a MANET routing protocol in a heterogeneous environment Carlos Miguel Tavares Calafate, Roman Garcia Garcia, Pietro Manzoni Department of Computer Engineering Polytechnic University of Valencia (UPV), Valencia, SPAIN calafate, roman, pmanzoni @disca.upv.es Abstract This paper focuses on the implementation of heterogeneous Mobile Ad Hoc networks (MANET). A heterogeneous MANET is a wireless network setting without a fixed infrastructure where participating devices may be of different kind (e.g., desktop, laptop, or palmtop computers), may not share the same operating system (e.g., Linux, Windows NT, or Windows CE), and may not share the same wireless technology (e.g., Bluetooth, or IEEE 802.11b). We describe the design and implementation of a prototype for the OLSR routing protocol, targeting multiple operating systems, devices, and radio technologies. We choose a proactive routing protocol to obtain optimal routes in a dense network with slow mobility patterns and to ease the portability task to the heterogenous environment. We also optimized the OLSR protocol, making it more reactive to topology changes.
1 Introduction Mobile Ad Hoc networks (MANETs) are becoming widely deployed as they allow the rapid establishment of an interconnected network with little effort and without the need for a fixed infrastructure. They are the preferable solution when groups of users have to join during short periods of time, especially in bounded regions. The IEEE 802.11b is the most widely accepted wireless technology for use in MANETs, and therefore the development process of routing protocols for MANETs is centered around it. Concerning the devices and operating systems used, research has focused on laptop devices due to their characteristics of mobility and processing power. The typical operating system is Linux due to its open-source nature, which makes it optimal for the development and the evaluation of new features.
This work was partially supported by the Generalitat Valenciana under grant CTIDIB/2002/29
This paper concentrates on the implementation of heterogeneous MANETs. In [1], a dedicated protocol is presented to cope with a heterogeneous environment. Heterogeneity was represented by the diversity in communication medium technology (such as wired, wireless, satellite, and optical links), as well as by the types of devices the network will interconnect. We consider a heterogeneous MANET a wireless networking setting where participating devices may be of different kind (e.g., desktop, laptop, or palmtop computers), may not share the same operating system (e.g., Linux, Windows NT, or Windows CE), may and not share the same wireless technology (e.g., Bluetooth, or IEEE 802.11b). Such variety can sometimes be a drawback in the development of users’ applications. We focus on a solution which tries to be an example of harmonization of all these different elements. The starting point is the OLSR protocol[2], a network routing protocol whose implementation for Linux is made freely available by its creators. An optimization of this implementation is presented targeting the protocol internals, the supported devices and operating systems and the radio technologies which it integrates. Concerning the structure of this paper, section 2 consists of a small introduction to OLSR’s architecture; in section 3 we will explore the development cycle of OLSR towards multi-platform compatibility; section 4 refers to the expansion of OLSR for multi-technology MANETs with the introduction of Bluetooth support. Section 5 will present some of optimizations made to the protocol, as well as the results achieved. Finally, in section 6 concluding remarks will be made.
2 The Optimized Link State Routing protocol The Optimized Link State Routing protocol [3], [4] is a routing protocol specifically designed for Mobile Ad Hoc Networks (MANETs). It is based on the definition and use
more reactive to topology changes. Section 5 describes the details of our optimization proposal.
of dedicated nodes, called multipoint relays (MPRs). MPRs are selected nodes which forward broadcast packets during the flooding process. This technique allows to reduce the packet overhead as compared to pure flooding mechanism where every node retransmits the packet when it receives the first copy of it. Contrary to the classic link state algorithm, partial link state information is distributed into the network. This information is then used by the OLSR protocol for route calculation. The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context. The Internet Engineering Task Force (IETF) MANET working group [5] proposed various routing protocols for Ad Hoc networks during the past few years. Those protocols can be classified into three broad categories: proactive, reactive, and mixed. OLSR is a proactive protocol. Proactive protocols establish and maintain paths independently on whether there are actual packets flowing through these paths. This particular aspect might be considered a disadvantage since it makes use of bandwidth in MANETs where communication is scarce, but has the advantage of reducing latency associated with communication setup since available routes are established before actually being used, which turns out to be appropriate when there are multiple packet flows and changing source/destiny pairs. In reactive protocols, like the AODV [6] protocol or the DSR [7] protocol, the route discovery procedures are invoked on demand when a source has a new connection pending towards a new destination. The route discovery procedures generally consists of the flooding of a query packet which eventually produces the route to the destination as a reply. These techniques do not guarantee the creation of optimal routes in terms of hops vs. distance. There is not an optimal routing solution which is independent from the scenario in which it is used. The most viable solution is to build mixed solutions that can dynamically adapt to manage the tradeoffs between proactive and reactive routing to meet ‘local’ conditions. That is, the appropriate routing strategy will depend on factors that are both temporally and spatially determined. A routing protocol can also be made more “dynamic” by measuring external effects, and dynamically adjusting internal parameter values. This is not actually a mixed approach, but it may be sufficient to handle most time-varying scenarios. From the implementation point of view, reactive protocols require a strong interaction with the kernel in order to interrupt packet flow for route discovery purposes. This particular requirement makes it specially difficult to implement such protocols on closed platforms like Windows NT/CE. We therefore adopted a proactive protocol to obtain optimal routes in a dense network with slow mobility patterns and to ease the portability task to the heterogenous environment. We anyway optimized the OLSR protocol, making it
3 Implementing a multi-platform solution Linux, in part due to its open-source policy, is the most widely used operating system to implement prototypes. Similarly, the ANSI C programming language is the most commonly used to implement networking code due to its flexibility and to its ability to optimize code size and speed. Two basic problems emerge when porting existing solutions to platforms like Windows NT or Windows CE: platform restrictions and code incompatibility. The former problem can only be solved with a new release of the operating system, or not solved at all; we therefore concentrate on the latter problem. We propose a multi-platform API focused on communication protocols design, called PICA [8]. The main goal of PICA is to provide a unique programming interface to be used to write networking code. The resulting code will be usable in the Linux operating system and in the Windows NT/CE operating systems. The PICA API was designed targeting both simplicity and usefulness. Simplicity was achieved through a straightforward and unified approach to the API calls, and usefulness was achieved by locating those services which where required by the protocols we wished to implement, but whose interface did not match any of the three target platforms. These services include threads, mutexes, semaphores, timers, pipes and other system management primitives, as well as network management primitives that allow users to control the forwarding process and the forwarding table, perform raw packet read/write, retrieving available interfaces and interface configuration, etc. One of our main goals was that the size of PICA remained small, so that it could be used as part of any protocol distribution. PICA’s size for version 1.1.0 is under 50 kilobytes for Linux and Windows CE platforms, and about 200 kilobytes in the Windows NT platform. The PICA library creates an adaptation layer between the user and the kernel space and offers specialized functions that aid the programmer activity when creating networking solutions based on packets capturing and handling. PICA, as illustrated in figure 1, does not hide completely the underlying layers. Depending on the needs of the protocol being designed, we could use the PICA interface, the pcap [9], [10] library or directly the kernel. The use of the pcap libraries does not compromise inter-platform compatibility, since there are pcap versions available for all the platforms where PICA is available. Using kernel specific functions the source code will loose its compatibility between platforms, and porting it will require and extra effort on the developer side. The PICA architecture is divided into two sets of prim2
User App. Call to PICAselect()
PICA internals PCAP library
PICA
Creation
WaitForMultipleObjects()
Event
on HANDLES
Pipe
Kernel Figure 1. Designer API choices
select() on Sockets
PICAselect() result
itives, namely the system management primitives and the networking management primitives. The former deals with the different approaches an operating system takes to handle its resources, while the latter deals with data packets and routing structures.
Figure 2. Architecture of the PICAselect() function in Windows
3.1 The system management primitives current thread stops waiting for events using a WaitForMultipleObjects() call and a secondary thread is created. This thread is dedicated uniquely to socket handling. When an event occurs on a socket, the secondary thread informs the waiting thread, and through a system pipe it sends the information about which socket is active (see Figure 2). Relatively to memory management, the PICA architecture is based on offering the possibility to easily handle a queue data structure. The aim was to provide auxiliary functions which could be useful at implementation time. The programmer can create as many queues as desired, allowing differentiated packet handling. The architecture chosen allows the use of multiple groups of queues, each group having a number of queues chosen by the user. In order to guarantee data coherence to multi-threaded applications, PICA uses a different mutex status variable to control the access to each queue so that, for example, distinct threads can read and write to different queues, even though these queues belong to the same group. It is relevant to point out that in order not to generate meaningful delays, these routines do not perform any kind of buffer duplication, having the sole task of managing pointers to the data. PICA offers a generic pipe data structure, too. It is a good practice to include logging capabilities in the applications that are developed, especially when these applications are network daemons. The PICA logging functions offer straightforward methods to read from and write to files. The new file type created has the unique purpose of unifying the different data types, i.e., HANDLE in Windows and int in Linux, used as file descriptor. Finally, PICA has a very reduced set of administrative
Two basic tasks are quite often used when designing protocol implementations: process management and memory management. The fork() call is of common use in Unix environments to manage processes. Windows systems, though, do not offer this function. We therefore adopted a combination of the threads approximation with the semaphore and mutex abstractions as an alternative to processes without generating too much extra code. Although the Posix standard [11] does not allow thread suspension and resuming, the PICA library allows the use of such functions in the Linux operating system by means of the SIGUSR1 and SIGUSR2 signals. This solution tries to cope with the differences with the Windows kernel where such functions exist. The recommended practice is anyway to avoid such calls because they can produce unpredictable results in critical sections of code. Also, the Posix standard implementation does not allow setting the maximum value of a semaphore, which is a feature available in Windows. PICA also provides such functionality, though introducing a little overhead. The select function is a well known Unix system call used to wait for events associated with any kind of descriptor; descriptors are represented by integers values. Instead, in Windows operating systems, the descriptors are generally represented by a specific data type called HANDLE, while integers are only used for sockets. In Windows the select function is only available for sockets, while for others events we have to use a function of the WaitFor family. The PICA library obviates this problem by emulating the Linux behaviour. When invoking the PICAselect() function the 3
Linux O.S.
functions used for such tasks as to initialize and release the library, to get a list of the devices available, to activate Windows Sockets API, or to test if the current user has certain privileges. PICA also provides a straightforward way to handle errors. Since all functions return either or in case of error or of success respectively, every time an error occurs the PICA library is updated and a call to a specific function (PICAgetLastError()) returns a string containing the error message, as well as the error number. We chose this technique since it is practical and widely used.
Original Implementation
Linux O.S. Linux native PICA
W2k & WCE Linux native native PICA Windows CE O.S.
W2k native
Linux native
PICA Windows 2k O.S.
Figure 3. Development cycle with PICA
3.2 Networking management primitives ble. These functions are not frequently used, but we found that they are sometimes useful in protocol design to provide dynamic connectivity. See, for example, the AODV implementation [13]. Moreover some protocols need to check some of the entries, like the broadcast ones, and this can be easily accomplished using these functions. We also give the possibility to get access to the current forwarding status and to the time-to-live (TTL) attributes. It should be noticed that the TTL value affected is the global system’s TTL. Lowering this value too much might cause loss of connectivity to other networks (e.g., Internet). For a per-socket definition of this value, the socket options available in most systems should be used.
The basic data structure abstraction is the data packet. PICA offers a small set of functions to send and receive (capture) packets. The approach taken in Linux and Windows are quite different. In Windows we inherited the functions to send and receive packets offered by the PACKET.DLL library which is part of the winpcap distribution. While Linux does not offer such a library it provides direct read and write access to a network interface (NIC) by using the PF PACKET socket domain. The socket interface is also one of the most frequently used interfaces when developing protocols implementations. PICA encapsulates this API using macros and eliminates the apparently slight differences between the various platforms. It should be noticed, though, that the Windows Sockets Version 2 (WinSock 2) API [12] does not provide useful functions such as the recvmesg and sendmsg whereas in Linux they are available. WinSock 2 also lacks of some of the options that are available on Linux based implementations. These factors should be taken into account by programmers, because they can compromise the compatibility between platforms. Handling timers is also of extreme relevance. Protocols and applications are often required to perform scheduled actions, e.g., to take into account network congestion status. Differently from Windows, the Linux architecture imposes a single timer per application. This ”restriction” encouraged us to provide PICA with multiple timers, by means of a priority queue. In this queue all events make use of the same timer in a way that only the first to-happen event affected will be used to set the value of the timer. There is a thread that executes the code indicated by the user, allowing the event handling to be not only asynchronous, but also parallel. The solution provided allows high versatility due to the possibility of multiple call-back functions, each accepting an argument. This allows for a differentiated approach to events, enabling the designer to group events into families, achieving more elegant solutions to common problems. Finally, PICA provides functions to handle the IP routing functionalities. The PICA routing functions allow the designer to add and remove entries in the forwarding ta-
3.3 OLSR implementation with PICA The OLSR architecture, due to its pro-active nature, allows us to do an artificial separation of the daemon into two blocks, which we called intelligence block and actuation block. The intelligence block is responsible for managing information relative to the link status, the routing table, and the message generation and interpretation, etc. The actuation block is responsible of performing system related operations, like message sending and receiving, managing the forwarding table, handling logs, trace and debug data, handling user actions, etc. To generate a platform independent version of the OLSR protocols we started from a version made available by its creators at INRIA. The intelligence block code portion almost does not use any specific system call, therefore simplifying its porting to other platforms. Concerning the actuation block, the nature of the tasks performed made it more system dependent. By doing a gradual transformation of the code in this block using the PICA library we were able to quickly reach the final solution for all three target platforms, and our analysis showed that they worked according to the version 3 of the draft, being similar to the original implementation available. The strategy used in the migration of OLSR is illustrated in figure 3. We started the porting by adapting the already existing Linux platform version code. We then proceeded 4
6
to the Windows NT version and finally to the Windows CE version. The reason for this development path is the portion of the API shared by these platforms. The Linux port consisted of a gradual substitution of code, with native system calls being successively replaced by PICA library calls. This allowed us to do a step by step check of the integrity of the code by testing each major change using a running version. This phase was the most time consuming part in the porting process since it was necessary to change most of the system specific code to PICA. With most of the incompatible code blocks already replaced by PICA calls in the Linux port, all that remained were a few blocks of code which were neither compatible with Windows NT nor were they included in PICA. These were essentially a few spots, like the Linux bzero call (ZeroMemory in Windows) or some of the returning values for sockets. These problems were solved using preprocessor directives. Windows CE, even though strongly similar to Windows NT, differs from this mainly due to the absence of the concept of a terminal and of standard I/O devices, and also because every application requires an associated GUI window. Anyway the solution we applied required only small changes in the code. Namely, writes to the standard output and the standard error where substituted by Edit Box writes, and the daemon had to run in a separate thread with high priority. A graphical user interface had to be created in order to make available the required user options, but once the daemon is running, window interaction is minimal in order to reduce as much as possible the consumption of resources. Anyway, all the parts of the code which belong to the core of the daemon maintained compatibility with the previous platforms as desired. After reaching a working solution on all three target platforms, we integrated PICA inside the OLSR routing daemon. This allowed us to create binaries that did not require PICA as an external library for execution, with the additional benefit that, due to PICA’s modularity, the unnecessary blocks of the library could be discarded in a simple and straightforward manner. This operation incremented the daemon running code size by an average of 30%.
5
Throughput (Mbit/s)
4
BT-BT BT-Mixed 802.11-802.11 802.11 Mixed
3
2
1
0 0
5
10
15
20
25 Time (s)
30
35
40
45
50
Figure 4. Performance of TCP on IEEE 802.11b and Bluetooth mixed environments
with the PAN profile. Figure 4 presents the results of this experiment. The BT-BT and 802.11-802.11 results were achieved in an isolated situation and are used as a reference. Results referred to as BT-Mixed and 802.11-Mixed were achieved running the FTP transfer while having the 4 devices close by in a 5 squared meters area. As expected, the experiment results show that the performance of both Bluetooth and IEEE 802.11b TCP connections are clearly affected by each other. The Bluetooth bandwidth, already much lower than the IEEE 802.11b’s, even showed an higher degradation. These results led us to think that the Bluetooth bandwidth is at a premium, the best solution being an implementation where no OLSR packets were required to flow through Bluetooth channels. We therefore propose to integrate Bluetooth devices in a MANET by using a star topology. The “Bluetooth only” nodes must be kept unaware that they belong to a MANET. The star core being a device with high availability of resources and connectivity. The node to which they are connected to, the star core, must have both a IEEE 802.11b as well as a Bluetooth card. The core is responsible for advertising to other nodes in the MANET the presence of the Bluetooth devices connected to it. That way all the nodes in the MANET can reach the “Bluetooth only” nodes. These devices do not need any special configuration, since all the traffic they generate will pass though their master, the star core, being then properly forwarded through the MANET. This solution not only saves Bluetooth bandwidth, but also minimizes interference between technologies when there is no data flowing through Bluetooth channels. Moreover, we do not need any running module of the MANET routing protocol on the “Bluetooth only”. Providing this solution was made possible with only a few changes in the daemon; specifically, the user has to notify the daemon of which Bluetooth devices are associated to it. In order to test the effectiveness of this proposal, we built the simple ad-hoc scenario presented in figure 5. Node B is an iPaq 3850 running Windows CE 3.0, and node E is a laptop running Windows 2000. The remaining nodes are also laptops running the Linux operating system.
4 Multi-technology approach Integrating Bluetooth technology in a IEEE 802.11b based MANET is not trivial. The basic issue is related to radio interferences [14]; the IEEE 802.15 Working Group is dedicated to studying this problem. Since most of the traffic that flows in the Internet is TCP based, we made a simple experiment in order to evaluate the impact of radio interference focussing on this protocol. Using the ”TCPstat tool” [15] we set-up a simple scenario where two Bluetooth nodes and two IEEE 802.11b nodes were performing FTP transfers. The Bluetooth protocol stack used was Affix [16] 5
3e+06 3 hops 2 hops 3 hops-Bluetooth 2.5e+06
Throughput (bits/s)
2e+06
1.5e+06
1e+06
500000
0 0
Figure 5. Simple scenario for the Bluetooth devices integration evaluation
20
40
60
80 Time (s)
100
120
140
160
Figure 7. TCP results for FTP transfer 2.1 Original Jitter 2
Time (ms)
1.9
1.8
1.7
1.6
1.5 0
10
20
30 40 HELLO Packets
50
60
70
Figure 8. Time interval between Hello messages with original implementation and with jitter
Figure 6. Ping results for the experimental hybrid MANET
In this scenario node A was sending pings messages to nodes D and E. As illustrated in the figure, node D has a Bluetooth connection to node C, and all the other connections use IEEE 802.11b channels. Our configuration forced the packets to go through three hops, which was an acceptable reference value inside a MANET. The results of the ping tests are presented in figure 6. The figure shows that Bluetooth connectivity was achieved successfully and that, as expected, the round-trip times for the ICMP packets were much higher for the A-D path. These results also make evident that even though the reachability of Bluetooth nodes is achieved with acceptable delays, the response times will be quite high. Concerning other hybrid topologies, where not all Bluetooth nodes are connected to a hybrid node, it should be pointed that the delay values can be very high, too. We evaluated the performance of TCP under Bluetooth, using the scenario of Figure 5 by generating FTP transfers between nodes A-D when evaluating Bluetooth and between nodes A-E when evaluating just IEEE 802.11b connections. The “2 hops” test consisted of making a direct connection between A and C, bypassing node B. Figure 7 shows the results of these experiments. The results presented in that figure show that having one extra hop does not reduce throughput significatively, since there is only a 0.4% throughput increase in the 2 hops scenario. However, the average throughput value when the final hop belongs to a Bluetooth connection is quite lower, which is due not only to the restriction of bandwidth on the Bluetooth connection, but also to interference between the Bluetooth and IEEE 802.11b radio technologies.
5 OLSR optimization The version 3 of the OLSR protocol was based on the use of a timer that generated asynchronous interruptions every 2 seconds, defined as the Hello message interval. This scheme had two problems: first, due to timers interactions with packet processing the OLSR messages tended to become synchronized [3]. This effect led to collisions and consequently to packet losses. The second problem had to do with the nature of the timers, that did not allow for an adaptive generation of messages according to node mobility. To avoid these problems we modified this scheme by removing the timer completely and substituting it by a temporized select call. This makes the daemon free of asynchronous events (except for daemon termination), and therefore makes the programming task simpler and straightforward. Now, random jitters can be added to the Hello message interval, solving the problem of message synchronization. Also, OLSR message generation can adapt itself to the node’s mobility by making the inter-Hello interval vary according to a defined measure for mobility. In figure 8 we show the interval between Hello messages for a single node with the original implementation compared with the results obtained by introducing the jitter, according to [3]. We can see that with our proposal the Hello interval has random values between 1.5 and 2 seconds, which complies with the drafts that states that: , where MI (Message Interval) is defined as 2 seconds and jitter is 6
6.2
1.8 Jitter Normal
Original FTC support 1.6
6 1.4 5.8
Reaction time (s)
Time (ms)
1.2 5.6
5.4 Avg.=5.25
1
0.8
0.6
5.2 0.4 5 0.2
4.8
0 2
4
6
8
10
12
14
0
2
4
6
TC Packet
8
10
12
14
16
18
20
Fast TC packet
Figure 10. Reaction times to topology changes
Figure 9. Time interval between TC messages with original implementation and with jitter
7 TC interval
defined as a random value in the interval [0, 0.5]. The OLSR drafts state that the time between Topology Control (TC) messages when there are no topology changes to report should be 5 seconds. However, in order to save bandwidth, the original OLSR implementation complying with draft v.3 sent TC messages along with HELLO messages, which meant that for each 3 HELLO messages, one TC message was sent. As we can see in figure 9, this led to a time between TC messages of 6 seconds instead of 5 in a static topology environment. With the insertion of jitter on the message generation system, TC messages are affected too, with the average value changing from 6 to 5.25 seconds, which is much closer to that stipulated in the draft.
6
Interval (s)
5
4
3
2
1
0 0
10
20
30
40
50
60
TC packet number
Figure 11. Time interval between TC messages with fast topology changes support
onds. Figure 10 presents the reaction times of the daemon with and without support to FTC in a network of a few nodes and average mobility. As can be seen, the reaction times where greatly improved so that now the reaction time does not surpass the upper limit of 0.5 seconds. The lower limit has to do with the time it takes for the system from the moment it discovers a topology change to the moment after the reaction packet has been sent and the daemon regains control. It will therefore depend on system speed and kernel interactions. In figure 11 we can see how the time interval between TC messages evolved after the introduction of support for Fast Topology Changes. Contrarily to the behavior of the original implementation, where the lower threshold was the inter-HELLO interval (2 seconds), now the new lower threshold changes to 0.5 seconds, which proves conformance with the drafts. It should be noticed that the changes presented in this section would not be appropriate without the introduction of jitter because the low reaction times introduced in the FTC process would lead to message synchronization between nodes very quickly. In order to further evaluate these FTC related optimizations we created a simple scenario of 3 nodes. The test consisted of evaluating ping losses and TCP throughput by using scripts to provoke topology changes at pre-defined instants in time. These scripts used the MAC filtering modules of Linux’s iptables tool. Our solution allowed the creation of a virtual mobility scenario which was independent
5.1 Fast Topology Changes (FTC) support In the previous section we pointed that the OLSR internals were such that the generation of MPR messages was synchronized with the generation of HELLO packets. This implementation, even though optimal at saving bandwidth, is not optimal in terms of high reactivity to topology changes because Topology Control messages can only be sent at fixed instants along with the next HELLO message scheduled. We devised a solution where TC messages could be sent immediately after a change in topology, although respecting a minimum interval of 0.5 seconds between consecutive TC packets as stated in the draft. We also considered that it would be a wiser option to send a HELLO message along, instead of just the TC message, because the overhead introduced is small compared to the total size of the packet. This approach implies that HELLO messages are sent statistically more often, therefore increasing the number of connectivity checks with surrounding nodes. This increase grows in situations where surrounding node mobility is confirmed. We also took care of rescheduling the next HELLO taking into account that an asynchronous HELLO was sent and, therefore, the lower limit for the time between HELLO messages is the same as for TC messages, which is 0.5 sec7
Packet loss Ping min. time Ping avg. time Ping max. time Ping max. dev.
Original 66% 2.015 ms 5.886 ms 10.241 ms 2.392 ms
With FTC 55% 1.976 ms 5.774 ms 10.417 ms 1.988 ms
to achieve major improvements in reactivity to topology changes it will be more effective to reduce the neighbor hold time and reduce the HELLO interval, because it is in neighbor detection that most overhead abides; however, this is outside of the scope of this paper.
6 Conclusions
Table 1. FTC evaluation through Ping 30000 Original FTC
In this paper we described the design and implementation of a prototype for the OLSR routing protocol, targeting multiple operating systems, devices, and radio technologies. Using a specifically designed API, called PICA, we analyzed the development process followed in order to obtain a multi-platform implementation of the protocol. We show how PICA simplifies and accelerates the development process, allowing developers to attain the final solution quickly. It was also evidenced that the routing code size, including PICA, is kept reduced. The possibility of integrating PICA inside the daemon was also considered, as well as the ability of tailoring PICA to the daemon’s needs. The support for heterogeneous radio technologies was introduced with an extension of OLSR in order to support Bluetooth nodes, being these restricted to a star topology surrounding an hybrid node. We showed how well this strategy performs in terms of applicability and preserving the scarce bandwidth available in Bluetooth links. The results prove that our purpose of reachability was accomplished successfully, but they also put in evidence the latency associated with Bluetooth connections. Finally, some optimizations to OLSR where introduced in order to avoid synchronization problems and to achieve faster reaction times to changes in node topology. Synchronization problems where solved with the introduction of jitters in the HELLO packet generation process, which, as stated in version 7 of the draft, helps to avoid some problems associated with broadcasts. Topology Control messages generation also takes advantage from this change because the original inter-message time for static topologies was one second above the time recommended in the draft. Concerning the support of fast topology changes, results showed that reaction times where greatly improved and that its effects in terms of connectivity and throughput where also satisfactory.
25000
Throughput (bit/s)
20000
15000
10000
5000
0 50
100 time (s)
150
200
Figure 12. TCP evaluation of Fast-TC optimizations
of user movements, making it more accurate and appropriate for a comparative evaluation. The script used in our tests consisted of a loop where we allowed direct connectivity between two of the nodes for 4 seconds, and connectivity only through the third node for 10 seconds. We considered this mobility scenario was adequate since it would be quite demanding for the current OLSR implementation, taking into account that the time specified in the drafts relative to the neighbor hold time is 6 seconds. The ping test was made with the standard ping application with the inter-packet interval set to 0.75 seconds. Table 1 presents the ping results for this scenario with and without our FTC optimization, showing that there was a slight improvement in connectivity as expected. TCP performance was also evaluated, again using the tcpstat tool to monitor an ftp file transfer. The tool was set so as to provide statistics every second in order to allow a more accurate visualization. The results obtained are shown in figure 12. As can be seen, TCP throughput also benefits from the optimizations introduced with an average throughput gain for the FTC solution of "!$# %'& , which is a value similar to that obtained in the ping tests, where the gain was of (')# ('& . It should be noticed however that the values obtained should not be considered final since they also depend on whether the HELLO messages are more or less synchronized between themselves and with the test script, specially for the scenario where nodes are running the original OLSR implementation. The jitter introduced for FTC support makes the test less synchronization dependent, meaning that the results for FTC are more stable and reliable. As a final remark it should be pointed that in order
References [1] Ignacio Solis, Katia Obraczka, and Julio Marcos. FLIP: a flexible protocol for efficient communication between heterogeneous devices. In 6th IEEE Symposium on Computers and Communications, July 2001. 8
[2] T. Clausen, P. Jacquet, A. Laouiti, P. Muhlethaler, A. Qayyum, and L. Viennot. Optimized link state routing protocol. International Multi Topic Conference, Pakistan, 2001.
[13] Charles E. Perkins, Elizabeth M. Belding-Royer, and Samir R. Das. Ad hoc on-demand distance vector (AODV) routing. Internet Draft, MANET Working Group, draft-ietf-manet-aodv-10.txt, January 2002. Work in progress.
[3] Thomas Clausen, Philippe Jacquet, Anis Laouiti, Pascale Minet, Paul Muhlethaler, Amir Qayyum, and Laurent Viennot. Optimized link state routing protocol. Internet Draft, MANET Working Group, draftietf-manet-olsr-07.txt, July 2002. Work in progress.
[14] Ratish J. Punnoose, Richard S. Tseng, and Daniel D. Stancil. Experimental results for interference between Bluetooth and IEEE 802.11b DSSS systems. IEEE Vehicular Society Conference, October 2001. [15] Paul Herman. The tcpstat tool. Publicly available at: http://www.frenchfries.net/paul/tcpstat/, February 2001.
[4] T.H. Clausen, G. Hansen, L. Christensen, and G. Behrmann. The optimized link state routing protocol, evaluation through experiments and simulation. IEEE Symposium on ”Wireless Personal Mobile Communications”, September 2001.
[16] Dmitry Kasatkin et al. The affix bluetooth protocol stack for linux. Publicly available at: http://affix.sourceforge.net/, October 2002.
[5] Internet Engineering Task Force. Manet working group charter. http://www.ietf.org/html.charters/manet-charter.html. [6] Charles E. Perkins and Elizabeth M. Royer. Ad hoc on-demand distance vector routing. In Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, LA, pages 90– 100, February 1999. [7] David B Johnson and David A Maltz. Dynamic source routing in ad hoc wireless networks. In Imielinski and Korth, editors, Mobile Computing, volume 353. Kluwer Academic Publishers, 1996. [8] Carlos Calafate and Pietro Manzoni. A multi-platform programming interface for protocol development. 11th Euromicro Conference on Parallel Distributed and Network based Processing, Genova (Italy), February 2003. [9] Fulvio Risso and Loris Degioanni. An architecture for high performance network analysis. Proceedings of the 6th IEEE Symposium on Computers and Communications, pg. 686-693, Hammamet, Tunisia, July 2001. [10] V. Jacobson, C. Leres, and S. McCanne. The libpcap packet capture library. Lawrence Berkeley Laboratory, Berkeley, CA. Available at http://www.tcpdump.org. [11] IEEE. Portable operating system interface (posix) - part 1: System application programming interface (api) [c language]. ISO/IEC 9945-1, 1996. [12] Martin Hall and Dave Treadwel et al. Windows sockets 2 application programming interface, August 1997. Available at ftp://ftp.microsoft.com/. 9
