5  DSDV Proactive Routing

5.1 Start Simple

Start with devices that have to pass useful data before any fixed network is guaranteed. In DSDV Proactive Routing, the first question is not the protocol name; it is which neighbors, routes, failure signals, and degraded behaviors you would trust in the field.

5.2 Start With a Route Table That Is Ready Before Demand

DSDV tells the network to keep routes ready before a packet asks for them. Each node maintains destination entries, sequence numbers, and next hops so forwarding can happen quickly when data arrives.

That promise is useful only when the cost of constant upkeep fits the IoT deployment. Start with one destination entry and ask how the node knows it is fresh. The sequence-number story is the heart of DSDV.

In 60 Seconds

Destination-Sequenced Distance Vector (DSDV) is a proactive ad-hoc routing protocol. It keeps route tables ready before traffic arrives, so forwarding can begin with a table lookup instead of an on-demand route discovery flood. The benefit is low first-packet delay. The cost is ongoing table maintenance, route advertisements, receive time, memory, and convergence work after topology changes.

Minimum Viable Understanding

• DSDV maintains routes continuously: each node tracks a next hop, hop count, and destination sequence number for known destinations.
• Freshness wins before distance: newer destination sequence numbers are preferred before hop count is considered.
• Ready routes have upkeep: periodic and triggered updates consume airtime and energy even when application traffic is quiet.
• Failure drills must prove convergence: a valid review shows stale-route invalidation, replacement route adoption, and bounded recovery time.

5.3 DSDV Updates for Ready Routes

Destination-Sequenced Distance Vector (DSDV) is a proactive ad-hoc routing protocol. Each node keeps a table for every known destination, including the next hop, hop count, and a destination sequence number. When an application has a packet to send, the node can forward immediately from the table instead of first flooding a route discovery request.

That ready-route behavior is useful only when the network can afford the maintenance cost. DSDV is easiest to defend in relatively stable ad-hoc IoT networks where many nodes communicate often enough that low route-lookup delay matters. It is harder to justify when traffic is rare, nodes move quickly, or battery and airtime budgets cannot absorb repeated table exchanges.

Think of DSDV as a promise between neighbors: “I will keep telling you what I know about every destination, and I will mark that knowledge with a freshness number.” The route table is not a cache that fills only after use. It is a maintained control-plane data structure. That distinction matters for IoT devices because a quiet sensor still has to spend receive time, table memory, and processing budget to keep the mesh ready for traffic that may never arrive.

The practical question is whether the saved route-discovery delay is visible to the service. A mobile robot team exchanging coordination messages, a temporary field mesh with awake relays, or a warehouse cart network may benefit from immediate forwarding. A sleepy star-like telemetry estate usually does not. The learner should evaluate DSDV by pairing every benefit with the upkeep that creates it: route entries require memory, advertisements require airtime, listening requires energy, and topology changes require fresh sequence-number propagation.

Figure 5.1: Ad-hoc mesh with wireless nodes connected through peer-to-peer multi-hop links

DSDV assumes an infrastructure-free mesh where neighbors can relay for each other.

5.3.1 Route Already Known

Forwarding starts with a table lookup. This reduces first-packet delay compared with protocols that discover a path on demand.

5.3.2 Freshness Before Distance

Higher destination sequence numbers win before hop count is considered. A fresh longer path is safer than a stale shorter path.

5.3.3 Continuous Control Cost

Nodes exchange route information even when the application is quiet, so control traffic competes with useful data and listening time.

5.3.4 Topology Sensitivity

Fast movement or unstable links can make tables age faster than the network can converge.

Design Question

Choose DSDV only when the value of immediate forwarding is worth the periodic and triggered update burden.

5.4 DSDV Route-Freshness Contract

A DSDV design review should not stop at “the table has a path.” The review has to prove that each node can maintain fresh enough route state for the service. That means recording route entries, update cadence, link-change triggers, stale-route handling, and the measured cost paid by relay nodes.

Use the table as a contract, not just a display. For each important destination, the reviewer should be able to explain why the selected next hop is current, why an older shorter path was rejected, what happens when that next hop fails, and how much route-maintenance traffic the device must hear while doing its sensing or control work. This makes the review concrete enough to compare against DSR, AODV-style discovery, a static route set, or a gateway tree.

Figure 5.2: DSDV routing table with destination, next hop, hop count, and sequence number fields

A DSDV table is useful because it combines next-hop reachability with a freshness number.

5.4.1 DSDV Review Ledger

Review item	What to capture	Approval evidence	Failure sign
Traffic fit	Which nodes talk often, which flows need low first-packet delay, and which flows can tolerate discovery delay.	Frequent traffic makes ready tables useful in the actual operating pattern.	Most updates maintain routes that the application rarely uses.
Table state	Destination, next hop, hop count, sequence number, and the age of the installed route.	Route entries change predictably when neighbors move, fail, or recover.	Stale entries survive because update loss or settling time hides topology changes.
Update burden	Periodic update interval, triggered update behavior, packet size, radio duty cycle, and relay energy.	Control traffic stays below the airtime and energy budget under representative traffic.	Routing maintenance consumes more capacity than the useful sensor or control traffic can tolerate.
Recovery drill	Broken-link detection, infinity metric propagation, replacement route adoption, and operator-visible telemetry.	Nodes stop using the failed path and converge on a valid alternative within the service tolerance.	Nodes keep forwarding into a black hole or oscillate between stale alternatives.

Figure 5.3: Node D’s DSDV neighbor graph maps the route table to direct neighbors B and F

A route review should map table entries back to the actual neighbor graph, not just to protocol labels.

Figure 5.4: Node D routing table with next-hop, hop-count, and sequence-number entries for neighboring destinations

Node D can forward immediately because it already has next-hop entries for the network.

5.5 DSDV Sequence Numbers

Classic distance-vector routing can form loops when neighbors advertise outdated reachability after a link fails. DSDV adds destination sequence numbers so nodes can identify which advertisement is newer. The destination normally advances its own sequence number for valid routes, and broken routes are advertised with a newer sequence number and an infinite metric so neighbors stop using the old path.

The update stream has two parts. Periodic updates keep the table synchronized during normal operation. Triggered updates spread important changes faster when a link fails or a route becomes unavailable. Some implementations also damp updates so brief instability does not create repeated oscillation. These mechanisms improve correctness, but they do not remove the basic cost: every node stores and advertises route state for many destinations.

The subtle point is that freshness and distance are separate decisions. A lower hop count is attractive only after the sequence number says the route information belongs to the same freshness generation. If a two-hop route has an older destination sequence number than a three-hop route, the two-hop path may simply be a stale story about a topology that no longer exists. That is how DSDV avoids many count-to-infinity failures that ordinary distance-vector protocols can suffer after a link break.

The cost of that safety is propagation discipline. A failure has to be detected, converted into an unreachable metric with newer freshness information, and carried far enough that neighbors stop preferring old good news. If updates are lost, delayed, or suppressed too aggressively, the table can look complete while packets still follow a dead next hop. Under-the-hood testing therefore watches sequence numbers, invalidation messages, and selected next hops over time, not just the final path after the network has settled.

Figure 5.5: DSDV keeps routes ready and selects the next hop by rule: a newer destination sequence number wins, and hop count breaks ties.

Forwarding is simple after convergence: look up the destination, select the next hop, and send.

Figure 5.6: Timeline of periodic DSDV updates, link failure, triggered update, and reconvergence

Failure recovery depends on how quickly newer route information replaces stale entries.

5.5.1 Fresh Route Rule

If a received advertisement has a higher destination sequence number, the node treats it as newer and can replace the old entry even when the hop count is larger.

5.5.2 Equal Freshness Rule

If sequence numbers match, the lower hop count wins because both routes describe the same destination freshness generation.

5.5.3 Broken Route Rule

A failed next hop is advertised with an infinite metric and a newer sequence number so stale neighbors do not keep selecting it.

5.5.4 Scale Rule

Table memory and update traffic grow as the number of destinations grows, so the design must measure overhead for the real node count and update interval.

Sequence Number Scope

Do not treat DSDV sequence numbers as application packet counters. Their role is route freshness and loop avoidance inside the routing control plane.

5.6 Summary

DSDV is a proactive distance-vector protocol for ad-hoc networks. It keeps route tables ready at each node, so forwarding can begin with a lookup instead of on-demand discovery. Its key protection is the destination sequence number: newer route information wins before hop count is considered, which helps nodes reject stale paths after topology changes.

The trade-off is continuous maintenance. Periodic and triggered updates consume airtime, energy, memory, and attention from relay nodes. DSDV is most defensible when the topology is fairly stable, traffic is frequent enough to benefit from ready routes, and fault drills prove that sequence-number updates suppress stale paths within the service tolerance.

5.7 Key Takeaway

Use DSDV when ready routes are worth the control-plane cost. Approve it with evidence for route freshness, update overhead, stale-route suppression, and recovery after real link changes.

5.8 See Also

• Ad-Hoc Multi-Hop Routing: compare DSDV with reactive and hybrid routing families before choosing a protocol.
• DSDV Protocol Operation: follow update timing, table changes, and topology-change behavior in more detail.
• DSDV Evaluation and Trade-Offs: review when proactive route maintenance becomes too expensive for the deployment.
• DSR Fundamentals and Route Discovery: contrast DSDV’s ready tables with an on-demand route discovery approach.