lcee 2013 - experimenting with watchdog implementation on a real-life ad hoc network - monitoring...

Chapter 21Experimenting with WatchdogImplementation on a Real-Life Ad hocNetwork: Monitoring Selfish Behavior

Tirthankar Ghosh and Tian Hou

Abstract A watchdog monitors neighboring nodes in a multihop wireless ad-hocnetwork to determine whether they are forwarding packets or not. In this paper wehave presented detailed study of our experiments with implementing watchdogfunctionality on a real-life ad-hoc network testbed. Experiments were conductedon our university campus to test the functionality under different networktopologies.

21.1 Introduction

The concept of watchdog was first proposed by Marti et al. [1]. They implementedthe function on Dynamic Source Routing (DSR) [2] protocol, where the nodes usesource routing to send packets. Monitoring neighboring nodes in a source routingenvironment is easier as the nodes have the entire route in the header structure, andknow all hops in the path. Over the course of several years many studies [3–5]have used the watchdog concept in monitoring neighboring nodes, but they havebeen limited mostly to simulation-based analysis.

There are two phases of neighbor monitoring in a multihop ad-hoc networkscenario: monitoring during the control phase, and monitoring during the datatransfer phase. During the first phase, watchdog monitors whether the neighboring

T. Ghosh (&) � T. HouDepartment of Computer Science and Information Technology,St. Cloud State University, St. Cloud MN, USAe-mail: [email protected]

T. Houe-mail: [email protected]

K. Elleithy and T. Sobh (eds.), Innovations and Advances in Computer, Information,Systems Sciences, and Engineering, Lecture Notes in Electrical Engineering 152,DOI: 10.1007/978-1-4614-3535-8_21, � Springer Science+Business Media New York 2013

255

nodes are forwarding routing control messages, while in the second phase moni-toring is done to ensure that the nodes in the path are forwarding data as agreed. Inour study, we have implemented watchdog to monitor neighbors during the controlphase on top of the Ad-Hoc On-Demand Distance Vector (AODV) [6] routingprotocol.

The rest of the paper is organized as follows. Section 21.2 discusses design andimplementation of watchdog, followed by detailed discussion on experimentalsetup and tests in Sect. 21.3. Finally, Sect. 21.4 concludes the paper and highlightssome of the future work.

21.2 Design and Implementation

21.2.1 Watchdog Design

Selfish behavior of a node in a multihop ad-hoc network results from its unwill-ingness to forward packets to save its battery power. As normal network operationdepends on mutual trust among nodes in forwarding packets, selfish behaviorresults in disruption of the network operation. There are two broad approaches toensure that nodes are forwarding packets as agreed: the first approach deals withproviding incentives to nodes [3, 7, 8, 9], and the second approach is based onmonitoring neighboring nodes [1, 3, 5]. Both approaches have their relative prosand cons. In the first approach a game theoretic strategy needs to be designed andimplemented where the incentives outweigh nodes’ selfish intention. On the otherhand, the second approach is difficult to implement and consumes significantcomputing resources especially on power-intensive applications. Typically,watchdog is based on the second approach where each node monitors its one-hopneighbors. Due to the resource-intensive nature of watchdog, our approach to theproblem is to have a dedicated watchdog in the network which will be imple-mented as a mobile agent. The watchdog will move around and monitor nodeswhether they are forwarding packets. This study is conducted only with imple-menting watchdog to monitor control packets, we are working towards theimplementation for monitoring data packets which will be presented in future.

The essential idea behind the design of watchdog is that by recording the IPaddress of previous hop from which RREQs were received by a neighboring node,watchdog determines if the neighboring node has forwarded the packets. SinceAODV only stores the originator IP address and the destination IP address, thestructure of AODV needs to be modified to include the IP address that is recordedwhen transmitting control packets. To fully achieve the goal of knowing if aparticular neighboring node has forwarded RREQs, the watchdog utilizes thefollowing functionalities of AODV:

• Buffering a record for every RREQ broadcasted by any node for a time intervalthat is defined for path discovery

256 T. Ghosh and T. Hou

• Identifying each broadcasted RREQ packet with the originator IP address andthe RREQ ID

