0% found this document useful (0 votes)
76 views22 pages

Adhoc On Demand DV

The document describes the Ad-hoc On-Demand Distance Vector (AODV) routing protocol. AODV is designed for ad-hoc networks that have no infrastructure and dynamic links. It uses an on-demand approach for route discovery, only setting up routes when needed. Routes are discovered through a route request/route reply query cycle and maintained through periodic beacons and route error messages until the destination is no longer reachable or needed. The protocol aims to be loop-free, self-starting, and scalable to large and dense networks.

Uploaded by

api-3761983
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
76 views22 pages

Adhoc On Demand DV

The document describes the Ad-hoc On-Demand Distance Vector (AODV) routing protocol. AODV is designed for ad-hoc networks that have no infrastructure and dynamic links. It uses an on-demand approach for route discovery, only setting up routes when needed. Routes are discovered through a route request/route reply query cycle and maintained through periodic beacons and route error messages until the destination is no longer reachable or needed. The protocol aims to be loop-free, self-starting, and scalable to large and dense networks.

Uploaded by

api-3761983
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 22

Ad-hoc On-Demand Distance

Vector (AODV)
By Charlie Perkins and Elizabeth Moyer

Computer Networks
Dr. Jorge A. Cobb
Ad-hoc Networks
 No infrastructure in the network
 All nodes capable of movement
 Links appear and disappear dynamically
 Special constraints:
• limited bandwidth
• limited power
• high error rates
 Protocol needed to create and maintain routes
 Conventional routing protocols not applicable

2
Desired Characteristics of an
Ad-hoc Routing Protocol
 Ability to find multi-hop paths
 Unicast, broadcast, and multicast routing ability
 Dynamic topology maintenance
 Ability to self-start
 Loop-freedom and rapid route convergence
 Low consumption of memory, bandwidth
 Scalable to large (1000) populations of nodes
 Minimal control overhead
 No data overhead

3
Ad-hoc On-Demand Distance Vector
Routing (AODV)
 Primary Objectives
• Provide unicast, broadcast, and multicast capability
• Initiate forward route discovery only on demand
• Disseminate changes in local connectivity to those
neighboring nodes likely to need the information

 Characteristics
• On-demand route creation, resulting in localized effect of
topology changes, and minimized control traffic
• Two dimensional routing metric: <Seq #, HopCount>
• Storage of routes in Route Table

4
Loop freedom
 Each node has a non-decreasing local
sequence number
 Each node also keeps track of the
largest sequence number it has seen (5,5)
A
from each destination.
 Recall that the metric to reach a (7,4)
destination is B
• <seq #, hop count>
 To ensure loop freedom, for every
node A whose next hop to D is B (i.e., (7,3)
A  B  …  D), we always have
the following
• seq # of D at A is ≤ seq # of D at B (8,1)
• If equal, the hop count at A to
reach D is greater than the hop
count at B to reach D
 You can argue that this ensures loop D (8,0)
freedom (why?)

5
Routing Table
 Fields:
• Destination IP Address
• Destination Sequence Number
• Hop Count
• Next Hop IP Address
• Active Neighbors
• Expiration time
 Each time a route entry is used to
transmit data, the expiration time is
updated to at least:
current_time + active_route_timeout
 Route entries may be updated if a better
route (i.e. with greater sequence number
or an equal sequence number with a
smaller hop count) is discovered

6
Route Discovery
 Route discovery is performed by broadcasting a
route-request (RREQ) message looking for the
destination
 The destination replies with a route-reply (RREP)

 Each node maintains a local broadcast_id number


• It is incremented every time a new RREQ is
broadcasted
• Used to eliminate redundant broadcasts

7
Route Discovery
 Source increases its local sequence number and
broadcast ID. Then, it broadcasts a Route Request
(RREQ)
 RREQ contains:
<Source_Addr, Source_Seq#, Broadcast_ID,
Dest_Addr, Dest_Seq#, Hop_Count>
 Nodes keep track of <Source_Addr,
Broadcast_ID>
and discards redundant broadcasts
 A node can reply to the RREQ if
• It is the destination, or
• It has a route to the destination with sequence
number at least Dest_Seq#
 Otherwise it rebroadcasts the RREQ after
increasing the hop count.
8
RREQ Propagation
bid,s#5,hc0
bid,s#5,hc0 S

9
RREQ Propagation
S (5,1)
S
bid,s#5,hc1
S (5,1)
S (5,2)

bid,s#5,hc1 bid,s#5,hc2

S (5,3)

bid,s#5,hc3

10
RREQ Propagation
S (5,1)
S

S (5,1)
S (5,2)

bid,s#5,hc4
X
S (5,3)
Y
S (5,4)
bid,s#5,hc2

Both X and Y discard each other’s RREQ since


D
the same (source, bcast_id) has been seen
before (i.e., Y will not learn of the shorter
path to S)
11
Reverse Route Entry Setup
 From the RREQ, nodes update their Route
Table with an entry for the source node.
• Destination IP Address = Source_Addr
• Destination Sequence Number =
Source_Seq#
• Hop Count = Hop_Count
• Next Hop IP Address = neighbor from
whom I received this RREQ
• Active Neighbors = empty
• Expiration time = current time +
active_route_timeout
 Reverse path entry used to forward Route
Reply (RREP) back to source if one is
received
 Expiration time is long enough for a RREP to
be received back at the source.

12
More details on processing a RREQ
 Dest_Seq# in the RREQ is the latest # known by the source
(perhaps 0)
 If the same bcast_id has been seen before, drop the message
(even if it has a lower hop count!)
 Since the source seq # is incremented before bdcasting the
RREQ, it is larger than the source seq # of any earlier RREQ.
• I.e., this will create a new path back to the source that
overrides any earlier paths created from a RREQ.
 Can a node receive a new RREQ with a source seq # smaller
than what you have seen before?
• Yes, if source did a RREP after doing the RREQ and the
RREP arrived before the RREQ (see later slides)
• Keep the information of the larger sequence # in this case.

13
Route Reply
 Destination, or intermediate node with current route
to destination, unicasts Route Reply (RREP) back
to source.

 If RREP is sent by the destination:


• The destination increases its sequence number
(if necessary) before sending RREP
• New value must be increased to at least the
Dest_Seq# of the RREQ.

 RREP contains:
<Source_Addr, Dest_Addr, Dest_Seq#,
Hop_Count, Lifetime>

14
Forward Route Entry Setup
 From the RREP, nodes along the path to
the source record in the Routing Table an
entry for the destination node:
• Destination IP Address = Dest_Addr
• Destination Sequence Number =
Dest_Seq#
• Hop Count = Hop_Count
• Next Hop IP Address = neighbor from
whom I received this RREP
• Active Neighbors = empty
• Expiration time = current time +
max(lifetime, active_route_timeout)
 Since routes are bidirectional, lifetime is
also applied to the table entry of the source
 Source can begin sending data when it
receives first RREP.

15
Optimization
 If the source later receives a RREP with better metric (larger
destination seq# or equal seq# but with smaller hop count), it
updates its route table entry.
• The source could be an intermediate node along the path
from the destination to ANOTHER source
• Actually, if at any time you see a RREP with a better metric
than what you have, you update your routing table from it.

 If you sent an early RREP (you are the intermediate node) then
• Also send a RREP to the destination of the RREQ
• This RREP has as a “destination” the source of the RREQ
• This will prevent the destination from bdcasting a RREQ
looking for the source.

16
Path Maintenance – Active Neighbors
 A routing table entry for a destination (i.e. a “path” to the
destination) is active if within the last active_route_timeout
seconds it has received a data message addressed to that
destination.

 The set of active neighbors of a routing table entry are all


those neighbors that have sent data messages addressed to
the destination within the last active_route_timeout seconds.

 Movement of nodes not along active path does not trigger


protocol action.

17
Path Maintenance (continued …)
 If source node moves,
• it can reinitiate route discovery.
 When destination or intermediate node moves along an active
path,
• Node upstream of break sends unsolicited RREP to all
active upstream neighbors
∀ ∞ hop count, with incremented Dest_Seq#
• Used to flush stale routes
 RREP is propagated to their active neighbors, and so on back
to source
 Source can reinitiate route discovery if route is still needed
• RREQs contains destination sequence number at least
greater than the RREP
18
Path Maintenance (continued)

 Node 3 moves to new location 3’


 Node 2 notices loss of link, sends link failure to Node 1
 Node 1 forwards link failure to Source
 Source reinitiates route discovery, finds new route through Node 4

19
Local Connectivity Management
 Node must periodically hear from its neighbors to know they
are still within range

 Eavesdrop on neighbor transmissions

 If no other transmissions within hello_interval, broadcast


Hello packet

 Failure to hear from a neighbor for


(1 + allowed_hello_loss) * hello_interval
indicates loss of link

20
Simulation Results
 If you are interested in these, please see the paper

 I will not hold you responsible for the simulations.

21
Concluding Remarks
 On-demand route establishment
 Minimum delay for route discovery
 Quick response to link breakage in active routes
 Maintenance of loop-free routes by use of destination sequence
numbers
 Scalable to large populations of nodes

Within the limits imposed by mobile, wireless networks, AODV is


an effective protocol for routing within ad-hoc networks.

22

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy