原地址：        http://www.dcs.warwick.ac.uk/~adhoc1/trustaodv.html

There are many possible means of identifying if a node can be trusted. This trust can be based on a variety of the nodes activities, with the different behaviors of the node being weighted accordingly to produce a trust level.

A lot of the means described below are difficult to detect or are not fully implemented within ns2's version of AODV. This has led to using acknowledgment solely to indicate benevolence. We believe that this form of detection is the most worthwhile and best indicates a benevolent and functioning node.

Acknowledgment is a means of ensuring that packets sent for forwarding have been forwarded. There is a couple of ways that this is possible but Passive Acknowledgment is by far the easiest to implement. Passive Acknowledgment uses promiscuous mode to monitor the channel, this allows the node to detect any transmitted packets, irrelevant of the actual destination that they are intended for. With this the node can ensure that packets it has sent to a neighbouring node for forwarding are indeed forwarded.

This has been implemented within TRUSTAODV using promiscuous mode to monitor the channel.

As defined by Pirzada “Packet Precision ensures the integrity of the data and control packets that are either received of forwarded by other nodes in the network.”, this type of detection aims to spot packets that have either been corrupted due to a faulty node or have been generated maliciously. This could be done by monitoring the control packets that lead to suitable successful routes. Another possible means is to check the packet information is within certain tolerances. For example one possible addition to TRUSTAODV would be to ensure that the sequence number within a reply is note inconceivably higher that the sequence number within the request, as this suggests that the replying node is trying to ensure it is part of the final route.

This is possible to implement and would be a good addition to the TRUSTAODV protocol.

Gratuitous replies are generated when an intermediate node replies to a route request because it has a fresh enough route, allowing AODV to respond faster to route requests. When this happens the node sends out a normal reply to the source of the request and then sends a gratuitous reply to the destination to update and ensure that the route still exists. Gratuitous replies are only required to be sent when the 'G' flag is set within the route request (No such G flag exists within ns2, it is either on or off all of the time) and even then gratuitous replies are not required for the network to function but they improve route maintenance. This means that a nodes benevolence can be detected from their willingness to transmit gratuitous replies. We currently have gratuitous replies turned off and they can be turned on by defining RREQ_GRAT_RREP within trustaodv.h. The line to insert is: