4 DSDV Proactive Routing

4.1 Start Simple

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.

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.

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

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

Before DSDV Updates for Ready Routes, inspect Figure 4.1 to compare “Ad-Hoc Network Topology” with “Source nodes”. Their juxtaposition makes ad-hoc mesh with wireless nodes connected through peer-to-peer multi-hop links visible.

Read Figure 4.1 from “Ad-Hoc Network Topology” to “Source nodes”. Taken together, “Ad-Hoc Network Topology” and “Source nodes” express ad-hoc mesh with wireless nodes connected through peer-to-peer multi-hop links. For DSDV Updates for Ready Routes, the observed relationship between “Ad-Hoc Network Topology” and “Source nodes” is evidence that “Ad-Hoc Network Topology” carries into the next decision.

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

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

Before DSDV Route-Freshness Contract, inspect Figure 4.2 to compare “Forward to” with “F-H”. Their juxtaposition makes DSDV routing table with destination, next hop, hop count, and sequence number fields visible.

Read Figure 4.2 from “Forward to” to “F-H”. Taken together, “Forward to” and “F-H” express DSDV routing table with destination, next hop, hop count, and sequence number fields. For DSDV Route-Freshness Contract, the observed relationship between “Forward to” and “F-H” is evidence that “Forward to” carries into the next decision.

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.

Before DSDV Review Ledger, inspect Figure 4.3 to compare “E-G” with “D-B”. Their juxtaposition makes node D’s DSDV neighbor graph maps the route table to direct neighbors B and F visible.

Read Figure 4.3 from “E-G” to “D-B”. Taken together, “E-G” and “D-B” express node D’s DSDV neighbor graph maps the route table to direct neighbors B and F. For DSDV Review Ledger, the observed relationship between “E-G” and “D-B” is evidence that “E-G” carries into the next decision.

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

Before DSDV Review Ledger, inspect Figure 4.4 to compare “D → B → A” with “D → F → E”. Their juxtaposition makes node D routing table with next-hop, hop-count, and sequence-number entries for neighboring destinations visible.

Read Figure 4.4 from “D → B → A” to “D → F → E”. Taken together, “D → B → A” and “D → F → E” express node D routing table with next-hop, hop-count, and sequence-number entries for neighboring destinations. For DSDV Review Ledger, the observed relationship between “D → B → A” and “D → F → E” is evidence that “D → B → A” carries into the next decision.

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

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

Use Figure 4.5 to separate DSDV’s readiness benefit from the update cost paid to obtain it. The visual puts the stored route table and its selection rule beside the forwarding outcome, so freshness is visible before distance.

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 forwarding is simple after convergence while the control plane must keep paying to refresh and invalidate route state.

Before DSDV Sequence Numbers, inspect Figure 4.6 to compare “Phase 2” with “sequence”. Their juxtaposition makes timeline of periodic DSDV updates, link failure, triggered update, and reconvergence visible.

Read Figure 4.6 from “Phase 2” to “sequence”. Taken together, “Phase 2” and “sequence” express timeline of periodic DSDV updates, link failure, triggered update, and reconvergence. For DSDV Sequence Numbers, the observed relationship between “Phase 2” and “sequence” is evidence that “Phase 2” carries into the next decision.

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

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

4.7 Key Takeaway

4.8 See Also