• Converting IP addresses from a network byte order to a string in dotted decimalformat by which information about a node associated with receiving and for-warding RREQ packets can be learnt.

Overall, the watchdog traces which neighboring node has assisted in dissemi-nating RREQs during route discovery. So the information obtained through thismechanism can be used to determine which node has not participated in thetransmission of route request packets in the networks.

21.2.2 Implementation

We have used AODV-UU [10], Uppsala University implementation of AODVrouting protocol, to implement our watchdog functionality. Figure 21.1 belowshow the flowchart to illustrate the process when a RREQ is received by watchdog.

The existing RREQ structure is modified to include a new field calledhold_addr, which is used to hold the address of previous hop of RREQ during pathdiscovery. The value of hold_addr is updated before a RREQ is forwarded to thenext hop. This information stored by hold_addr is key to watchdog operation as ittells watchdog the ID of the previous node from which RREQ is received.

In AODV, any node acts on only the first RREQ and ignores any subsequentRREQs with the same RREQ ID. In the process of Fig. 21.1, instead of ignoringthe duplicated RREQs, watchdog does the address checking. When a RREQ isreceived by watchdog, it checks if it has a record for the RREQ in its buffer. If itdoes not have one, then it determines if the previous hop of the RREQ is theoriginator by comparing the IP address of the previous hop of the RREQ with theIP address of originator in the RREQ. If the RREQ is not directly transmitted fromthe originator meaning that the previous hop of the RREQ is an intermediate node,which has retransmitted the packet, then watchdog prints out information telling ithas seen that the forwarding node receiving the RREQ from its predecessortransmitted the RREQ. The original RREQ module uses function ip_to_str () toconvert IP addresses from a network byte order to a string in dots-and-numberformat when logging AODV information. Watchdog utilizes this feature, so it cantell from which IP a forwarding node receives a control packet and re-forwards itto its neighbors. Notice that all AODV message types including RREQ arereceived via User Datagram Protocol (UDP) and that normal IP header processingapplies. This enables the IP address of previous hop of RREQ as a parameter to beused directly in the function rreq_process () when processing control packets.

On the other hand, if a record is found for the RREQ, watchdog checks theRREQ record timer since each RREQ is buffered for a PATH_DISCOV-ERY_TIME interval. If the timer is not expired, and the RREQ is transmitted by

21 Experimenting with Watchdog Implementation 257

an intermediate node, watchdog then prints out information saying that it hasobserved that the forwarding node receiving the RREQ from its previous hoptransmitted the packet.

Fig. 21.1 Flowchart illustrating watchdog function in a node


21.3 Experimental Setup and Test

21.3.1 Experimental Setup

Our testbed was built with four HP Evo N600c laptops running Fedora 7 withkernel version 2.6.21-1, equipped with Orinoco Gold b/g wireless cards.The wireless card drivers were set up in ad-hoc mode using 802.11b standard. Thetransmission power of each card was reduced to 2 mW during each run of theexperiments. This was done to scale down the area of coverage. We selectedAODV-UU [10], the AODV implementation developed by Uppsala University,Sweden, as our routing protocol. MadWiFi driver was used for the wireless cards.

Three types of scenarios were developed for the test. To illustrate the test foreach scenario, a corresponding network topology created for the scenario isexplained with figure. The sample output generated for each scenario during theexecution of each test is presented with interpretation for verification of watchdogoperation. For simplicity, the following capital letters are used with the networksetup to represent the name of each node deployed in networks:

S: source nodeA, B: any intermediate nodeD: destination nodeW: node running watchdog

Fig. 21.2 Scenario 1: allnodes in one another’stransmission range


21.3.2 Tests

Scenario 1. The first scenario developed for the test is that all ad hoc nodesdeployed in the network are within each other’s transmission range. Figure 21.2illustrates the network topology.

As in Fig. 21.2, the source S broadcasted RREQs containing destination IPaddress 192.168.1.30 to its neighbor W, A and D for a path discovery. Since all thenodes can see one another, W and A retransmitted the packets as they checked theywere not the destination, however, S, A, and D did not re-process the duplicatedRREQs, because AODV nodes act on only the first RREQ with the same RREQID. Thus, A is the only node that W has seen forwarding the RREQ. There are twolog files (aodvd.log and aodvd.rtlog) that were generated for watchdog whenrunning the test for scenario 1. The following shows a portion of AODV logs,which provides information for verification for the watchdog operation.

Let us look at the process that takes place when a RREQ is received by thewatchdog written to/var/log/aodvd.log.


In the debug output of the process above that contains the RREQ informationone can see that it contains the hop count, the RREQ ID, the originator anddestination IP addresses, and the originator and destination sequence numbers(highlighted in red). The first entry in the output tells the RREQ is the first timereceived by watchdog from IP 192.168.1.10 (the previous hop of the RREQ). Thefollowing entry indicates that watchdog inserts a record for the RREQ. The secondentry from the bottom in the output illustrates that watchdog receives a duplicatedRREQ and then drops the packet, while the last entry (highlighted in blue)describes that A (192.168.1.20) forwarded the RREQ (src=192.168.1.10, rre-q_id=2) for S (192.168.1.10).

Second is an example of the AODV internal routing table generated forwatchdog, which is corresponding to the RREQ process illustrated in debug outputpreviously.

As shown in the routing table in Table 21.1 above, watchdog establishes onehop with every other node accordingly since all nodes are within each other’stransmission range.

Scenario 2. In the second scenario, the network topology was developed withthree hops. As illustrated in Fig. 21.3, S and A were placed out of each other’stransmission range with W in the middle. Similarly, W and D were deployed out ofeach other’s transmission range, and A was placed in between.

In Fig. 21.3, W monitors its one-hop neighbor node A as S sends out RREQsfor seeking a route to D. In addition, W also serves as a forwarding hop in theprocess of the route discovery. As expected, W has observed that A retransmittedthe RREQs to its neighbors. A sample log including debug outputs and routingtable printouts drawn from aodvd.log and aodvd.rtlog files for scenario 2 is pre-sented in below.

Table 21.1 Routing table for scenario 1

Destination Next hop HC St. Seqno Expire Iface

192.168.1.20 192.168.1.20 1 VAL 1 2431 ath0192.168.1.10 192.168.1.10 1 VAL 6 4950 ath0192.168.1.10 192.168.1.30 1 VAL 1 6135 ath0


As shown in the debug output above, the first two entries illustrate thatwatchdog receives a new RREQ with ID ‘‘81’’ from IP 192.168.1.10 and buffers arecord for the RREQ. The next three entries contain information of the RREQ(highlighted in red). Entry 6 and 7 indicate that the RREQ is forwarded and sentthrough a socket. The eighth entry indicates that a duplicated RREQ is receivedfrom A (192.168.1.20) and the last entry (highlighted in blue) tells that A for-warded the RREQ (src=192.168.1.10, rreq_id=81) for W (192.168.1.100).

The output above is a look at the process of RREP corresponding to the processillustrated for the RREQ previously. The first entry indicates a RREP is received.

Fig. 21.3 Scenario 2: watchdog in 2-hop from destination


The second entry shows the RREP is transmitted by A (192.168.1.20). Entry 3, 4,and 5 reveal the information of the RREP. Entry 6 indicates a forward route isadded. Entry 7 and 8 tell that RREP is forwarded and sent in the AODV messageto S (192.168.1.10). Last entry adds precursor S to the route entry (192.168.1.30).

Table 21.2 shows the routing table of watchdog under scenario 2. As shown inthe table, W (192.168.1.100) establishes two hops to D (192.168.1.30); whereas itcreates one hop to both A (192.168.1.20) and S (192.168.1.10) respectively.

Scenario 3. In this last scenario, the network topology was developed for twohops. As illustrated in Fig. 21.4, S and W were placed out of each other’s trans-mission range with A and B in the middle. Due to the limited number of mobilelaptops, W was not deployed as the destination node in the network. Instead, itserved as a forwarding node again. The reason to design such network topology isthat W can monitor multiple neighbors in the network (while lacking of available


Destination Next hop HC St. Seqno Expire Iface Precursor

192.168.1.30 192.168.1.20 2 VAL 24 5367 ath0 192.168.1.10192.168.1.20 192.168.1.20 1 VAL 1 2366 ath0192.168.1.10 192.168.1.10 1 VAL 89 4879 ath0


ad hoc devices, which is only in this case). To test the watchdog operation in suchscenario, we simply pinged an unreachable IP address i.e., 192.168.1.200.

The following debug output and routing table printout provide information thatverifies the witness of watchdog on A and B in the transmission of RREQs.

Fig. 21.4 Scenario 3: watchdog as destination


As shown in the context of the output above, the first and last two entries(highlighted in blue) need to be discussed. The first entry indicates that a newRREQ is received by watchdog from B (192.168.1.30) and the second entry tellsthat B forwarded the RREQ for S (192.168.1.10); whereas, the second last entryillustrates that the watchdog receives a duplicated RREQ with the same ID from A(192.168.1.20) and the last entry depicts that A forwarded the RREQ for S(192.168.1.10).

For other entries, the messages are interpreted in order as follows: The thirdentry buffers a record for the RREQ. Entry 4, 5, and 6 display the RREQ infor-mation (highlighted in red). Entry 7 updates the routing table. Entry 8 adds theforward route. Entry 9 and 10 indicate the RREQ is forwarded and sent in AODVmessage.

The routing table in Table 21.3 above illustrates the establishment of hops ofwatchdog with other nodes. As shown in the routing table, watchdog establishesone hop with both A and B and two hops with S.


Destination Next hop HC St. Seqno Expire Iface

192.168.1.30 192.168.1.30 1 VAL 1 2759 ath0192.168.1.10 192.168.1.30 2 VAL 2 48 ath0192.168.1.20 192.168.1.20 1 VAL 1 2760 ath0


21.4 Conclusion and Future Work

In this experimental study, we have implemented watchdog on a real-life wirelessmultihop ad-hoc network testbed, and conducted experiments with different net-work topologies to test its functionality. The implementation was done on Ad-HocOn-Demand Distance Vector (AODV) routing protocol.

The study discussed here has been conducted only with implementing watchdogto monitor control packets, we are working towards the implementation formonitoring data packets which will be presented in future. Also, watchdog needsto be implemented on all nodes, and a detailed study needs to be conducted tomonitor the energy utilization of the nodes under such condition.

References

1. Marti S, Giuli TJ, Lai K, Baker M (2000) Mitigating routing misbehavior in mobile ad hocnetworks. In: Proceedings of the 6th annual international conference on Mobile computingand networking (MobiCom), August 06–11, 2000, Boston, MA

2. Johnson DB, Maltz DA (1999) The dynamic source routing protocol for mobile ad hocnetworks. Internet draft, MANET working group, IETF, Oct

3. Buchegger S, Boudec JL (2002) Performance analysis of the CONFIDANT protocol(cooperation of nodes: fairness in dynamic ad-hoc networks). In: MOBIHOC’02,Switzerland, June 9–11

4. Pirzada AA, McDonald C (2004) Establishing trust in pure ad-hoc networks. In: 27thAustralian computer science conference, the University of Otago, Dunedin, New Zealand

5. Ghosh T, Pissinou N, Makki K (2005) Towards designing a trusted routing solution in mobilead hoc networks. ACM J Mobile Netw Appl (MONET) Special Iss Non-Cooperative WirelNetw Comput 10(6):985–995

6. Perkins C, Royer E (1999) Ad hoc on-demand distance vector routing. In: Proceedings ofIEEE workshop on mobile computing systems and applications

7. He Q, Wu D, Khosla P (2004) SORI: a secure and objective reputation-based incentivescheme for ad-hoc networks. In: WCNC 2004

8. Michiardi P, Molva R (2002) CORE: a collaborative reputation mechanism to enforce nodecooperation in mobile ad hoc networks. In: Proceedings of the 6th IFIP communications andmultimedia security conference, Portorosz, Slovenia

9. Buttyán L, Hubaux JP (2002) Stimulating cooperation in self-organizing mobile ad hocnetworks. MONET J Mobile Netw 10(4):477–486

10. AODV Implementation, (AODV-UU), Department of Information Technology, UppsalaUniversity (Sweden). http://core.it.uu.se/core/index.php/AODV-UU


http://core.it.uu.se/core/index.php/AODV-UU

lcee 2013 - experimenting with watchdog implementation on a real-life ad hoc network - monitoring...

Documents