Mike's suggestion to read RFC 3561 - Ad hoc On-Demand Distance Vector (AODV) Routing should do the trick; in the meantime, I will go ahead and summarize it for you.
Wireless (routing) protocols, such as AODV protocols, use sequence numbers in a different way than wireline protocols do. AODV maintains a table of destination IP addresses, along with the last sequence number. This way, if it receives the same routing sequence number in an update, it detects the duplicate and drops the update; thus, avoiding a potential loop. Additionally, AODV does not forward/process update packets that it has seen before. The sending node (based on whatever message they send Route request, Route Reply), maintains their own sequence numbers and increments it before sending a new packet out.
AODV is hardly alone in depending upon sequence numbers to avoid loops; RFC 4728 - Dynamic Source Routing (DSR) also depends on sequence numbers. Yet another wireless (multicast) routing protocol that uses sequence number to avoid looping is IETF Draft - The Adaptive Demand-Driven Multicast Routing Protocol for Mobile Ad Hoc Networks (ADMR).
We should note that layer-2 in wireless networks (typically) do not use Spanning Tree Protocol (STP) for loop prevention.
Case of RREP: When nodes receive RREQ (Route request) for a destination node, then two types of nodes can respond to it. One is the destination node itself -- in this case, it can increase the seqeunce ID. The second types of nodes are those that have an existing route to the destination node. Now, they have already saved the seq number that was generated by the destination node, when they received the route. When sending a RREP, these intermediate nodes simply copy the earlier learnt sequence number (and do not generate a new one). This way, if the destination were to send a new route, then the node that generated RREQ, when it receives the RREP, it can pick the one with the latest sequence number and ignore the ones that are stale.
Here is what the RFC says about the destination node sending RREP:
If the generating node is the destination itself, it MUST increment its own sequence number by one if the sequence number in the RREQ packet is equal to that incremented value.
Case of RREQ: Nodes also maintain reverse routes (let us say, for node X) and they would want to update the route to originator of RREQ (node X) only when they receive a new RREQ from node X. One way to do this is to let X increment the sequence number whenever it sends a RREQ.
A note on destination sequence number field in the RREQ: As per section 5.1, when originating RREQ: "Destination Sequence Number: The latest sequence number received in the past by the originator for any route towards the destination.". As per section 6.5, when processing RREQ: "Lastly, the Destination Sequene number for the requested dest is set to the maximum of the corresponding value received in the RREQ message, and the destination sequence value currently maintained by the node for the requested destination."
So, basically, settting/updating Dest Seq Number means that the sender or forwarder of RREQ is indicating that I have the information till, let us say seq 101, that was sent by the destination node. If that is not the latest, then the destination node does not bother to increase its own sequence number before sending the RREP (section 6.6.1).
Best Answer
These two sequence numbers help avoid looping and stale routes in the route discovery process. They act as a time-reference (using it for a lack of b identifier for the originator of RREQ and the intended receiver (destination) of the RREQ. Since they act as a time-reference for different nodes, there is no duplication!
The RREQ ID (let us seqA) identifies the originator of the RREQ packet (let us say nodeA). Other nodes that receive the RREQ can learn a route to the originator and mark that with seqA. Now, if these nodes were to receive any route update for nodeA, then they would compare the sequence number in that packet against seqA -- if it is lower, then they would discard it.
The destination sequence number (let us say seqB) helps identify the destination node for which we are sending the RREQ (let us say nodeB). It is possible that other nodes in the path may already have a route for nodeB along with an associated sequence number. If seqB is higher than the associated sequence number, then these intermediate devices would know that nodeA is looking for a newer route and would not reply to that.
Your closely is perhaps similar to an earlier question: AODV sequence numbers and loop prevention