Integration of re active ad hoc routing daemon into Quagga routing suite for wireless ad hoc routers

Integration of Re-active Ad-hoc Routing Daemon into Quagga Routing Suite for Wireless Ad-Hoc Routers Quan LE-TRUNG School of CSE, International University at HCM city Wireless Embedded

Integration of Re-active Ad-hoc Routing Daemon into Quagga Routing Suite for Wireless Ad-Hoc Routers

Quan LE-TRUNG School of CSE, International University at HCM city

Wireless Embedded Internet group

Ho Chi Minh city, Vietnam

ltquan@hcmiu.edu.vn

Van-Hau PHAM Faculty of Computer Network and Communication University of Information Technology Vietnam National University HCMC

haupv@uit.edu.vn

Abstract—Research in Mobile Ad-hoc Networks (MANETs)

has been in-progress towards the real implementation of ad-hoc

routing protocols to be used in the real-time applications

However, existing approaches implement ad-hoc routing

protocols as standalone daemons to serve only pure routing

functionalities, leading to difficulties on the network

configuration once multiple routing protocols are running in the

network In this paper, we use another approach, in which

ad-hoc routing protocols are integrated into the Quagga routing

software suite, and aodvd, a re-active ad-hoc routing daemon, is

used for the real integration demonstration

Keywords—MANETs; ad-hoc routing; implementation;

daemons; protocols

I INTRODUCTION Mobile ad-hoc networks (MANETs) are subset of wireless

network that helps us to overcome the limited freedom of

mobility of infrastructure wireless network MANETs are

infrastructure-less, self-organized and seft-healing networks

that consists of mobile nodes, interconnected by multi-hop

wireless paths Due to these characteristics, MANETs are

suitable for instant applications without the need of any

network infrastructures, e.g., group communication between

soldiers in the battlefield, between rescuers in the disaster area,

between partners in a conference, just to list a few Currently,

we have been in progress to develop a smart building

application that uses 802.11 technology operated in low-power

mode for wireless communication, instead of the conventional

802.15.4 technology Our purpose is to achieve the energy

efficiency, while reducing the number of hops on collecting

sensor readings, and thus, increasing the performance (higher

data delivery ratio, shorter latency) of the system In our

application architecture, a MANET node, i.e., a wireless ad-hoc

router (WADR), takes an important role on the delivery of

sensor readings Fig 1 shows the mapping network

architecture (on the right) of our motivation example (on the

left) on a smart building application, in which a WADR takes

the role of a cluster head (in each room, or floor) for the local

data, code, and context repository, as well as for the

communication via 802.11 technology to disseminate sensor

readings back to the sink, and/or the management station

Many routing protocols have been proposed and

implementation versions were developed for routing purposes

in MANETs environment [6] However, these ad-hoc routing

protocols are normally implemented as standalone routing

daemons, e.g., aodvd [5], olsrd [7], to serve only for pure routing functionalities such as access control list, route map policy, redistribute mechanism In these existing routing approaches, there will be difficulties in the routing configuration once there is the need to run either multiple or

alternative routing protocols in the network In this paper, we

use an integrated approach, in which ad-hoc routing protocols are added into the Quagga routing software suite

[4], that provides TCP/IP based routing services with routing protocols support such as RIPv1, RIPv2, RIPng, OSPFv2, OSPFv3, IS-IS, BGP-4, BGP-4+, and IPv6 routing protocols

In particular, a re-active ad-hoc routing protocol, aodvd [5],

is used to illustrate for this integration in the Linux platforms Our work can be thought as a complement to

OLSRdq [8], in which a pro-active ad-hoc routing, olsrd [7], is

integrated into Quagga framework Fig 2 shows the Quagga

system architecture with the aodvd daemon integration

Fig 1 The network architecture of our smart building application

Normally, a legacy routing software, e.g., ripd [10], ospfd

[11], is made as a one process program which provides all of the routing protocol functionalities Quagga takes a different approach It is made from a collection of several daemons that work together to build the routing table Fig 2 also shows several protocol-specific routing daemons For changing the Linux kernel routing table and for redistribution of routes between different routing protocols, there is a kernel routing

table manager, i.e., zebra daemon It is easy to add a new

routing protocol daemon to the entire routing system without

affecting any other software Only the protocol daemons

associated with routing protocols in use are needed to run

Thus, user may run a specific daemon and send routing reports

to a central routing console The zebra daemon also tells

routing protocol daemons for interface status changing,

interface IP address update [4] This Quagga multi-process

architecture brings extensibility, modularity and

maintainability At the same time, it also brings many

configuration files and terminal interfaces, and Quagga

provides integrated user interface shell called vtysh, that

connects to each daemon with Unix/Linux domain socket and

then works as a proxy for user input [4] These features are

useful in solving the configuration difficulties once either

multiple or alternative routing protocols are running in the

network, and to be exploited in this paper for the integration of

a re-active ad-hoc routing daemon (aodvd)

Fig 2 Quagga system architecture with aodvd

This paper is organized as follows Section II shows in details

the architecture, the implementation, and the integration of

aodvd daemon into the Quagga routing software suite Section

III presents a real MANET testing case, and discusses on the

recorded results Section IV shows the related work Finally,

Section V ends this paper with conclusions and future work

II INTEGRATION OF AODVD INTO QUAGGA ROUTING SUITE

In this Section, we describe the main flows in the

implementation of aodvd routing daemon, which is integrated

into the Quagga infrastructure in the Linux platforms Details

of the synchronization between aodvd routing table with zebra

routing table, and the Linux kernel routing table, are also

shown

AODV [1] is a re-active (on-demand) ad-hoc routing

protocol which means the routing daemon must be triggered

for the route discovery process if a route to the destination host,

or destination network, is not available This characteristic

makes AODV different from traditional routing protocols

supported in Unix/Linux, which are pro-active (table-driven)

In our aodvd implementation, we have kept the same netfilter

hooks [9] as the original aodvd implementation [5], for packet

processing In particular, these netfilter hooks will capture

traversed packets, identify the packet types, and tell netfilter to

accept the packets, or queue the packets, for later processing at

user-space However, the tasks to update the kernel routing

table are transferred to zebra daemon [4] Fig 3 shows the flows of packet handling in our aodvd implementation

Incoming AODV control messages are accepted and queued for processing on a separated UDP socket using port

654 The message is processed by the aodv_socket module,

which checks the message type field and calls the correspondent functions to handle Outgoing AODV message

generated locally will also be caught by netfilter hook

NL_IP_LOCAL_OUT , queued by the kaodv-mod module, and received by the kaodv-queue module The kaodvd-queue module will return an accept verdict to the kaodv-netlink and the packet will then be caught by the netfilter hook

NL_IP_POST_ROUTING The packet has also updated the latest routing information and finally sent out [3]

Fig 3 Flows of packet handling in aodvd implementation

For handling data packet, if the destination of the packet (determined by its destination IP address) is the current host, the packet is a broadcast packet, or Internet gateway mode has been enabled and the packet is not a broadcast within the current subnet, the packet is accepted This means that the packet under these circumstances will be handled as usual by the operating system Otherwise, the packet should be forwarded, queued or dropped The internal routing table of

aodvd is used for checking whether an active route to the specified destination exists or not If such a route exists, the next hop of the packet is set and the packet is forwarded Otherwise, provided that the packet was generated locally, the

kaodv-netlink module for indirectly queuing the packet until

aodvd has decided on an action, and a route discovery is initiated If the packet was not generated locally, and no route was found, it is instead dropped and an error message is sent to the source of the packet Figs 4-5 show in details the packet

processing in kernel-space, and in user-space, respectively, of our aodvd implementation

When aodvd daemon updating its routing table, changes in

aodvd routing table are synchronized to the kernel routing table

via zebra call functions A Unix/Linux socket is initialized to

create a communication channel between aodvd and zebra

daemons Route updates are then sent to zebra daemon

(aodv_route) using zebra protocol Upon receiving route

updates, zebra will recalculate its routing tables (Routing

Information Base-RIB and Forwarding Information Base-FIB),

and zebra FIB is then fed to the kernel routing table The

user-space module of aodvd performs the kernel route update via

three modules: i) nl_send_add_route_msg() for adding a new

route to the kernel, ii) nl_send_del_route_msg() for deleting a

route from kernel, and iii) nl_send_no_route_found_msg() for

announcement of no route found These functions are called

when aodvd performs an update on its routing table to

synchronize aodvd routing table and the kernel routing table

With the integration with Quagga, aodvd will tell zebra

daemon for route updates (add, or update, or delete) This is

done by the module aodv_route(), which is defined in the file

zebra.c The destination information is stored in the data

structure prefix_ipv4 p, the next_hop, metric and interface

index are also used to generate the data structure zapi_ipv4 api

Finally, the module zapi_ipv4_route() is called to perform

appropriate actions (add route, or delete route)

Fig 4 Packet processing in kernel-space of aodvd implementation

Fig 5 Packet processing in user-space of aodvd implementation

The zebra protocol is a streaming protocol with a common

header, and is used by our aodvd daemon to communicate with

the zebra daemon The aodvd daemon can now request and

send information to and from the zebra daemon, such as

interface states, routing state, next-hop validation, and so on

The zebra daemon manages which route is installed into the

forwarding table with the kernel The zebra daemon is also the

core daemon of Quagga routing suite, it acts as an abstraction

layer between other user-defined routing daemons (aodvd in

our case), and the underlying Unix/Linux kernel That means,

it will send and receive routing requests from aodvd daemon;

add, delete and update the kernel routing table The data

structure zserv defined in zebra/zserv.h represents the zebra daemon It has sock parameter, which is the socket to communicate with aodvd daemon zebra daemon supports two

types of socket s– TCP socket and Unix/Linux socket

When zebra daemon starts, zebra_zserv_socket_init() is called to create zebra server socket, zebra_serv() function is called if zebra daemon support TCP socket, otherwise,

zebra_serv_un() function is called to create zebra Unix/Linux

domain socket with file descriptor at /var/run/zserv.api by default The aodvd daemon will connect to this Unix/Linux socket for communicating with the zebra daemon The zebra daemon has three buffer; *ibuf and *obuf for input/output buffer to client, and *wb for data waiting to be written to client Sub-thread *t_read is periodically reschedule to listen to aodvd daemon requests Once the zebra_client_read() function is

called, it reads messages from Unix/Linux socket, filters command types and performs the correspondent functions for handling the client requests In this paper, we focus on kernel

routing table update requests - ZEBRA_IPVX_ROUTE_ADD and ZEBRA_IPVX_ROUTE_DELETE (X stands for IPv4/v6)

Fig 6 shows the kernel route flow in our implementation

Fig 6 Kernel route update flow in zebra/Quagga framework

aodvd routing daemon operates and send route updates to the

zebra daemon by calling the function zapi_ipv4_route() (for IPv6 route, zapi_ipv6_route() is called instead) Route

information (with command for add or delete) is then sent to

the zebra socket, and the zclient_socket()/zclient_socket_un() function is called to establish the connection The zebra

daemon periodically listens to the socket Upon receiving a

zread_ipv4_add()/zread_ipv4_delete() is called to handle add

or delete request The zebra routing information base will then

be updated with client’s route requests by calling the

rib_add_ipv4_multipath() function for adding a new route, and

the rib_delete_ipv4() function for deleting a route After updating, the rib_process() function is called to process the

zebra Routing Information Base (RIB) At this stage,

Forwarding Information Base (FIB) is calculated The zebra

daemon feeds the FIB to the Linux kernel, which allows the IP

stack in the kernel to forward packets according to the routes

computed by the Quagga The kernel FIB is updated in an

OS-specific way, e.g., the netlink interface is used on Linux [3]

III DEMONSTRATION This Section presents a real test case with three physical

machines (laptops with attached or integrated WLAN cards

and operated in ad-hoc mode) to carry out the test on the aodvd

routing daemon operations such as the routing information and

message exchanging between the aodvd daemon and the zebra

daemon, and the Linux kernel routing table The test case also

comes with some movement action to mimic nodes mobility

Log files, screen dumps, data records are also collected for

troubleshooting the source code functionalities Fig 7 shows

the network architecture for this test case

L a p to p _ A

1 0 1 1 1 0 /2 4

L a p to p _ B

1 0 1 1 3 0 /2 4

L a p to p _ A

1 0 1 1 1 0 /2 4

L a p to p _ C

1 0 1 1 2 0 /2 4 L a p to p _ B

1 0 1 1 3 0 / 2 4

M o b ility

Fig 7 The network architecture for a real test case

Each laptop is installed with Linux Ubuntu 10.04 (kernel

2.6.32-38-generic) , and our developed adhoc-iu-0.1.tar.gz

package (including Quagga 0.99.22.1 source code [4], and our

developed aodvd routing daemon from AODV-UU 0.9.6 source

code [5]) The procedures in this test case are carried out as

follows:

• Step-1: Machine A and B are placed near each other

(within each other coverage range) Both machines

run aodvd and zebra daemons

• Step-2: Machine A pings machine B successfully, and

vice verse

• Step-3: Capture zebra routing table on both machine

A and B

• Step-4: Move machine B away from machine A’s

coverage range

• Step-5: Machine A and machine B is now

disconnected

• Step-6: Now place a machine C in the middle of A and B, and C is in both A and B’s coverage range

Run aodvd and zebra on C

The results are shown in Figs 8-16 In particular, Figs 8-10 show results for Steps 1-3, Fig 11 shows results for Steps 4-5, and Figs 12-16 show results for Step 6

Fig 8 aodvd route update status on machine A about machine B

Fig 9 Machine A zebra routing table with route update to machine B

Fig 10 The establishment of connection between machines A-B

Fig 11 Link break route update status on A once machine B moves away A

Fig 12 aodvd route update status on machine C (between A-B)

Fig 13 Machine C zebra routing table with route update to machines A-B

Fig 14 aodvd route update status on machine A once C is inserted

Fig 15 Machine A zebra routing table with route update to machines C-B

Fig 16 Re-establishment of connection between machines A-B via C

IV RELATED WORK

In this Section, we show a current review on existing implementation of MANET ad-hoc routing protocols, network testbeds, or semi-testbeds We do not consider other simulators and/or emulators used for testing and measuring MANET

A number of standalone ad-hoc routing protocols have been partly implemented and tested piconet [12] implements

an ad-hoc routing protocol, i.e., dynamic source routing (DSR) [6], for IP on Linux which will allow a dynamic network of mobile devices to be self-organizing and self-configuring It assumes that the network interface is up before installing the

DSR module kernel-aodv [13] is a loadable kernel module for

Linux It implements aodv routing between computers

equipped with WLAN devices Like piconet, kernel-aodv only

implements a single ad-hoc routing protocol However, in this package, it additionally adds multiple characteristics, e.g., supporting for multiple interfaces and internetworking with the

Internet awds [14] implements a layer 2 routing protocol for

wireless mesh networks, based on link-state routing, similar to the olsr routing For communicating with applications, the

awds daemon creates a virtual Ethernet interface (i.e., awds0) The device emulates an Ethernet interface, and thus all kinds of protocols that work with Ethernet can be used through virtual

Ethernet tunnel established over wireless link APE [15] is a

universal ad-hoc test-bed for protocol evaluation in realistic scenario, and APE distribution also comes pre-configured and contains tools for data gathering at both IP and Ethernet level Moreover, APE source code allows building customized APE distribution packages, with new scenarios, protocols, and much more, it also contains analysis tools for analysis of gathered data There are popular ad-hoc routing protocols integrated into

APE , including aodv, dsr, olsr However, each routing protocol

has to be configured separately and manually, and APE is platform-dependent with many assumptions about underlying software and hardware platforms In contrast, our work in this

paper overcomes these issues with the integration of a re-active

ad-hoc AODV routing daemon into the Quagga routing

software suite OLSRdq [8] is both the most similar and a complement to our work, in which a pro-active OLSR routing

protocol is used for the integration

V CONCLUSIONS This paper has shown part of our work in developing wireless ad-hoc routers to be used in smart building applications In

particular, a re-active ad-hoc routing daemon, i.e., aodvd, has

been integrated into the Quagga routing suite for the comfortable configuration of multiple routing protocols A real test case has also demonstrated the operations of our developed wireless ad-hoc routers

With this release adhoc-iu-0.1.tar.gz, our developed aodvd daemon does not support all zebra message types, only route

ADD, route UPDATE, and route DELETE messages The

aodvd daemon has also still not re-acted to interface status changing during its operation which is a drawback to be taken care of in later work New IPv6 address support is also an important module that the author should target The security and memory leak are missing in this release and yet to be fulfilled in future work As for testing purposes, proposed test

cases are simple and not cover many aspects in ad-hoc

environment – number of nodes, hidden node problem, signal

strength, internet gateway testing, re-distribution between

multiple routing protocols, are some other approaches to focus

on

ACKNOWLEDGMENT This research is funded by Vietnam National University

HoChiMinh City (VNU-HCM) under grant number

HS2014-28-01

REFERENCES [1] C Perkins, E Belding-Royer, and S Das, “Ad-hoc On-Demand

Distance Vector (AODV) Routing,” IETF Network Working Group,

RFC 3561, July 2003

[2] B Wiberg, “Porting AODV-UU Implementation to ns-2 and Enabling

Trace-based Simulation,” Master’s Thesis at Uppsala University,

Sweden, 2002

[3] K Wehrle, F Pählke, H Ritter, D Müller, and M Bechler, “The Linux® Networking Architecture: Design and Implementation of

Network Protocols in the Linux Kernel,” Prentice Hall, August 2004 [4] The Quagga Routing Software Suite, http://www.nongnu.org/quagga/ [5] The AODV-UU project, http://aodvuu.sourceforge.net/

[6] IETF MANETs charter, http://datatracker.ietf.org/wg/manet/charter/ [7] The olsrd Routing Daemon, http://www.olsr.org/

[8] OLSRdq – OLSR Daemon for Quagga, http://olsrdq.sourceforge.net/ [9] The netfilter Framework, http://www.netfilter.org/

[10] The IETF Routing Information Protocol (RIP) charter,

http://datatracker.ietf.org/wg/rip/charter/ [11] The IETF Open Shortest Path First (OSPF) charter,

http://datatracker.ietf.org/wg/ospf/charter/

[12] The piconet Project, http://sourceforge.net/projects/piconet/

[13] The kernel-aodv Project, http://w3.antd.nist.gov/wctg/aodv_kernel/ [14] The awds Project, http://awds.berlios.de/

[15] The APE Project, http://apetestbed.sourceforge.net/