4 DSDV Proactive Routing

4.1 Start Simple

This section: Start Simple — Picture a rescue node that forwards immediately but uses yesterday’s next hop after the team moves.

Watch One Ready Route Become Stale

Picture a rescue node that forwards immediately but uses yesterday’s next hop after the team moves. A ready table helps only when changes and invalid routes are visible.

A protocol means an agreed set of message and behavior rules used by communicating systems.

Send a marked packet on a stable path, move one relay, and send again during and after convergence. Keep node identities, protocol and table versions, sequence number, metric, next hop, update time, delivery, loss, and recovery result.

This test covers selected movement and routes, not every mobile network. The deeper sections explain advertisements, sequence numbers, metrics, settling, loops, overhead, and route expiry.

4.2 Start With a Route Table That Is Ready Before Demand

This section: Start With a Route Table That Is Ready Before Demand — DSDV tells the network to keep routes ready before a packet asks for them.

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.

4.3 DSDV Updates for Ready Routes

This section: DSDV Updates for Ready Routes — Destination-Sequenced Distance Vector (DSDV) is a proactive ad-hoc routing protocol.

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.

+

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

4.4 DSDV Route-Freshness Contract

This section: 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.

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.

+

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

4.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.

+

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

Inspect Figure 4.4 and ask why destination freshness is compared before hop count at node D.

+

Read Figure 4.4 from the next-hop map into node D’s route entries. Destinations A and B forward through B, while E and G use F, so the table turns a multi-hop topology into one immediate action per destination. Hop count estimates distance, but the destination sequence number records freshness. The comparison $42>40$ shows why a newer advertisement wins even when an older path might look shorter; hop count breaks ties only within the same freshness generation. This ordering prevents a stale route from displacing current knowledge after movement. The table therefore supports DSDV’s operating bargain: forwarding is immediately available, provided periodic updates keep sequence state current and invalid routes are withdrawn.

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

4.5 DSDV Sequence Numbers

This section: DSDV Sequence Numbers — Classic distance-vector routing can form loops when neighbors advertise outdated reachability after a link fails.

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.

Use Figure 4.5 to separate DSDV’s ready-route gain from its update cost by tracing the stored table and selection rule into the forward result.

+

Read Figure 4.5 from the table entry to the comparison rule. Check the destination sequence number first, then use hop count only to break a tie within the same freshness generation, and finally follow the selected next hop into forwarding. This explains why data forwarding is simple after convergence while the control plane must keep paying to refresh and invalidate route state.

+

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

4.6 Summary

This section: Summary — DSDV is a proactive distance-vector protocol for ad-hoc networks.

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.

4.7 Key Takeaway

This section: Key Takeaway

4.8 See Also

This section: See Also