DES-SERT: A Framework for Structured RoutingProtocol Implementation

Bastian Blywis Mesut Günes Felix Juraschek Philipp Schmidt Pardeep KumarDistributed Embedded SystemsInstitute of Computer Science

Freie Universität Berlin, Germany{blywis, guenes, jurasch, phils, pkumar}@inf.fu-berlin.de

Abstract—Routing is a general task, yet the implementationof routing protocols requires specific operating system relatedknowledge. The developer has to deal with particular kernelinternals that might have severe side effects. This is especially truefor reactive and hybrid protocols where routing and forwardingare heavily intermixed. Furthermore, novel routing protocolsrequire features that are not provided by current operatingsystems or have to be customized. Thus routing protocols formobile ad-hoc networks and wireless mesh networks are oftenstudied in simulation environments. However, simulations havelimitations that can result in conclusions that do not hold inreal networks. A framework for the implementation of routingprotocols in operating systems is required to enable real worldoriented research.

We introduce the DES Simple and Extensible Routing-Framework for Testbeds (DES-SERT). The framework supportsthe implementation and evaluation of routing protocols in atestbed environment. A structured protocol implementation isadvocated by transmitting data in extensions attached to packetsand by its pipeline based architecture. Several steps are elabo-rated how to derive an implementation from a routing protocolspecification.

Index Terms—Wireless Mesh Network (WMN), Testbed, Rout-ing, Framework

I. MOTIVATION

Routing including forwarding is a vital process to enablecommunication in a computer network, since it is responsiblefor the transport of data packets hop-by-hop from the sourceto the destination node. It is a major challenge especially intwo kinds of networks: mobile ad-hoc networks (MANET) andwireless mesh networks (WMN). These are suitable for manyapplication scenarios that require wireless communication.However, the wireless medium introduces new issues that haveto be addressed and demand for novel routing approaches.

Routing protocol specifications, like an Request For Com-ment (RFC), while containing message types and packetformats are unspecific on how to derive and structure animplementation. It is up to the developer to produce a suitablerepresentation. The developer should actually spend most ofhis time to implement the data gathering and evaluation so thatthe routing daemon can gain knowledge about the networktopology. This data is required by the forwarding procedure.However, forwarding as well as storing and caching of routinginformation are core services of any operating system (OS)and thus an integral part, that often cannot be detached or

manipulated in a straightforward way. The implementationof routing protocols for an OS requires special knowledgeabout particular internals. System level programming hasmany pitfalls and can interfere with other tasks of a kernel.Even simple protocol specifications can result in complex andunstructured implementations. Further on, many MANET andWMN specific routing approaches demand for features andmodular architectures that are not provided by the protocolstack of the OS.

Therefore, routing protocols for MANETs and WMNs areoften implemented and studied in simulations [1]. However,simulations abstract from complex scenarios which oftenresults in conclusions that cannot be transfered to real net-works [2]. Besides simulation based studies there are fewimplementations of routing protocols for an OS, like olsrd,AODV-UU, DYMO, and DSR-UU - even fewer are in aworking condition. For an overview of the currently availablerouting protocol implementations the reader is referred to ourtestbed site1.

The contribution of this paper is to introduce a frameworkwhich allows the implementation of reactive, proactive, andhybrid routing protocols in real networks. We present the DESSimple and Extensible Routing-Framework for Testbeds (DES-SERT) for testbed architectures like the DES-Testbed [3] atFreie Universität Berlin. Three central problems are addressed.First of all, it provides an abstraction from the operatingsystem kernel. The developer needs very limited OS domainspecific knowledge which enables to focus on the protocollogic instead of the interface. The uniform base of daemonsprovides increased comparability and fairness for experimentswhich is often neglected in studies. Secondly, DES-SERTintegrates into the experimentation process and architectureof a testbed. Routing daemons based on the framework canbe monitored, parametrized, and configured in each phaseand iteration of an experiment. This represents an applicationdomain that is not explicitely addressed by any related work.Thirdly, a structured protocol implementation is advocated bythe architecture and features of DES-SERT. Its methodologysupports the developer to create implementations using mod-ular components in short time and distinguishes DES-SERT

1Overview of WMN and MANET routing protocol implementations:http://www.des-testbed.net/routing

978-1-4244-5661-1/09/$26.00 ©2009 IEEE

Figure 1: Routing framework to kernel interface. DES-SERTprovides the routing daemon developer with access to thenetwork interfaces and the protocol stack of the kernel.

from other routing frameworks and suites.This paper is structured as follows. The DES-SERT frame-

work is introduced in Section II. Alternative routing frame-works and suites are discussed in Section III and the differ-ences to DES-SERT are elaborated. The paper ends with aconclusion in Section IV.

II. DES-SERT ROUTING FRAMEWORK

DES-SERT is a framework written as ANSI-C library withPython bindings currently in development. While generallyusable in many application scenarios, it is primarily usedin DES-Mesh, the multi-transceiver wireless mesh networktestbed part of the DES-Testbed. DES-SERT enables the im-plementation of proactive, reactive, and hybrid routing proto-cols via an underlay (layer 2.5 routing) in user space. Routingdaemons based on the framework are seamlessly integratedin the experimentation process of a testbed with experimentautomation and repetition to compare them quantitatively aswell as qualitatively. During experiments the parameters of therouting daemons can be altered at any time. All parameters aremade available over the network as well as via an interactiveshell. As logging is a vital part when executing and evaluatingexperiments, an unified interface is provided. The generalfunction set of DES-SERT is as follows:

• Transmission and reception of data• Serialization and de-serialization of data• Dynamic adding and modifying of extensions• Periodic execution of tasks• Logging• Runtime parametrization via an interactive shell• Network diagnosis support• SNMP integration via AgentX protocol

These functions are elaborated in the following.DES-SERT uses libpcap [4] to access all network interfaces,

which provides an operating system abstraction, e.g., fromthe Linux packet-sockets and the BSD Berkeley packet filterdevices. Thus, operating system independent receiving andsending of data is possible where a libpcap implementationis available. One POSIX thread is used for each monitoredphysical network interface. These helper threads, as depicted

0 8 16 24 31

destination address

source address

ethertype protocol

Ethernetheader

⎧⎪⎪⎪⎪⎨⎪⎪⎪⎪⎩

protocol version flags

ttl unused

header length payload length

⎫⎪⎪⎪⎪⎬⎪⎪⎪⎪⎭

DES-SERTheader

type ext. len. ext. data������������������������������

⎫⎪⎬⎪⎭

DES-SERTextension

...type ext. len. ext. data���������������

���������������

⎫⎪⎬⎪⎭

DES-SERTextension

payload data���������������

���������������payload

⎧⎪⎪⎪⎪⎨⎪⎪⎪⎪⎩

Figure 2: DES-SERT message format. The Ethernet headerrepresents layer 2. It overlaps with the layer 2.5 headerof the DES-SERT message. Two extensions are depicted inthis example carrying some piggybacked data. The payloadcontains an encapsulated Ethernet frame or raw IP datagramdepending on the usage of a TAP or TUN device.

in Figure 1, enable the forwarding of packets over the network.Routing protocol implementations can register callbacks withthe library to receive packets from selected interfaces. A TUNor TAP interface is used to send locally created packets intothe network; packets that are received via any monitoredinterface and are destined to this host are injected in theoperating system protocol stack. TAP interfaces can be usedfor layer 2.5 routing of Ethernet frames with layer 2 to layer 3address resolution by ARP. In contrast, TUN interfaces enableindividual layer 2 and 3 mappings and the routing of raw IPdatagrams. The physical network interfaces are still usable forany other data communication. DES-SERT relies on Ethernetas layer 2 protocol. The ethertype field in the framesflags all underlay packets. Currently we use the value of0x8042 that is listed as DEC unassigned by the IEEE. Whilelibpcap can introduce a delay penalty, it decouples all routingimplementations from the operating systems and is widelyavailable.

