DSDV vs AODV comes down to when a route gets built. DSDV builds every route in advance, whether or not anyone needs it yet. So each node keeps a full table, listing every other destination, all the time. AODV instead waits. It searches for a route only once a node actually has data to send. Both protocols avoid loops with a destination sequence number, a mechanism AODV borrowed directly from DSDV. DSDV’s own numbers stay even; a broken link instead forces an odd number, meaning an infinite metric. For instance, in an eight-node network, DSDV maintains 56 table entries permanently. AODV, for the same route, installs just 9, and lets 3 of them expire unused. DSDV works better for a small, steady network. AODV instead scales better as a network grows and its nodes keep moving.
Picture a fleet of delivery drones with no cell tower in range. That describes a mobile ad hoc network, or MANET. A MANET builds its own network on the fly, with no fixed backbone. Every node can join, move, or drop out at any moment. So routing between any two nodes has to adapt fast.
This guide compares two influential routing protocols for MANETs: DSDV and AODV. One instead keeps a route ready in advance. The other searches only when a node actually needs one. A single worked example, an eight-node network, then shows exactly where the overhead in each protocol goes.
Two Families of Ad Hoc Routing
Ad hoc routing protocols split into two broad families. Our guide to proactive vs reactive routing protocols covers that split in full. DSDV belongs to the proactive family: it builds routes in advance. AODV belongs to the reactive family: it builds a route only on demand.
DSDV came first, published in 1994. AODV came later, standardized as an RFC in 2003. Both protocols also use a destination sequence number to stay loop-free. The next two sections then walk through each one in turn.
How DSDV Works
DSDV stands for Destination-Sequenced Distance-Vector routing. Perkins and Bhagwat first published it at ACM SIGCOMM in 1994. DSDV is proactive, so every node keeps a table for every destination, at all times. Nothing needs to be sending data for that table to exist.
Each routing-table entry holds five fields:
- destination address
- next-hop neighbour
- hop-count metric
- destination sequence number
- install time
The metric itself is just hop count. DSDV sends two kinds of updates: a full dump and an incremental update. A full dump carries the whole table, so it may need several network protocol data units. Because of that size, DSDV sends a full dump only now and then.
An incremental update instead carries only the entries that changed since the last full dump. That smaller message fits inside a single NPDU, so DSDV sends it far more often. DSDV also broadcasts an update right away, after any significant change, such as a broken link. So DSDV is never purely periodic.
Still, all that bookkeeping carries a real price. Periodic updates plus triggered updates push total overhead high. After a failure, convergence can also take a prolonged exchange of updates. DSDV’s overhead gets worse as the network grows, or as nodes move faster.
ns-3’s own DSDV model still uses hop count as its metric, with updates every 15 seconds by default. DSDV itself was never published as an RFC.
How AODV Works
AODV stands for Ad hoc On-Demand Distance Vector routing. Perkins, Belding-Royer, and Das first described it at WMCSA in 1999, in New Orleans. AODV later became RFC 3561, published in July 2003. Even so, that RFC carries the Experimental label, not Standards Track.
AODV is reactive, so a node holds a route only while it needs one. Routing runs hop-by-hop, with one routing-table entry per destination. That is not source routing; our AODV vs DSR comparison covers that different approach in full.
AODV defines four message types, each with its own type code:
- RREQ, type code 1
- RREP, type code 2
- RERR, type code 3
- RREP-ACK, type code 4
Route discovery starts with the originator incrementing its own sequence number. It then broadcasts an RREQ. Every node that receives the RREQ creates or updates a reverse route back toward the originator. The destination, or an intermediate node with a fresh enough route, unicasts an RREP in reply. As that RREP travels back, each forwarding node installs a forward route toward the destination.
A node rebroadcasts an RREQ only when the incoming TTL is greater than 1. So AODV does not necessarily flood the whole network on the first try. Instead, RFC 3561 recommends an expanding ring search. That search starts at TTL_START and grows by TTL_INCREMENT after each timeout. Once the TTL reaches TTL_THRESHOLD, which is 7, AODV uses NET_DIAMETER instead. Meanwhile, every node buffers the RREQ ID for PATH_DISCOVERY_TIME, so duplicate copies get discarded.
Every route entry also carries a lifetime, and it expires once unused. RFC 3561 gives an exact reverse-route lifetime formula: current time, plus twice NET_TRAVERSAL_TIME, minus twice HopCount times NODE_TRAVERSAL_TIME. HELLO messages remain optional in AODV, simply an RREP sent with TTL equal to 1. Even so, once a node enables HELLO messages, it does emit a periodic beacon.
RFC 3561 fixes nine default values for these parameters:
| Parameter | Default |
|---|---|
| ACTIVE_ROUTE_TIMEOUT | 3,000 ms |
| HELLO_INTERVAL | 1,000 ms |
| NET_DIAMETER | 35 |
| NODE_TRAVERSAL_TIME | 40 ms |
| RREQ_RETRIES | 2 |
| TTL_START | 1 |
| TTL_INCREMENT | 2 |
| TTL_THRESHOLD | 7 |
| ALLOWED_HELLO_LOSS | 2 |
Four more numbers combine from these defaults. NET_TRAVERSAL_TIME is 2 times 40 times 35, or 2,800 ms. PATH_DISCOVERY_TIME then doubles that figure, to 5,600 ms. MY_ROUTE_TIMEOUT instead doubles ACTIVE_ROUTE_TIMEOUT, to 6,000 ms. DELETE_PERIOD equals 5 times the larger of ACTIVE_ROUTE_TIMEOUT or HELLO_INTERVAL, or 15,000 ms.
Sequence Numbers: The Idea AODV Borrowed
Classical distance-vector routing, plain Bellman-Ford, suffers from one nasty weakness: counting to infinity. A stale route can loop forever between two nodes, each one believing the other still has a path. Our distance vector vs link state guide explains that weakness in full. DSDV fixes it with one addition: a destination sequence number on every route.
Two rules settle every comparison, in order. A higher or more recent sequence number always wins. When two numbers tie, the smaller metric wins instead. Sequence numbers also carry a strict parity: a destination’s own numbers stay even. Any odd value instead marks something else entirely, an infinite metric.
Only one case breaks that even-number pattern. When a link to a next hop fails, the node that notices assigns every route through it an infinite metric. That node also generates a new, odd sequence number for each affected route. So, just this once, the sequence number comes from somewhere other than the destination itself.
DSDV also tracks a settling time for each destination. That figure is a running average of how long the best route usually takes to arrive. A brand-new destination gets advertised right away, with no delay at all. An improved but not brand-new route instead waits roughly twice that average, before DSDV advertises it. That short delay damps fluctuation, instead of announcing every tiny improvement immediately.
AODV borrows the destination sequence number from DSDV. It never adopts the settling time, though. Before starting any route discovery, a node must first increment its own sequence number. During route discovery, a higher destination sequence number always signals a fresher route, exactly as it does in DSDV. So the single most interesting shared idea between these two protocols is this one number.
DSDV vs AODV: Comparison Table
The table below lines up every major contrast, side by side.
| Aspect | DSDV | AODV |
|---|---|---|
| Protocol family | Proactive, table-driven | Reactive, on-demand |
| When routes are computed | Continuously, in advance | Only when a node needs one |
| RFC status | Never published as an RFC | RFC 3561, Experimental (2003) |
| Routing-table contents | Destination, next hop, hop count, sequence number, install time | One entry per destination, hop-by-hop |
| Table size (8-node example) | 56 entries, network-wide | 9 entries installed for one route |
| Metric | Hop count | Hop count, paired with a sequence number |
| Sequence-number origin | The destination, except on a broken link | The originator, incremented before every discovery |
| Sequence-number parity | Even means own number, odd means infinite metric | No parity rule; just increments before discovery |
| Update mechanism | Full dump, incremental, plus triggered updates | RREQ, RREP, and RERR per discovery |
| Control traffic when idle | Constant; periodic broadcasts continue regardless | Optional HELLO; none unless enabled |
| Route discovery latency | None; the route already sits in the table | Bounded by an expanding ring search, up to 5,600 ms |
| Link-break signalling | Infinite metric plus a new odd sequence number | An RERR message, type code 3 |
| Loop prevention | Destination sequence numbers, the original mechanism | The same sequence-number rule, borrowed from DSDV |
| Route lifetime | Entries persist, until a better sequence number arrives | Expires; ACTIVE_ROUTE_TIMEOUT defaults to 3,000 ms |
| Memory profile | One entry for every other node, always | Entries only for destinations reached recently |
| Scalability limit | Overhead and convergence worsen as size or mobility grow | State grows with active destinations, not total nodes |
| Best-fit network | Small, relatively static networks | Larger, more mobile networks |
Worked Example: One Route in an Eight-Node Network
Picture eight nodes, labelled A through H. Exactly eight links connect them: A-B, B-C, B-D, C-E, C-F, D-G, G-H, and E-F. Node A needs a route to node F.
Hop distances from A work out like this: B is 1 hop, C and D are 2 hops each, E, F, and G are 3 hops each, and H sits 4 hops away. So the shortest path from A to F is A-B-C-F, just three hops.
DSDV side. DSDV keeps an entry for every other destination, at every node. That is 8 nodes times 7 entries, or 56 routing-table entries, maintained across the whole network, permanently. Over 60 seconds, at the default 15-second interval, that is four rounds across all eight nodes, or 32 full-table broadcasts. Those 32 broadcasts carry 4 times 8 times 7, or 224 entry advertisements, even though zero data is flowing.
AODV side. A broadcasts an RREQ. Take the attempt at TTL equal to 3, once the expanding ring search has grown past TTL_START. Four nodes rebroadcast it, because their incoming TTL exceeded 1: A, B, C, and D. Six nodes receive it and create a reverse route back toward A instead: B, C, D, E, F, and G. H sits four hops out, so it never receives the request at all.
F is the destination, so it unicasts an RREP back along F, then C, then B, then A. Each node that receives that RREP installs a forward route to F: C, B, and A. In total, AODV installs nine entries for this single route.
Six of those entries stay in use: A’s forward route, B’s reverse and forward routes, C’s reverse and forward routes, and F’s reverse route. Three entries instead expire unused. D’s reverse route, two hops out, expires at 5,600 minus 160, or 5,440 ms. E’s and G’s reverse routes, three hops out, each expire at 5,600 minus 240, or 5,360 ms.
The headline contrast is stark. DSDV maintains 56 entries permanently. AODV installs 9, keeps 6, and lets 3 expire.
Where the Overhead Actually Goes
Go back to the eight-node example above. DSDV paid its cost up front: 56 entries, refreshed by 32 broadcasts every 60 seconds, whether or not any data ever moves. AODV instead paid nothing until node A actually needed node F.
Its entire cost sat inside one route discovery: 9 entries installed, only 6 of them ever used. So the real question is not simply which protocol costs less. It is whether that cost sits inside a permanent table, growing with every node in the network. Or it sits inside a single discovery, growing only with how often routes actually change.
One more cost sits outside both totals. AODV’s HELLO messages remain optional, but once enabled, they add a steady beacon of their own, every 1,000 ms by default.
When to Use Which
DSDV suits a small, relatively static network. Its constant table upkeep is easy to tolerate only while the network stays small and calm. AODV instead fits a larger, more mobile network.
The worked example above makes the reason clear: 56 permanent entries against 9 entries created on demand. Known DSDV literature also states it plainly: overhead and convergence time both worsen as a network grows or its nodes speed up. Neither protocol wins in every situation; the right pick depends on network size and how often nodes move.
Interview Questions
Frequently Asked Questions
Wrapping Up
DSDV and AODV both route traffic across a MANET, just on opposite schedules. DSDV keeps a full table ready at every node, all the time. AODV instead waits, then searches only when a node actually needs a route.
Remember the exam essentials. Sequence numbers began in DSDV, then AODV borrowed the same idea. An odd DSDV number always means an infinite metric, not simply an old route. AODV searches with an expanding ring, never a blind flood. Neither protocol wins outright; the right pick depends on network size and mobility.
Related reading on DiffStudy:
- Proactive vs Reactive Routing Protocols
- AODV vs DSR Routing Protocols
- Cellular Network vs Ad Hoc Network
- Distance Vector vs Link State Routing
