Analysis of Simulation of Ad-hoc on Demand Distance Vector Routing Protocol

The “Ad hoc On-Demand Distance Vector (AODV) routing protocol” is used by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as ``counting to infinity'') associated with classical distance vector protocols. The Ad hoc On-Demand Distance Vector (AODV) algorithm enables dynamic, self-starting, multihop routing between participating mobile nodes wishing to establish and maintain an ad hoc network. AODV allows mobile nodes to obtain routes quickly for new destinations, and does not require nodes to maintain routes to destinations that are not in active communication. AODV allows mobile nodes to respond to link breakages and changes in network topology in a timely manner. The operation of AODV is loop-free, and by avoiding the Bellman-Ford ``counting to infinity'' problem offers quick convergence when the ad hoc network topology changes (typically, when a node moves in the network). When links break, AODV causes the affected set of nodes to be notified so that they are able to invalidate the routes using the broken link. One distinguishing feature of AODV is its use of a destination sequence number for each route entry. The destination sequence number is created by the destination for any route information it sends to requesting nodes. Using destination sequence numbers ensures loop freedom and is simple to program. Given the choice between two routes to a destination, a requesting node always selects the one with the greatest sequence number. Route Requests (RREQs), Route Replies (RREPs), and Route Errors (RERRs) are the message types defined by AODV. This message types are received at port 654, over UDP, and normal IP header processing applies. So, for instance, the requesting node is expected to use its IP address as the Originator IP address for the messages. For broadcast messages, the IP limited broadcast address (255.255.255.255) is used. This means that such messages are not blindly forwarded. However, AODV operation does require certain messages (e.g., RREQ) to be disseminated widely, perhaps throughout the ad hoc network. The range of dissemination of such RREQs is indicated by the TTL in the IP header. Fragmentation is typically not required. As long as the endpoints of a communication connection have valid routes to each other, AODV does not play any role. When a route to a new destination is needed, the node broadcasts a RREQ to find a route to the destination. A route can be determined when the RREQ reaches either the destination itself, or an intermediate National Conference on Advanced Computing and Communication Technology | ACCT-10| 772 node with a 'fresh enough' route to the destination. A 'fresh enough' route is an unexpired route entry for the destination whose associated sequence number is at least as great as that contained in the RREQ. The route is made available by unicasting a RREP back to the origination of the RREQ. Each node receiving the request caches a route back to the originator of the request, so that the RREP can be unicast from the destination along a path to that originator, or likewise from any intermediate node that is able to satisfy the request. Nodes monitor the link status of next hops in active routes. When a link break in an active route is detected, a RERR message is used to notify other nodes that the loss of that link has occurred. The RERR message indicates those destinations which are now unreachable due to the loss of the link. In order to enable this reporting mechanism, each node keeps a ``precursor list'', containing the IP address for each its neighbors that are likely to use it as a next hop towards the destination that is now unreachable. The information in the precursor lists is most easily acquired during the processing for generation of a RREP message, which by definition has to be sent to a node in a precursor list.A RREQ may also be received for a multicast IP address. In this document, full processing for such messages is not specified. For example, the originator of such a RREQ for a multicast IP address may have to follow special rules. However, it is important to enable correct multicast operation by intermediate nodes that are not enabled as originating or destination nodes for IP multicast address, and likewise are not equipped for any special multicast protocol processing. For such multicast-unaware nodes, processing for a multicast IP address as a destination IP address MUST be carried out in the same way as for any other destination IP address. AODV is a routing protocol, and it deals with route table management. Route table information must be kept even for ephemeral routes, such as are created to temporarily store reverse paths towards nodes originating RREQs. AODV uses the following fields with each route table entry: Destination IP Address Destination Sequence Number Interface Hop Count (number of hops needed to reach destination) Last Hop Count (described in subsections 6.4 and 6.11) Next Hop List of Precursors (described in Section 6.2) Lifetime (expiration or deletion time of the route) Routing Flags Managing the sequence number is crucial to avoiding routing loops, even when links break and a node is no longer reachable to supply its own information about its sequence number.A destination becomes unreachable when a link breaks or is deactivated. When these conditions occur; the route is invalidated by operations involving the sequence number and metric (hop count). [1] [2] [7] National Conference on Advanced Computing and Communication Technology | ACCT-10| 773 1. SIMULATION WORK [4] [5] [6] On the basis of results of *.nam file and *.tr file, the analysis is being done. We also evaluate the performance of AODV by taking number of nodes as a parameter. NAM is a built-in program in ns2-allinone package. It helps us to see the flow of packets between various nodes. With this, we are also able to know whether the packets have reached to their destination properly or dropped in between. NAM is invoked within the Tcl file. The NAM scripts are stored in *.nam file and scripts for tracegraph are stored in *.tr file. 1. AODV with 6 nodes. 2. AODV with 10 nodes. 3. AODV with 15 nodes. The comparison of performance of AODV, based on the number of nodes is done on following parameters like packet sent, packet received, throughput and average end-to end delay. 1. Simulation of AODV with 6 Nodes Fig. 1.1AODV with 6 nodes: Sending and Receiving Packets and Route Discovery Fig. 1.2 X-graph out-put of adov.tcl with 6 nodes 2. Simulation of AODV with 10 Nodes Fig.1.3 AODV with 10 nodes: Xgraph National Conference on Advanced Computing and Communication Technology | ACCT-10| 774 Fig. 1.4 AODV with 10 nodes: Sending and Receiving Packets and Route Discovery 3. Simulation of AODV.TCL with 15 nodes Fig AODV with 15 nodes: Dropping of Packets Comparison of Performance of AODV based upon Number of Nodes As we increase the number of nodes for performing the simulation of AODV protocol, number of sent and delivered packets changes, which in turn changes the throughput and average end-to-end delay. Throughput is defined as the ratio of data delivered to the destination to the data sent out by the sources. Average end-toend delay is the average time a packet takes to reach its destination. shows the difference between sent packets, received packets, lost and dropped packets, average end-to-end delay when number of nodes is increased. NO. OF NODES 6 10 15 PACKET SENT 2.20