The underlay approach introduces some overhead due to anadditional header between the Ethernet and IP headers. Wenevertheless opted for this design as it has some advantages.The functions of routing and forwarding are intermixed formany novel routing protocols. Proactive routing daemons veryoften only execute a periodic route discovery and then modify

the routing table accordingly using some interface, like thenetlink interface in the Linux kernel. The forwarding featureis a part of the kernel’s protocol stack and usually heavilyoptimized. Reactive (and hybrid) protocols require that packetsfor which no routing information is available have to be stored.Thus packets either have to be stored in kernel space orpassed to a user space process. The “user” has to handlethe packet himself as most modern kernels do not considerreactive routing. Further on, many protocols require additionalrouting information to be stored in the forwarded IP datagram,e.g., for source routing or to update path metrics. This canbe accomplished either by a modified IP implementation oralternatively using a so called shim header; the layer 2.5in our case. Modifying or extending (or maybe replacing)IP is often not an option. This leaves a shim header as themost viable option. The adding, modification, and removal ofthis layer 2.5 header certainly can be done in kernel- as inuser space. As research and not high speed routing is thefocus of DES-SERT everything is done in user space. Allmanagement and data packets are handled the same and allowconclusions without considering kernel internals. We arguethat a fair evaluation of the performance and behavior ofproactive and reactive protocols is otherwise hardly possible.Additionally, ease of deployment on a hybrid testbed and/oron computers of probands for MANET studies with possiblymany different kernel versions can only be achieved this way.Adapting a kernel module to updated versions of the Linuxkernel’s protocol stack alone is a “Sisyphean task” due to therapid development in the last years.

DES-SERT is structured into several modules that imple-ment particular function sets. The packet manipulation moduleis used to serialize data and to deserialize packets. It allocatesand frees the needed memory, encapsulates and decapsulatesframes and IP datagrams. Most memory management is doneby DES-SERT and requires no actions by the developer andthus no OS specific knowledge. Where simple manual actionsare required, appropriate constructor and destructor functionsare provided.

The manipulation and adding of extensions is a core feature.Extensions are typed serialized data structures and a powerfultool. The overall packet structure is shown in Figure 2. ADES-SERT message is always the service data unit (SDU) ofan Ethernet frame. The message, the layer 2.5 protocol dataunit (PDU), consists of the DES-SERT header and severalextensions. Routing protocol structures can be defined andplaced inside an extension. Each field or even a flag could usea single extension if the overhead is negligible, e.g., for simpleprototyping. Extensions can be added and removed on demandon a per hop basis. Thus, data can be easily piggybackedwhich is useful to propagate information about the network,like link qualities, energy consumption, or the traveled path.Error checking can be implemented in a similar way by addingan extension that carries a checksum. DES-SERT supportsmultiple extensions of the same type. This allows to reduce theoverhead as multiple independent data parts can be cumulatedand sent together. For example, multiple vectors of a distance

vector based routing protocol could be propagated in a singlepacket by appending extensions.

A command line interface (CLI) with Cisco IOS like syntaxis provided via libcli [5]. Besides the user interaction withtelnet or netcat, the CLI is also used to parse and eval-uate the routing daemons configuration file. The configurationconsists of several commands that the user would normallyenter in the shell. Developers of a routing daemon can registernew commands to read and write their parameters. Registeredparameters will also be automatically exported via the AgentXprotocol [6] in future versions of DES-SERT. SNMP agentscan then provide these as managed objects that are accessibleby a management instance. In the case of the DES-Meshthe central Testbed Management System (DES-TBMS) canexecute experiment scripts that configure particular parametersets on demand.

Timed task execution, e.g., for route maintenance, is sup-ported by registering callback functions. Single or periodicexecution are available. As last, DES-SERT offers a unifiedlogging feature with level support. Messages can be sent tothe syslog daemon, standard output, logfile, and a ring bufferthat can be read via the CLI. A relational database connectoris currently in planning.

A. Methodology

DES-SERT supports callback functions for several events.Most importantly, callback functions are used to handle pack-ets that are received from the network or enter the daemonvia a TUN or TAP interface from the host side. The data canbe dropped, sent over the underlay, or injected in the host’sprotocol stack by using the API of DES-SERT. All receiveand transmit callback functions have a priority to determinetheir order. Thus, complex handling routines can be split intosmaller parts. DES-SERT advocates to structure the handlingof packets into logical stages that are connected in a pipeline.The stages can order the further handling of a packet, drop it,or request the buffer for the packet to be enlarged via particularreturn values. If the buffer has to be enlarged, the callback ofthe particular stage is called again after the memory has beenreallocated.

Extensions and priorized callback functions have a synergyeffect. Each pipeline stage can implement the handling ofa particular extension. The pipeline can be defined, regard-less whether a received packet contains the correspondingextensions. If a stage has no work to do as the extension ismissing, it signals to continue the packet handling process.This approach can reduce the size and complexity for lesserror prone and easier to maintain implementations. It leadsto a division of the routing logic into units where each partimplements independent functionality. We call this approachExtension-Pipelining.

B. Structured Protocol Implementation

Routing protocol specifications are usally very general andunspecific regarding how an implementation can be derived.Yet the services (neighbor discovery, error checking, etc.)

and format of messages are described in detail. When imple-menting a specification with DES-SERT, the implementationprocess should proceed according to the following generalsteps.

First of all, the service procedures (like sending or eval-uating hello messages) that handle the receiving (rx) andtransmitting (tx) should be split in two groups. Most if notall2 rx procedures should have a corresponding tx procedure inthe other group. These will eventually result in two pipelines.Each service procedure pair has to be considered. A unique idis assigned to the corresponding message of the service pro-cedure pair. Now the data format utilized to sent, respectivelyto parse received data, has to be mapped to a representationas extensions.

For the transmitting side, a tx function is implemented thatprovides the required data for this service. An empty messageis allocated and initalized accordingly. The provided data isserialized into the data portion of a message extension whosetype is set to the unique id. This tx function could be calledonce data arrives via a TUN/TAP interface by registering itas tx callback or periodically by using DES-SERT’s timerinterface.

For the receiving side, an rx callback function has to bedeveloped that will be registered to handle packets from theunderlay. The function scans the DES-SERT message for anextension with the particular type. If it is found, the data isretrieved, parsed, and handled. Normally the rx callback willthen exit and signal via a return code to continue the handlingof the message.

In the last step of the implementation, after all serviceprocedures are implemented, the order of the callbacks hasto be defined. The discussed steps to implement a routingprotocol specification are very general but should be appli-cable in most situations. We define one metric to distinguishparticular implementations on their usage of extensions: thegranularity of a service procedure. The granularity achievedby abiding to the elaborated steps is coarse; one serviceprocedure message corresponds to exactly one extension type.With a higher degree of granularity, a service procedure usesmultiple different extension types for its data. For example,such a scenario can arise when the data of a service messagecontains optional elements. Coarse granularity generally hasa lower overhead than fine granularity. The order of stages,respectively callbacks, is interdependent with the granularity.When semantically related data is split into multiple extensionsthey usually have to be evaluated in a particular order. DES-SERT advocates to start with a coarse grained implementation.Finer grained daemons can be derived in iterative steps ifrequired.

The ordering of the pipeline stages, respectively the call-backs, based on the granularity is only one aspect. Stagesthat belong to different service procedures also have to beconsidered. Their order is not related to the discussed gran-

2In the following we will assume each rx function to have a correspondingtx function.

ularity. The pipeline of stages is usually implicitely definedin the routing protocol specification, e.g., error checking hasto be done before evaluating a packet. Imprecise routingprotocol specifications can be revealed when the derived orderis ambiguous.

C. Application of DES-SERT

Due to the extension mechanism DES-SERT is applicablefor the implementation of virtually any proactive, reactive,or hybrid routing protocol. Some scenarios especially fitthe framework. Routing protocols that use multiple differentheader formats or require extensive piggybacking of dataobviously profit from DES-SERT. For example, we madesome very promising experiences when we implemented theAnt Routing Algorithm (ARA) [7] protocol. MPLS [8] likeprotocols are implemented with very little effort. The shimheader can be realized as an extension carrying the labelstacks.

Multi-protocol routing also becomes simple to implement.For example the Zone Routing Protocol [9] can be imple-mented by using a proactive protocol for the zone and areactive one for nodes outside. Using the pipeline mechanisma received packet is first handled by the stages of the proactiveprotocol. If the packet is forwarded, it is removed fromthe pipeline otherwise the stages of the reactive protocolare executed. Thus already existing protocol implementationsusing DES-SERT can be chained and no special adaptation ofthe protocols is required.

Using extensions it is possible to provide often used func-tionality in a standard library, e.g., a trace extension allows touse path tracing in any protocol. With this approach we hopeto minimize individual implementations in code size whileat the same time increasing the maintainability leading to ahigher number of implementations in working condition forreal world based research.

Besides ARA we already have an implementation of the Bet-ter Approach to Mobile Ad-hoc Networking (B.A.T.M.A.N.)protocol and are working on AODV, DYMO, and OLSR whichwe will then study in several experiments for the applicationin WMNs.

D. Performance Considerations

User space routing is often times considered to have asignificant overhead due to many context switches. To showthat the framework architecture is not a severe bottleneck, wedid some experiments. Two mesh routers of the DES-Testbedwere connected with a crossover Ethernet cable. This allowsus to create a worst case scenario. Latency measurementswere executed with different sized packets and 1000 packetseach using ping. TCP throughput was measured with iperfover a minute with 20 repetitions. To get a better estimatewe compared the pure kernel forwarding with two protocolimplementations: a very simple gossiping [10] and the aforementioned ARA serving as a “heavy weight” example. Theresults are shown in Figure 3. While the effect of the contextswitches is visible, it can be neglected in most scenarios. The

(a) Round Trip Time as a function of packet size (b) Throughput in the three considered cases to estimate the limitation

Figure 3: Measurements with two mesh routers connected via Ethernet. To measure the effect of user space routing pure kernelforwarding, a very simple protocol (gossiping), and a complex protocol (ARA) were considered.

overhead in round trip time is within the magnitude that never-theless can be expected in multi-hop wireless communicationconsidering for example media contention and OS scheduling.The maximum achievable throughput on the other hand isreduced by up to 27 MBits/s. Considering the theoretical netthroughput that can be achieved with IEEE 802.11g saturationhas not yet been reached. Of course both of these issues can berelieved by using a faster hardware. User space routing withDES-SERT should not result in a bottleneck in its commonapplication scenarios.

III. RELATED WORK

In this section, we review existing routing frameworksand compare them to DES-SERT based on their applicationdomain and feature set. Several sophisticated routing suitesand frameworks have been developed, each for particularapplication scenarios. In the following we focus on the dif-ferences to DES-SERT.

Quagga [11] is a routing suite to implement user space rout-ing daemons. A core daemon serves as kernel abstraction andprovides an API for clients that implement the routing logic.Several implementations are available to be used in productionenvironments, e.g., OSPF, RIP, and BGP. Quagga’s focus ison proactive protocol implementation and route redistribution.The implementation of reactive protocols is not supportedand each routing protocol is implemented individually usingthe features that are provided by the zebra daemon. Thisdaemon acts as abstraction to the kernel and provides commonfunctions to access the kernel’s routing table. The Bird InternetRouting Daemon and XORP are similar suites and basicallysupport the same protocols but there are several differences intheir software architectures.

The x-kernel [12] initially started as a stand alone oper-ating system kernel and eventually evolved into a portableframework. While virtually any network protocol can beimplemented in the object-based framework, the major focus isnetwork subsystem modularization and performance improve-ment. Morpheus is a special-purpose programming languageto implement communication protocols that is related to the

x-kernel. Unfortunately, no compiler seems to exist for thisvisual and object oriented language.

The Click Modular Router [13] provides a visual flow-basedlanguage and a declarative script language. So called elementsprovide the user with the needed functionality to create acustom router. The main focus of Click is quality of serviceand traffic shaping. Nevertheless, routing protocol implemen-tation is possible to some degree. AODV, DSR, DSDV, TORA,and ZRP implementations have been developed although someauthors admit, that not all functionality specified in RFCs isintuitively represented as an element. DES-SERT’s pipeliningis similar to the chaining of elements of click but has severalsynergy effects due to the extension mechanism. Click isavailable in several variants: as user space program, as kernelmodule, and a version for ns-2. The kernel module requires thekernel to be patched which unfortunately makes deploymentmore complex. Click provides a rich library of elements yetwith less focus on storing and multiplexing data in packetsthan DES-SERT.

The ad-hoc support library (ASL) [14] provides a sharedlibrary to implement user space routing daemons combinedwith a kernel module. ASL basically provides support for theimplementation of reactive protocols but limited kernel ab-straction as the kernel module has to be customized dependingon each particular protocol.

GEA [15] provides a Generic Event-based API for routingprotocols. Providing the same protocol implementation foroperating systems and a simulation environment (ns-2) wasthe focus of development. Abstraction of the routing protocollogic from the underlying system is the main goal of GEAby providing a minimal set of required functions: transmittingand receiving data, timer functionality, and concurrent waitingfor I/O with timeouts.

The Mesh Connectivity Layer (MCL) [16] developed byMicrosoft Research is a simple driver that provides a virtualnetwork adaptor that acts as a gateway to an underlay network.

Implementations for ns-2 network simulation environmentcan also be used in an OS [17]. As the implementation ina simulation environment differs (e.g. socket buffer structure,

packet format, kernel-user-space interfaces) from that of na-tive ones, a custom conversion module is required for eachprotocol.

DES-SERT is focused on structured protocol implementa-tion and testbed integration. It combines the features of thediscussed frameworks and suites and benefits from the synergyeffects while supporting the implementation of proactive, reac-tive and hybrid protocols. DES-SERT is not focused on high-speed, proactive Internet backbone routing as, e.g, Quagga.In the testbed context ease of deployment, maintainance,configuration, and troubleshooting have a higher priority. Fewframeworks and suites advocate and support a similar struc-tured and modular protocol implementation. We believe therelatively low number of WMN and MANET routing protocolimplementations that are in a working condition is at leastpartially due to this fact. DES-SERT follows the approach tobe simple yet extensible, easy to use, and dozens of routingdaemons in a testbed easy to manage and monitor.

IV. CONCLUSION AND FUTURE WORK

Routing is an important task but the implementation ofprotocols often demands domain specific knowledge aboutoperating systems. For the research of routing protocols aframework that enables the implementation without regard tokernel internals and focus on the routing logic is required. Weintroduced the DES-SERT library, an abstraction frameworkfor the implementation of proactive, reactive, and hybridrouting protocols. Its architecture and features were discussed.Daemons based on the framework integrate in testbed environ-ments and support the experimentation process. DES-SERTadvocates a structured protocol implementation based on itscallback and extension feature. Extension-Pipelining leads toa clear design and makes routing protocols comparable andcombinable. Extensions allow the implementation of particularservices that can be reused by any routing protocol. Alternativeframeworks and suites for routing protocol implementationhave been introduced and discussed. Our future work willinclude a detailed comparison of DES-SERT and the men-tioned routing frameworks as well as a study of the protocolsimplemented by us. We will try to evaluate the applicabilityof the frameworks in particular scenarios.

DES-SERT is currently scheduled to be submitted for re-view to be included in the Debian GNU/Linux distribution. Allrouting protocol implementations will also be made availablefor the public this way. It is our goal to provide a solid toolfor research and teaching.

ACKNOWLEDGEMENTS

This publication has been partially sponsored by the Opti-mization driven Multi-Hop Network Design and Experimenta-tion (OPNEX) project of the European Union, FP7 - INFO -ICT - 224218.

REFERENCES

[1] S. Kurkowski, T. Camp, and M. Colagrosso, “MANET simulationstudies: the incredibles,” SIGMOBILE Mob. Comput. Commun. Rev.,vol. 9, no. 4, pp. 50–61, 2005.

[2] D. Cavin, Y. Sasson, and A. Schiper, “On the accuracy of MANETsimulators,” in POMC ’02: Proceedings of the second ACM internationalworkshop on Principles of mobile computing. New York, NY, USA:ACM Press, 2002, pp. 38–43.

[3] M. Günes, B. Blywis, and F. Juraschek, “Concept and design of thehybrid distributed embedded systems testbed,” Freie Universität Berlin,Tech. Rep. TR-B-08-10, 2008.

[4] “tcpdump/libpcap.” [Online]. Available: http://www.tcpdump.org/[5] D. Parrish and B. O’Dea, “libcli.” [Online]. Available: http:

//code.google.com/p/libcli/[6] M. Daniele, B. Wijnen, M. Ellison, and D. Francisco, “Agent Extensi-

bility (AgentX) Protocol Version 1,” RFC 2741 (Draft Standard), Jan.2000.

[7] M. Günes, U. Sorges, and I. Bouazizi, “ARA - The Ant-ColonyBased Routing Algorithm for MANETs,” in Proceedings of the 2002ICPP Workshop on Ad Hoc Networks (IWAHN 2002), S. Olariu, Ed.,vol. 00. Los Alamitos, CA, USA: IEEE Computer Society, August2002, Routing, pp. 79–85.

[8] E. Rosen, A. Viswanathan, and R. Callon, “Multiprotocol Label Switch-ing Architecture,” RFC 3031 (Proposed Standard), Jan. 2001.

[9] Z. Haas, “A new routing protocol for the reconfigurable wirelessnetworks,” 1997, pp. 562–566.

[10] Z. J. Haas, J. Y. Halpern, and E. L. Li, “Gossip-based ad hoc routing.”in Proceedings IEEE INFOCOM 2002. New York, USA: IEEE, June23-27 2002.

[11] “Quagga routing software suite.” [Online]. Available: http://www.quagga.net/

[12] N. C. Hutchinson and L. L. Peterson, “The x-kernel: An architecturefor implementing network protocols,” IEEE Transactions on SoftwareEngineering, vol. 17, pp. 64–76, 1991.

[13] E. Kohler, R. Morris, B. Chen, J. Jannotti, and M. F. Kaashoek, “Theclick modular router,” ACM Transactions on Computer Systems, vol. 18,no. 3, pp. 263–297, August 2000.

[14] V. Kawadia, Y. Zhang, and B. Gupta, “System services for ad-hocrouting: Architecture, implementation and experiences,” in MobiSys ’03:Proceedings of the 1st international conference on Mobile systems,applications and services. New York, NY, USA: ACM, 2003, pp.99–112.

[15] A. Herms and D. Mahrenholz, “Gea: A method for implementingand testing of event-driven protocols,” in Proceedings of the First Int.Workshop on Wireless Mesh Networks (MeshNets), 2005.

[16] R. Draves, J. Padhye, and B. Zill, “The architecture of the link qualitysource routing protocol.” Microsoft Research, Tech. Rep. MSR-TR-2004-57, 2004.

[17] A. K. Saha, K. A. To, S. Palchaudhuri, S. Du, and D. B. Johnson,“Physical implementation and evaluation of ad hoc network routingprotocols using unmodified simulation models,” in Proceedings of theACM SIGCOMM Asia Workshop, April 2005.