Download Extending AODV to enforce participation in a Mobile Ad

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Wake-on-LAN wikipedia , lookup

Deep packet inspection wikipedia , lookup

Computer network wikipedia , lookup

AppleTalk wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

IEEE 1355 wikipedia , lookup

Backpressure routing wikipedia , lookup

Distributed operating system wikipedia , lookup

Airborne Networking wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

IEEE 802.1aq wikipedia , lookup

Everything2 wikipedia , lookup

CAN bus wikipedia , lookup

Kademlia wikipedia , lookup

Routing in delay-tolerant networking wikipedia , lookup

Transcript
Extending AODV to enforce participation in a Mobile
Ad-Hoc Network
Project Report
Team Members
Imran Patel ([email protected])
Wasim Mohiuddin ([email protected])
Abstract
In the not-so-distant future, ad-hoc mobile networks will get widely deployed for commercial and
civilian uses. Problems related to security, fault-tolerance and robustness are of special concern
in these scenarios. For maintaining the peer-to-peer and co-operative nature of ad-hoc mobile
networks in such untrusted environments, some challenging problems need to be solved. In this
project, we tried to address one such important problem of guaranteeing participation in an adhoc mobile network. Our goal was to design and implement a system which guarantees that
participating nodes in a network forward other nodes’ packets irrespective of their own selfish
motives of conserving resources like battery power, CPU and memory usage, etc.
In this project, we designed and implemented a technique that “forces” the nodes to cooperatively forward packets in the network. Our system achieves this by detecting selfish
behavior and punishing misbehaving nodes appropriately. We discuss the rationale, design and
operation of our protocol in the sections that follow. We also discuss the validity and
performance of our approach, which was evaluated using a simulation model.
Motivation
Use of ad-hoc networks in our daily lives is expected to increase in the coming years. Adhoc networks are characterized by constraints such as nodes with low processing-power, low
battery power and unreliable and bandwidth-constrained wireless links. Most of the current
research in this area is focussed on applying ad-hoc networks in military and other specialized
scenarios. However, ad-hoc networks when applied to “open” networks can face unique
problems.
Mobile Ad-Hoc networks consist of mobile nodes which act as routers. All the current
ad-hoc routing protocols assume that mobile nodes co-operatively participate in forwarding
packets. However, it might be the case that some nodes might not co-operate in forwarding the
packets and thus disrupt the routing fabric of the network. A node may do this for several reasons:

The node is selfish and it wants to conserve valuable resources like battery power,
processing, memory or other resources by avoiding routing packets that are of no direct
interest to it.

The node is malicious and it wants to disrupt the ad-hoc network by launching attacks like
Denial of Service, Illegal Intrusion, etc. A malicious node normally operates by spreading
false routing information in an ad-hoc network.
To explain the scenario, we consider an “open” multi-hop ad-hoc mobile network, which
is a collection of community wireless networks providing “hot spots” for Internet connectivity.
Now, consider a person with a laptop sitting in a street-side cafeteria next to a local “hot spot”.
His node is one of the nodes that forwards the Internet-bound or Internet-originated packets
to/from the “hot spot”. The person might decide to turn off the forwarding of non-local packets to
decrease his power usage and may thus violate the co-operation property of ad-hoc network.
We believe that these kind of selfish behaviors might pose serious threat to the fair usage
of ad-hoc networks in day-to-day scenarios. To achieve the goal of enforcing participation in
routing, our system follows the concept of “punishment-if-found-guilty” model.
The operation of the system can be described generally as:
 Each node keeps a close watch on its neighbors looking for any selfish behavior. In other
words: a node does not trust anybody.
 If a node detects selfish behavior from its neighbor, it assumes the link with the neighbor to
be broken and “remembers” the selfish node. Thus all the routes using this now broken link
are invalidated and the selfish node is thereby removed from the routing infrastructure of the
affected nodes. Also, since the neighbor node remembers the selfish node, any further
communication from the selfish node will be ignored.
 A node, which acts as selfish, is eventually exposed by its neighbors and is cut off from the
rest of the network.
 After some period of cut-off from the affected nodes as punishment, the selfish node might be
re-admitted into the network.
In the above approach, fear of punishment forces nodes to be selfless and fair in forwarding
packets.
Scope of the Project and Assumptions
To achieve the goal of enforcing participation in routing, our system works on top of an existing
routing protocol. We have chosen AODV [1] as our underlying ad-hoc routing algorithm since it
provides almost all the required message-passing functionality and necessary states in the nodes
to support our extension. This leads to a less overhead for enforcing participation in routing.
However, we rely on some extra state information to correctly enforce participation. Although
this makes our mechanism tightly coupled with AODV, we think that it might be easier to make
this mechanism work in conjunction with other routing protocols.
We also make an important decision about the types of misbehaviors that our protocol can
address. Specifically, we only handle the selfishly behaving nodes (as defined above) in our
protocol. The reason for this is that the participation guarantee problem is closely related to
Byzantine failure model. It has been proved in [2] that Byzantine failures are impossible to handle
in an asynchronous system even in the presence of a single “faulty” node. For example, a mobile
node trying to tactfully avoid forwarding packets is similar to a malicious node foiling a
consensus algorithm. This means it is impossible to create algorithms that might handle all kind
of faulty behavior. Thus, by deciding to tackle selfish nodes, we can concentrate on a specific
type of fault model and define a well-tuned solution for it. We believe tackling malicious nodes
can be made easy by utilizing in-built routing security mechanisms like authentication.
We also make assumptions about the kind of selfish behavior a node can exhibit. One of the ways
in which a selfish node can drop non-local data packets is by using a packet filtering personal
firewall. Moreover, the selfish node can still send and receive its own data while exhibiting this
selfish behavior. We assume that the users are not sophisticated enough to intelligently drop
routing control packets since that would require a deep knowledge of the underlying routing
protocol.
The proposed protocol is not designed to be immune against “node collusion”. So, if two or more
nodes agree beforehand to mislead and bypass it, they can do so with relative ease. But forming
such kind of a priori relationship in a dynamic mobile ad-hoc network seems to be a less likely
event.
Keeping in mind these assumptions, we now define selfish behavior as:
A selfish node agrees to route the data flow (i.e. participates in route discovery) but
indiscriminately drops data packets later.
Finally, for the correct operation of the proposed protocol, we assume that the underlying link is
bi-directional and link layer acknowledgements are provided in the case of unicast transmissions
(as in IEEE 802.11b).
Related Work
Though enforcing participation is one of the major issues a routing protocol must
consider, relatively less work has been done on it. Currently, it seems that the trend is to develop
a routing protocol and then formulating some system on top of it. Upon surveying related
research projects, we found the following methods currently employed to solve this problem:
Incentive Based Approach
This approach is being used by the Terminodes Project [3]. Under this scheme, each node
is given some incentives for forwarding other nodes’ packets. The node then spends these
incentives for forwarding its own packets. Thus this model simulates a virtual economy where
virtual currency (called “nuglets”) is transferred between nodes. The implementation of this
payment method is done using simple counters which are implemented under a tamper-proof
secure layer. In general, this method has following disadvantages:
Computationally expensive
It utilizes private/public key cryptography to provide enhanced security – this is a frequently done
computationally expensive task, which is not desirable for low-powered mobile nodes.
Requires Tamper-Resistant Layer
This solution assumes that there is a layer in the protocol stack in each node, which is tamperproof and secure. This property can only be achieved by a hardware solution and this will mean
that each mobile node has to be modified which is infeasible in most cases.
Weak Model
This model does not guarantee a stable network/economy. Nodes can earn unequal amounts of
virtual currency because of their topological location. Consider, a node on the periphery of the
network. This node might not be selfish, but because of its topologically inferior position, it can
forward only few packets compared to the packets it has to send. This node might go bankrupt
very soon. Compare this to a node in the center of the network, which might earn lots of money
because it can forward lots of traffic based on its superior location.
Weak Participation Guarantee
It does not properly enforce participation since a node with enough money can stop
participating for a while and start forwarding again when the need arises.
A group at Stanford also works along the same lines [4]. They build upon the above
approach but instead of relying on a tamper-proof hardware solution, they propose a software
solution. They introduce the concept of a trusted third-party called the “Banker Node”. This
solves most of the problems related to payment consolidation, non-repudiation and authenticity.
But it has the following shortcoming in addition to those mentioned above (except the tamperresistance requirement):
Centralized approach
The reliance on a trusted third-party for providing “banking services” severely reduces the faulttolerance and mobility of the system. In an ad-hoc mobile network, it is very difficult to provide
fault-tolerance and continuos connectivity guarantees.
Mitigating Routing Misbehavior
This method is described in [5] and it solves the problem by routing packets around the selfish
nodes. Thus, it also requires discovering selfish nodes and then avoids routing traffic across them.
However, a selfish node may transmit its own packets if it wishes. So, this method does not
enforce participation and tries to get around the problem.
Handling Malicious Nodes
Malicious nodes can be tackled by providing integrating authentication with AODV. On such
approach is described in [6]. An inherently secure routing protocol limits the damage caused by a
malicious node. Thus, it can aid participation guarantee protocol like ours to provide a more
robust and secure solution.
Design and Operation of the Protocol
In this section we try to explain the working of our protocol. We assume the reader is familiar
with the working of AODV since our protocol runs as an extension on top of it. The proposed
protocol comprises of 4 basic operations:




Selfish Node Discovery
Adjusting Routing to isolate and punish Selfish Node
Re-inducting the selfish node into the network.
Avoiding “False Accusations”
Selfish Node Discovery
For finding a selfish node, we use a “Passive Acknowledgement (Ack)” scheme which can be
described as follows:
 When any node sends a packet to the next hop, it stores some information about the packet
with itself.
 It then listens on the channel in promiscuous mode to check whether the next hop forwarded
the packet or not.
 If it overhears a packet which matches with the packet info that it has, it decides that the next
hop has forwarded the packet.
 If it does not overhear a matching packet on the channel for sometime, it doubts the next hop
as selfish.
However, the node is not deemed selfish right away upon the failure of a single Passive Ack.
Instead, we give the next hop a few chances. So given our example “café” scenario, the node next
to the hot spot is detected to be selfish by one of its neighbors.
Selfish Node Punishment
Once the node determines the neighbor is selfish, it broadcasts a RERR packet suggesting that the
link through the selfish node is broken. This invalidates all the routes going through that link. It
also marks the misbehaving node as selfish in its neighbor table. Any further correspondence
from the selfish node would be ignored by it in the future for sometime.
Again, in our scenario, this means that the nodes start accessing the Internet through some other
node closer to the hot spot instead of routing through the selfish nodes. Also, the selfish node is
now gradually isolated from the network by its neighbors.
Re-induction of Selfish Node into the network
The node is cut-off from the rest of the network only for a specific time as a form of punishment.
After a specified time, the node can start accessing the network again.
Avoiding False Accusations
Sometimes the Passive Ack scheme might fail i.e. a node may fail to overhear the next hop’s
transmission even if the next hop forwarded the packet. In this case, it might wrongfully accuse
the next hop to be selfish. We try to avoid this by using a compensation scheme. This means that
whenever the next hop successfully forwards a packet, the precursor node lessens its “doubt” of
the node being selfish.
Implementation
We prototype implementation was carried out under a simulator. In this section, we provide a
high-level overview of the various components of our implementation.
Passive Ack Scheme
We implemented the passive ACK scheme by writing a promiscuous mode packet handler. This
callback function is called for each promiscuous receive. Also, when we send a data packet, we
keep some information about it in a table called “Data Sent Table (DST)”. As an optimization,
instead of storing a copy of the packet, we only store the fields of IP header that uniquely identify
the packet. The promiscuous handler upon receiving each packet compares its info with the sent
packets info in the DST. If it finds a matching packet, it means that a packet that we sent was
overheard (meaning forwarded by the next hop) and thus its entry is deleted from the table.
However, if the entry is not removed after sometime (meaning that the promiscuous handler did
not overhear the packet), the next hop is doubted to be selfish. The Passive Ack operation is
shown in the Fig 1.
Source IP = A
Id = 100
Fragment Offset = 0
TTL = 62
Matches!
A
B
C
Source IP = A
Id = 100
Fragment Offset = 0
TTL = 63
Fig 1
State Maintenance
Once we discover that our next hop is selfish, we remember this information. We do this by
defining a neighbor table. A node is entered into our neighbor table if we receive a RREP from it
and we remove it from our table if there is a link breakage. We keep a counter with each neighbor
table entry that quantifies our “doubts” of the neighbor being greedy.
Route Invalidation and Re-discovery
We do this when we confirm that the next node is selfish. In that case, we send a RERR packet to
all the precursor nodes that might be using the selfish node for their routing. In turn, they initiate
a new route discovery cycle in which RREPs from the selfish node are ignored and thus an
alternate route is established.
Selfish node punishment
This is achieved by dropping all routing related transmissions (RREQ, RREP) from a selfish node
at the neighbors. This guarantees that the selfish node is unable to initiate new connections
through the neighbors who know the fact that it is selfish.
Testing and Characterization
This section describes our prototype simulation, validation and performance characteristics,
associated measurements and their analysis.
We implemented the prototype for our AODV extension under Glomosim - a wireless network
simulator developed at UCLA. Our simulation code is clearly segregated from the standard
AODV implementation and can be enabled/disabled as a compile-time option. The
implementation was done in C on Solaris 8 workstations. We also developed bash and awk scripts
for extracting the relevant statistics from the simulation runs. The simulations were carried out on
PCs (Intel) running Solaris 8.
Configuration Parameters
The following parameters can be configured at compile-time in our simulation:
Selfish Behavior Start Time: This value specifies after what time should the designated selfish
nodes start behaving selfishly. We set it to 0 min i.e. start acting selfish right from the start.
Selfish Node Fraction: This specifies what fraction of the nodes should act selfish. We varied
this value during our simulation.
Selfish drop threshold: This value specifies that how many “benefit of doubts” should the next
node be given before declaring it selfish. This value should be selected such that false accusations
as well as packet losses are minimized. We set its value to 8 for our simulation.
Re-induction timeout: This value specifies the time duration for which a selfish node should be
punished/isolated. It was set to 5 min in our simulations.
Validity Testing
To check whether our implementation was valid and working correctly, we created a base case
scenario. We analyzed simulation runs based on it and verified the functionality of our protocol
extension.
Our scenario consisted of 8 nodes, which were placed in a custom grid-like position
initially. We designated one node to be selfish. We created three Constant Bit Rate (CBR)
connections. Two of them originated from the selfish node and the other had a route through it.
The various stages of the scenario are depicted in the Fig 2 – 5. As shown, we selected node 1 to
be selfish. Two CBR connections – node 1 to node 3 and node 2 to node 0 are established
throughout the simulation. The third connection from 1 to 7 gets established at a later time. This
is shown in Fig 2. We describe the validation tests as follows:
0
4
0
4
0
4
0
4
1
5
1
5
1
5
1
5
2
6
2
6
2
6
2
6
t=0s
t=60s
7
3
Fig 2
7
3
Fig 3
7
3
Fig 4
7
3
Fig 5
Discover selfish nodes: Initially, the routes for the two connections are as shown in Fig 3.
However, node 1 being selfish drops packets for the packets from node 2 destined for node 0. Our
Passive Ack scheme was able to identify selfish behavior of node 1 (Fig 4).
Route around the selfish nodes: Once node 2 discovered that node 1 was selfish it invalidated
the route for the connection to node 0 since it passed through node 1. It then established a route
around the selfish node (Fig 4).
Punish the selfish node: In addition to routing around node 1, node 2 must also punish it for
being selfish. Our protocol does this by making the non-selfish node avoid all new connections
from selfish nodes. However, the existing connections from selfish node remain unaffected. In
this case, node 2 does not allow the new connection from node 1 to node 7, thus punishing node 1
(Fig 5).
Re-induct the selfish node if necessary: Eventually, after node 1 is isolated for a sufficient time,
node 2 re-inducts it back into the network. It does this by allowing the till-now unsuccessful
connection from 1 to 7.
Performance Tests
For these tests, our simulation scenario included 50 nodes positioned in a 1000 x 1000 m flat
space. The link layer protocol used was IEEE 802.11 since our protocol requires link-layer Acks
to function properly. Our simulations run for 300 seconds – we discuss the effects of this
parameter later .
Node Placement
For the initial node placement, we used a random placement model. The random placement (and
all other random behavior in Glomosim) is influenced by a single seed, which is specified in a
configuration file. We used 5 different seeds for each simulation run.
Mobility Model
We carried out our tests using a Random Waypoint Mobility Model. Under this model, a node
randomly chooses a destination and moves straight in that direction with speed uniformly
bounded within a range. After reaching the destination, the node waits for a period of time known
as the Pause Time. We carried out our simulations with the following parameters:
 Minimum speed: 0 m/s
 Maximum speed: 20 m/s
 Pause Time: 100 seconds
We chose the above model and parameters because they represent a moderate mobility
environment and closely model real world mobility scenarios.
Communication Model
In our tests, we used 8 Constant Bit Rate (CBR) data flows among nodes. All the 16 end-nodes
involved in the flows are different. In three of the data connections, the selfish nodes act either as
source or destination. The other five connections were to and from the fair nodes. All CBR
connections have a data rate of 512 bytes/sec (one packet of 512 bytes is sent every second) and
they run from the start of the simulation till the end.
Selfish Node Behavior
In our simulations, a fraction of the nodes act as selfish. As described above, a selfish node will
allow routes to pass through it (by routing packets to pass through) but will refuse to forward data
packets later. Selfish nodes can start behaving selfishly after a variable amount of time. One of
the most challenging parts of the simulation was to figure out an appropriate randomized scheme
for selecting random nodes. We wanted to measure different performance characteristics by
varying the fraction of selfish nodes in the network. In our simulation, the fraction of selfish
nodes varies from 0 – 50% in 10% increments. We thought that 50% bound was very realistic and
represented the worse case. Finally, the mathematical model that we used for selecting random
nodes is expressed as:
R = Node Id % 100/Fraction_interval
Selfish if 0 <= R < Fraction * 10
In our simulations, Fraction_interval = 10% and Fraction varies from 0 –50% in 10% increments.
The above formula can select selfish nodes in a predictable manner. So, for example in our 50
node network:
Fraction = 10 %: Selfish Nodes = {0, 10, 20, 30, 40}
Fraction = 20%: Selfish Nodes = {0, 1, 10, 11, 20, 21, 30, 31, 40, 41}
The above figures reflect an important property: The nodes, which are deemed selfish in the 10%
case, are also deemed selfish in the 20% case. Thus, the simulation run with 20% nodes as selfish
has the same (and more) difficulties as that of a 10% run, when they are run with the same seed
(thus guaranteeing the same mobility pattern and initial placement). This property can also be
achieved by generating random numbers to select selfish nodes with the same seed across 10%
and 20% cases. But then connections might include selfish nodes in one run and might not
include selfish nodes in another run. This is required because when we collect the performance
metrics, we separate out the metrics of selfish connections from that of non-selfish connections.
We discuss the rationale for this below.
Performance Metrics
We measured the following metrics to evaluate the performance of our protocol extension:
Throughput
Network Throughput
We measure the network throughput, which is defined as ratio of number of packets received to
the number of sent. We record the throughput of connections involving non-selfish nodes and the
throughput of connections involving selfish nodes. We do this because our protocol may increase
or decrease throughput depending on whether the connection involves a selfish node or not. Thus,
this test reflects the desired effects that our protocol is trying to achieve.
False Accusation Avoidance
One special case is when there are no selfish nodes in the network i.e. fraction of selfish nodes =
0%. We want to show that in this case, our extensions achieve the same throughput as that of a
standard AODV protocol. We want to show that our scheme also mitigates the effects of false
accusations that might occur due to ambiguous promiscuous listening. Normally, a false alarm
will unnecessarily result in a new route discovery, which in turn leads to decrease in packet
throughput. But with the compensation scheme in our protocol, these false alarms can be
minimized. This test measures the effectiveness of our technique.
Overhead
We measure the overhead of our protocol in terms of two metrics:
Routing Overhead
It is defined as the ratio of number of routing control packets received to the number of data
packets transmitted. This transmission count includes the end-nodes of the connection as well as
the forwarding nodes. In the case of AODV, this means Route Request (RREQ), Route Reply
(RREP) and Route Error (RERR) packets.
Passive Ack Overhead
We calculate the overhead associated with Passive Ack scheme in terms of state maintenance and
processing of packets received in the promiscuous mode. We carry out this test by running
simulations under a fair network and compute the overhearing overhead by measuring the number
of packets additionally processed in promiscuous mode. We measure the state maintenance using
the same runs and by calculating the maximum amount of memory used for storing sent packet
info during the runs.
Results
We conducted the simulation runs using 5 different seeds and 6 different selfish fractions. We ran
this simulations using our protocol extensions and also using the standard AODV simulation.
Thus, we analyzed data from a total of 60 simulation runs. Our findings are detailed below:
Throughput
throughput
1
0.8
0.6
0.4
0.2
0
0
10
20
30
40
50
% of selfish nodes
Extended AODV
Standard AODV
Graph 1
Network Throughput
Graph 1 represents the throughput observations recorded during the simulation runs. As can be
seen, our extensions provided a higher throughput rate compared to the standard AODV
implementation. We achieve a maximum of 31% throughput increase and a minimum of 14%
throughput increase. One more important thing to notice is that as the fraction of selfish nodes
increases, our extensions perform much better than the standard implementation. This is because
when the number of selfish nodes is less, the non-selfish node can be unintentionally aided by its
mobility to get away from a selfish node.
Thus, mobility might lead to the creation of a new route, which avoids the selfish node. But as the
number of selfish nodes increases, even mobility doesn’t help much since the possibility that
alternate routes also have selfish nodes increases. Our extensions perform much better since they
intelligently route around selfish nodes instead of relying on this (sometimes beneficial) side
effect of mobility.
False Accusation Avoidance
Graph 1 also shows an important desirable characteristic. When both the AODV implementations
are run in a fair network (% of selfish nodes = 0), they achieve the same throughput. This shows
that our Passive Ack mechanism coupled with compensation scheme performs reliably and
generates lesser false alarms.
Overhead
Graph 2
Routing Overhead
Graph 2 compares the routing overhead incurred by our extensions versus that by standard
implementation. As can be seen from the graph, our extensions incur significant overhead
compared to the standard implementation. This is because the standard AODV implementation
fails to identify selfish nodes and thereby utilizes the same route, which includes the selfish node.
This leads to a lesser routing overhead since alternate fair routes are not explored. In contrast, our
protocol leads to new route discovery cycles upon finding a selfish node. This has an advantage
of increased throughput but also has the side effect of increasing routing overhead. Also note that
as the fraction of selfish nodes increase, the routing overhead increases in our case. This is
because more and more routes include selfish nodes and alternate routes have to be discovered
frequently.
State Maintenance Overhead
The figures related to state maintenance overhead are summarized in Table 1. As can be seen, the
number of packets processed increases tremendously in promiscuous mode. However, we think
that it might not affect the speed of our implementation since we make simple comparisons on
packets received in promiscuous mode.
Extra Packets Processed (promiscuously)
11 times (compared to Std AODV)
Maximum Size of Data Sent Table (Avg)
40 (720 Bytes)
Table 1
However, it might have considerable implications on the power usage of the mobile node. Also
noted in the table is the average storage associated with Passive Ack mechanism. It turns out to be
very less, thus showing that the memory requirements of our extensions are less.
Other observations
We also conducted the above mentioned performance tests in an ad-hoc network with no
mobility. We discovered that standard AODV performed very poorly. The tests that we
conducted showed that the standard AODV implementation achieved 90-100% throughput and
0% throughput in another run. This was because once a route through a selfish node is
established, it remains established forever (since there is no mobility) and thus all the data packets
get dropped. Thus standard AODV gives all-or-no throughput. Our extension outperforms the
standard implementation in terms of throughput but also incurs heavy routing overhead compared
to it.
One more important thing to note was that our simulations failed to show the decrease in
throughput of selfish nodes with our protocol. Instead, the throughput of selfish nodes increased
compared to the standard AODV case. We believe this was due to the selfish nodes dropping the
other selfish nodes packets. Thus, the selfish nodes routed around the other selfish nodes and
maintained the connection. They could find alternate route through nodes, which did not know
that they were selfish. This is because our protocol limits the knowledge of a node being selfish at
most to its neighbors and does not propagate the information throughout the network. We talk
more about this in the next section.
Lessons Learned
We learned very quickly during our implementation of Extended AODV that there were many
subtle issues that needed to be tackled. Our initial implementation of Extended AODV involved
non-selfish nodes dropping any packets originating from selfish nodes. This approach has some
flaws that can be seen more clearly using an example (see Fig 6). Suppose we initially have two
existing data connections as in the figure below (From Node A to Node B, and vice-versa).
Using our original approach, when Node A became selfish and stopped forwarding Node B’s data
packets, Node B would accuse Node A of being selfish (using Passive ACK on the data packets)
and Node B would immediately drop any data packets originating from Node A. Finally, Node B
would proceed to route around Node A if possible.
Then Node A would figure out that Node B stopped forwarding its packets. That had the
undesired side-effect of Node A (the true selfish node) accusing Node B (an innocent node) of
being selfish. This poses a serious problem if Node B tries to re-induct Node A into the network
even if Node A stops behaving selfishly. Node B would try to re-induct Node A into the network
after some timeout. At this point, Node A’s timeout for Node B would not yet have expired and
Node A would still be accusing Node B of being selfish (Node A would refuse to forward any
packets originating from Node B). By the time Node A’s timeout for re-inducting Node B would
have expired, Node B would be accusing Node A of being selfish. This “see-saw” problem of
nodes accusing each other of being guilty was preventing us from re-inducting greedy nodes.
Furthermore, this problem prevents us from trying to inform other nodes in the network about
existing selfish nodes because not all nodes that are being accused of being selfish are indeed
selfish.
To solve this problem, we had to allow existing data connections involving selfish nodes
to continue. But, any future connections from this selfish node would not be allowed (since we
do not use Passive ACK for the control packets used to setup a connection, this approach works).
A
B
Fig 6
Since the true selfish node is no longer accusing innocent nodes of being selfish, we could have
introduced a new control packet into AODV informing other nodes about selfish nodes. This
would serve an effective tool for isolating selfish nodes more quickly and could be addressed in
future work.
References
[1] C. Perkins, E. Royer, and S. Das, Ad hoc on-demand distance vector (aodv) routing, Internet
Draft draft-ietf-manet-aodv-04.txt, work in progress, October 1999.
[2] Fisher, M., Lynch, N., and Patterson, M. Impossibility of distributed consensus with one
faulty process, Journal of the ACM 32, 2 (Apr. 1985), 274-382.
[3] L. Buttyan, J. P. Hubaux. Stimulating Cooperation in Self-Organizing Mobile Ad Hoc
Networks, Technical Report No. DSC/2001/046, Swiss Federal Institute of Technology,
Lausanne, August 2001.
[4] Ad Hoc Participation Guarantee Group, Stanford University. Participation Incentives for Ad
Hoc Networks (http://www.stanford.edu/~chekist/paper.ps)
[5] S. Marti, T. Giuli, K. Lai, and M. Baker. Mitigating routing misbehavior in mobile ad hoc
networks. In Proceedings of the Sixth annual ACM/IEEE International Conference on Mobile
Computing and Networking, pages 255--265, 2000.
[6] Manel Guerrero Zapata. Secure Ad hoc On-Demand Distance Vector (SAODV) Routing,
Internet Draft draft-guerrero-manet-saodv-00.txt, work in progress, August 2001.