Essentially because, as RFC 3561 states, §6.6, "(...) the RREP is unicast to the next hop toward the originator of the RREQ, as indicated by the route table entry for that originator (...)". Since this message is unicast to the next hop towards the source, there's no possible confusion and the receiving node will in turn search in its tables a route to the next hop towards the originator, etc.

Thank you for your kind reply sir.  But, is there no need to specifically add one more field in the RREP header (or IP header) field to include the next hop info? And then the intermediate node whose address matches with the next hop address can receive it . Or does any additional header exist, already including the next hop info?  Does it suffice, to say the packet is unicasted using next hop info in routing table.

Venkatesh, let's state the obvious: if this RREP made it to the routing layer of the next hop, it simply means that the destination address in the IP header of the RREP (unicast, remember?) matched the IP address of the next hop beforehand, so this node is necessarily the next hop to the originator and that's what the next hop will assume. No need to add extra info.

Ok. So, the dest addr in RREP's IP header contains the next hop info. Lets come to data packets transmission. Let A-B-C-D be the route established. A is source and D is the destination. So, when A wants to sends data packet to D, the destination address in IP header of data packet sent by A is B (the next hop) for the destination D. When the data packet is received by B,  B does not have info of what the real destination(D in this case) is. So, B cannot choose the next hop (node C), then how wil data pkts be transmitted in this case.

I realize that what seems to bother you is in fact the concept of IP forwarding (very general, and out of the scope of AODV itself, although, as most if not all MANET routing protocols, the deployed solution will rely on it). I suggest you focus on that first, then the aforementioned discussion will become clearer.

On a side remark, IP forwarding is the reason why, obviously, the AODV RREP control packet was designed to be unicast on a hop-by-hop basis and not unicast directly by the destination to the source, since the control packet would then have been routed all the way along the intended path, but without being locally forwarded (note: not the same kind of forward) to the upper layers on the intermediate nodes. An interesting paper to read on that subject is "An Implementation Study of the AODV Routing Protocol" by Royer and Perkins.

Ok sir, shall try with it. Thank you for guiding me.

hi sir,

In "An Implementation Study of the AODV Routing Protocol" by Royer and Perkins, its said AODV control messages are received via UDP( using linux kernel implementation and AODV routing daemon), but in ns2 simulator these AODV control messages dont have a UDP header, so can i say that these control packets are manufactured in the network layer? If so, can the network layer have access to sequence number info which i hope it does using routing table info