Ad Hoc On-Demand Distance Vector Routing (AODV) http://www. ietf

Use protocol to discover the path (routing) Ad-hoc Solutions Use existing computers to act as routers Use protocol to discover the path (routing) Traditional routing algorithms no longer work well

Proactive Reactive Protocol Classes Ready to go Whole topology On-demand Little maintenance Cell operations Ready to go Whole topology Updates changes Overhead costs Bandwidth Battery power Inflexible

AODV Overview AODV is a packet routing protocol designed for use in mobile ad hoc networks (MANET) Intended for networks that may contain thousands of nodes One of a class of demand-driven protocols The route discovery mechanism is invoked only if a route to a destination is not known *As a routing protocol for mobile ad hoc networks, AODV is intended to accommodate networks that are as large as several thousand nodes. *It is one of several demand-driven (or on-demand) protocols that are in existence today. Hence, the protocol is invoked only when a node (host) has data to transmit. It is a reactive protocol. *The AODV RFC indicates that the transport layer protocol is UDP, which of course only offers best effort delivery of packets, and does not support either error recovery or flow control. *Addressing is handled using IP addressing *Since each node acts as both a host and routing node, each must maintain a routing table that contains information about known destination nodes. Entries are keyed to destinations.

Ad-hoc On-demand Distance Vector (AODV) Charles E. Perkins, 1999 Reactive protocol Fast discovery Loop free On-demand

Unicast Route Establishment Unicast route is a route from a source node to a destination node. this protocols uses two types of messages, route request (RREQ) and route reply (RREP). we use sequence numbers to keep track of recent routes. Every time a node sends a new message, it uses a new sequence number which increases monotonically.

AODV Routing There are two phases Route Discovery. Route Maintenance. Each node maintains a routing table with knowledge about the network. AODV deals with route table management. Route information maintained even for short lived routes – reverse pointers.

AODV Route Discovery Destination Starting Point

AODV Route Discovery

AODV Route Discovery

AODV Route Discovery

AODV Route Discovery

AODV Route Discovery

AODV Route Discovery

AODV Route Discovery

AODV Route Maintenance AODV Route Maintenance Broken Link in Route

AODV Route Maintenance

Overview (continued) The basic message set consists of: RREQ – Route request RREP – Route reply RERR – Route error HELLO – For link status monitoring The basic message set includes a route request message, route reply message, route error message, and a hello message. The mechanics of each of these messages will be covered in detail later in the presentation. Briefly, however, a host (node) multicasts a RREQ message when it needs to find a route to a destination (either not already contained in its routing table, or one whose status is invalid).

AODV Operation – Message Types RREQ Messages While communication routes between nodes are valid, AODV does not play any role. A RREQ message is broadcasted when a node needs to discover a route to a destination. As a RREQ propagates through the network, intermediate nodes use it to update their routing tables (in the direction of the source node). The RREQ also contains the most recent sequence number for the destination. A valid destination route must have a sequence number at least as great as that contained in the RREQ.

Route Request (RREQ) Message Format

A B? B? B? B? B? B? B? B RREQ Message Make sure you explain how an intermediate node distinguishes between copies of the same RREQ. In your graph, the node in the middle receives two copies of the RREQ. In this case, the hop count from the source (A) is the same, so it doesn’t matter how its own routing back to A is updated. If you look at the example graph I included in the overview, you see that node B and the destination node F both receive multiple copies of the RREQ. In both cases, each copy followed a different route to get to the respective node. Therefore, B and F must choose the correct version of the message to use for updating their own routing tables and also for forwarding. The hop count field is the key that allows them to decide which message to keep and which message to throw away. B? B? B

AODV Operation – Message Types RREP Messages When a RREQ reaches a destination node, the destination route is made available by unicasting a RREP back to the source route. A node generates a RREP if: It is itself the destination. It has an active route to the destination. Ex: an intermediate node may also respond with an RREP if it has a “fresh enough” route to the destination. As the RREP propagates back to the source node, intermediate nodes update their routing tables (in the direction of the destination node). You should point out that the RREQ/RREP mechanism depends on the assumption that links are symmetrical, or bidirectional.

Route Reply (RREP) Message Format

RREP Message A A A A A A A B

Route Error (RERR)– Message Types RERR Messages This message is broadcast for broken links Generated directly by a node or passed on when received from another node

Route Error (RERR) Message Format

AODV Operation – Message Types Hello Messages Hello Message = RREP with TTL = 1 This message is used for broadcasting connectivity information. Ex: If a neighbor node does not receive any packets (Hello messages or otherwise) for more than ALLOWED_HELLO_LOSS * HELLO_INTERVAL mseconds, the node will assume that the link to this neighbor is currently lost. A node should use Hello messages only if it is part of an active route.

Unicasting Point-to-point transmission from one device to another. Most transmissions (where one user connects with one source or other user at a time) is unicast. A source node wants to send a message to a destination node.

Multicasting However, in many situations a node wants to send a message to a group of nodes in the network. This is called multicasting and the group is called a multicast group.

Broadcasting Broadcasting is a special case of multicasting when all the nodes in the network is in the multicast group.

Route Request (RREQ) Message When node S wants to send a message to node D, S searches its route table for a route to D. If there is no route, S initiates a RREQ message with the following components : The IP addresses of S and D The current sequence number of S and the last known sequence number of D A broadcast ID from S. This broadcast ID is incremented each time S sends a RREQ message.

Processing a RREQ Message (I) The <broadcast ID, IP address> pair of the source S forms a unique identifier for the RREQ. Suppose a node P receives the RREQ from S. P first checks whether it has received this RREQ before. Each node stores the <broadcast ID, IPaddress> pairs for all the recent RREQs it has received.

Processing a RREQ Message (II) D P Q If P has seen this RREQ from S already, P discards the RREQ. Otherwise, P processes the RREQ : P sets up a reverse route entry in its route table for the source S. This entry contains the IP address and current sequence number of S, number of hops to S and the address of the neighbour from whom P got the RREQ.

Lifetime of a Route-Table Entry A lifetime is associated with the entry in the route table. This is an important feature of AODV. If a route entry is not used within the specified lifetime, it is deleted. A route is maintained only when it is used. A route that is unused for a long time is assumed to be stale.

Route Requests in AODV Y Z S E F B C M L J A G H D K I N Represents a node that has received RREQ for D from S

Broadcast transmission Route Requests in AODV Y Broadcast transmission Z S E F B C M L J A G H D K I N Represents transmission of RREQ

Route Requests in AODV Y Z S E F B C M L J A G H D K I N Represents links on Reverse Path

Reverse Path Setup in AODV Y Z S E F B C M L J A G H D K I N Node C receives RREQ from G and H, but does not forward it again, because node C has already forwarded RREQ once

Reverse Path Setup in AODV Y Z S E F B C M L J A G H D K I N

Reverse Path Setup in AODV Y Z S E F B C M L J A G H D K I N Node D does not forward RREQ, because node D is the intended target of the RREQ

Forward Path Setup in AODV Y Z S E F B C M L J A G H D K I N Forward links are setup when RREP travels along the reverse path Represents a link on the forward path

Handling More than one RREP An intermediate node P may receive more than one RREP for the same RREQ. P forwards the first RREP it receives and forwards a second RREP later only if : The later RREP contains a greater sequence number for the destination, or The hop-count to the destination is smaller in the later RREP Otherwise, it does not forward the later RREPs. This reduces the number of RREPs propagating towards the source.

Route Maintenance Once a unicast route has been established between two nodes S and D, it is maintained as long as S (source node) needs the route. If S moves during an active session, it can reinitiate route discovery to establish a new route to D. When D or an intermediate node moves, a route error (RERR) message is sent to S.

Route Maintenance 1 2 3 S D RERR 3´ The link from node 3 to D is broken as 3 has moved away to a position 3´. Node 2 sends a RERR message to 1 and 1 sends the message in turn to S. S initiates a route discovery if it still needs the route to D.

Updating Route Tables 1 2 3 S D RERR 3´ 4 5 Suppose neighbours 4 and 5 route through 2 to reach D. Node 2 broadcasts RERR to all such neighbours. Each neighbour marks its route table entry to D as invalid by setting the distance to infinity.

Updating Route Tables 1 2 3 S D RERR 3´ 4 5 Each neighbour in turn propagates the RERR message. Route entries with an infinity metric are not rejected immediately as they contain useful routing information for the neighbourhood.

Local Connectivity Neighbourhood information is obtained through hello messages. Each node broadcasts a hello message to its neighbours at a regular hello-interval. When a node M receives a hello message from a neighbour N, node M updates the lifetime associated with N in its route table. Hello messages propagate only for one hop, in the neighbourhood of a node.

Performance of AODV AODV does not retransmit data packets that are lost and hence does not guarantee packet delivery. However, the packet delivery percentage is close to 100 with relatively small number of nodes. The packet delivery percentage drops with increased moility.

Control Overheads The overhead packets in AODV are due to RREQ, RREP and RERR messages. AODV needs much less number of overhead packets compared to DSDV. The number of overhead packets increases with increased mobility, since this gives rise to frequent link breaks and route discovery.

Latency in Route Discovery The route discovery latency in AODV is low compared to DSR and DSDV. The latency is almost constant even with increased mobility if the concentration of the nodes remain similar. The average path length for discovered routes is also quite low.

AODV: Summary Routes need not be included in packet headers Nodes maintain routing tables containing entries only for routes that are in active use At most one next-hop per destination maintained at each node DSR may maintain several routes for a single destination Sequence numbers are used to avoid old/broken routes Sequence numbers prevent formation of routing loops Unused routes expire even if topology does not change