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

The 2014 International Conference on Advanced Technologies for Communications (ATC'14) Integration of Re-active Ad-hoc Routing Daemon into Quagga Routing Suite for Wireless Ad-Hoc Routers Quan LE-TRUNG Van-Hau PHAM School of CSE, International University at HCM city Wireless Embedded Internet group Ho Chi Minh city, Vietnam ltquan@hcmiu.edu.vn Faculty of Computer Network and Communication University of Information Technology Vietnam National University HCMC haupv@uit.edu.vn 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 shows the Quagga system architecture with the aodvd daemon integration 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 adhoc 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; daemons; protocols ad-hoc routing; implementation; 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 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 Fig 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 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 Many routing protocols have been proposed and implementation versions were developed for routing purposes 978-1-4799-6956-2/14/$31.00 ©2014 IEEE 256 The 2014 International Conference on Advanced Technologies for Communications (ATC'14) table are transferred to zebra daemon [4] Fig shows the flows of packet handling in our aodvd implementation 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) 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 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 Fig 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 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 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 257 The 2014 International Conference on Advanced Technologies for Communications (ATC'14) 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 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 userspace 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) 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 shows the kernel route flow in our implementation Fig Packet processing in kernel-space of aodvd implementation Fig 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 route request, the correspondent functions 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, Fig 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 258 The 2014 International Conference on Advanced Technologies for Communications (ATC'14) 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 OSspecific way, e.g., the netlink interface is used on Linux [3] • 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 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 shows the network architecture for this test case Fig aodvd route update status on machine A about machine B M o b ility L a p to p _ A L a p to p _ B 1 1 /2 1 /2 L a p to p _ A L a p to p _ C 1 1 /2 1 /2 L a p to p _ B 1 /2 Fig Machine A zebra routing table with route update to machine B Fig 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 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 259 The 2014 International Conference on Advanced Technologies for Communications (ATC'14) 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 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 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 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 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 Fig 15 Machine A zebra routing table with route update to machines C-B 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 Fig 16 Re-establishment of connection between machines A-B via C 260 The 2014 International Conference on Advanced Technologies for Communications (ATC'14) [3] 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 [4] [5] [6] [7] [8] [9] [10] ACKNOWLEDGMENT This research is funded by Vietnam National University HoChiMinh City (VNU-HCM) under grant number HS201428-01 [11] REFERENCES [1] [2] [12] [13] [14] [15] C Perkins, E Belding-Royer, and S Das, “Ad-hoc On-Demand Distance Vector (AODV) Routing,” IETF Network Working Group, RFC 3561, July 2003 B Wiberg, “Porting AODV-UU Implementation to ns-2 and Enabling Trace-based Simulation,” Master’s Thesis at Uppsala University, Sweden, 2002 261 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 The Quagga Routing Software Suite, http://www.nongnu.org/quagga/ The AODV-UU project, http://aodvuu.sourceforge.net/ IETF MANETs charter, http://datatracker.ietf.org/wg/manet/charter/ The olsrd Routing Daemon, http://www.olsr.org/ OLSRdq – OLSR Daemon for Quagga, http://olsrdq.sourceforge.net/ The netfilter Framework, http://www.netfilter.org/ The IETF Routing Information Protocol (RIP) charter, http://datatracker.ietf.org/wg/rip/charter/ The IETF Open Shortest Path First (OSPF) charter, http://datatracker.ietf.org/wg/ospf/charter/ The piconet Project, http://sourceforge.net/projects/piconet/ The kernel-aodv Project, http://w3.antd.nist.gov/wctg/aodv_kernel/ The awds Project, http://awds.berlios.de/ The APE Project, http://apetestbed.sourceforge.net/  ... 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. .. 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. .. 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 Fig 15