6  DSDV Route Updates and Convergence

emerging-paradigms
adhoc
dsdv
operation

6.1 Start Simple

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

6.3 DSDV Updates Before Demand

Destination-Sequenced Distance Vector routing keeps a table of next-hop routes at every node. Nodes advertise table entries to neighbors, and neighbors decide whether the advertised route is fresher or better than the route they already hold.

The important operational idea is simple: DSDV pays continuous control overhead so a node can forward immediately when an application packet arrives. Route updates are not a side task. They are the protocol’s main contract.

That contract has two rhythms. Periodic updates give neighbors a regular view of the table, even if no obvious topology change has happened. Triggered updates carry urgent news sooner, such as a broken next hop, a newly learned route, or an invalidation that should displace stale good news. A field review should identify both rhythms because they stress the network differently: periodic updates create predictable baseline overhead, while triggered updates reveal how the mesh behaves during failures, movement, or noisy links.

The route choice itself is staged. A receiving node checks destination sequence freshness before it trusts a shorter metric. Only when two advertisements describe the same freshness generation does hop count decide the winner. When a link fails, the affected routes must be advertised as unreachable with newer freshness so neighbors stop forwarding toward the dead next hop. In other words, DSDV operation is a loop of maintaining tables, comparing freshness, invalidating broken state, and measuring whether the update stream stays affordable for the IoT workload.

A strong operator trace therefore shows one quiet interval, one triggered change, and the table row before and after each decision, so route readiness is tied to observable evidence rather than protocol labels.

DSDV routing concept showing proactive table maintenance across an ad hoc network.
Figure 6.1: DSDV routing concept showing proactive table maintenance across an ad hoc network.

DSDV maintains routing state proactively so forwarding can use a table entry instead of starting route discovery.

6.3.1 Periodic Updates

Nodes send routing information on a schedule so neighbors can refresh table state even when no topology event was observed.

6.3.2 Triggered Updates

Important changes, such as a broken next hop or a new fresher route, can be advertised without waiting for the next scheduled update.

6.3.3 Freshness Rule

A route with a newer destination sequence number wins. If sequence numbers match, the route with the lower metric wins.

6.3.4 Invalidation Rule

A detected broken route is advertised with an unreachable metric and a newer sequence value so stale good news is displaced.

Review Rule

Do not approve a DSDV design from a topology diagram alone. The review needs update triggers, freshness handling, broken-route handling, and convergence evidence.

6.4 Practitioner: Trace the Update Decision

A practitioner should review DSDV as a set of table decisions. When an advertisement arrives, the receiving node checks destination, next hop, metric, sequence number, and local route state. It installs the advertisement only when the freshness and metric rules justify the change.

The same discipline applies to failures. When a node loses a neighbor, routes that depended on that neighbor must be invalidated, advertised as unreachable, and replaced only when an alternate route with acceptable freshness appears.

DSDV link-failure handling on an eight-node network where the link between Node D and Node F breaks: a four-step protocol response detects the failure, sets the metric to infinity, increments the sequence number, and broadcasts the update, with sequence numbers preventing routing loops during recovery.
Figure 6.2: When a link breaks, DSDV invalidates the route: the detecting node sets the metric to infinity, increments the destination sequence number, and broadcasts the update so neighbors stop using the dead path.

Every DSDV update review should name the table fields that decide whether a route is installed, ignored, or invalidated.

6.4.1 Update Review Flow

Step Review action
Receive route advertisement Identify destination, advertising neighbor, metric, sequence number, and whether the route is normal or invalidating.
Compare freshness Prefer the route with the newer destination sequence number; ignore older advertisements unless policy says otherwise.
Compare metric When freshness is equal, prefer the route with the lower metric after accounting for the hop through the advertising neighbor.
Record propagation If the local table changes, decide whether a triggered update is required and what evidence proves neighbors received it.

6.4.2 Update Evidence Ledger

Event Table action Evidence needed Risk if missing
Scheduled refresh Advertise current route entries so neighbors eventually correct stale state. Configured interval, table size, radio load, and neighbor reception evidence. Hidden overhead or stale routes remain invisible until packets fail.
New route appears Install it only if freshness wins, or if freshness ties and the metric is better. Received advertisement, local prior route, sequence comparison, metric comparison, and final table row. Loops or route oscillation from accepting stale or worse entries.
Neighbor disappears Invalidate affected routes through that next hop and advertise unreachable state with newer freshness. Neighbor-loss trigger, affected destinations, invalidation update, and downstream acknowledgements or observations. Packets keep flowing toward a dead next hop.
Alternate route arrives Accept only when the alternate route satisfies freshness and metric policy after the invalidation. Alternate advertisement, sequence value, metric, next-hop proof, and convergence observation. A node may return to a stale path or remain disconnected longer than expected.

6.5 Convergence as State Audit

Under the hood, DSDV convergence is not just the moment one node changes a table row. It is the interval between a topology change and the point where affected nodes have consistent, loop-free forwarding state for the destination.

Triggered updates can reduce delay, but they do not remove the need to measure propagation. Wireless loss, hidden terminals, neighbor timeout policy, table size, update suppression, and rapid mobility can all make the observed convergence differ from a simple hop-count story.

DSDV timing variant showing route advertisement, invalidation, alternate route, and convergence evidence stages.
Figure 6.3: DSDV timing variant showing route advertisement, invalidation, alternate route, and convergence evidence stages.

Convergence evidence should show when stale state is invalidated and when the selected alternate path becomes stable.

6.5.1 State Boundaries to Verify

Boundary What to inspect Failure mode Retest trigger
Neighbor detection Hello, beacon, link-layer, or receive-timeout policy plus evidence that the neighbor really disappeared. False failure reports from interference or congestion create unnecessary invalidations. Radio setting, mobility rate, congestion, timeout, or link-layer policy changes.
Invalidation propagation Affected destinations, unreachable metric, newer sequence value, triggered update, and neighbor table result. Stale working routes survive and keep forwarding traffic into the failed link. Table format, update suppression, sequence handling, or retransmission policy changes.
Alternate route acceptance Alternate advertisement, freshness comparison, metric comparison, selected next hop, and observed packet path. A node accepts a stale alternate path or oscillates between neighbors. Mobility, density, link asymmetry, or route dampening policy changes.
Control overhead Update size, update frequency, radio duty, neighbor count, and application traffic impact. Routing updates consume energy or airtime that the sensor workload needs. Node count, report cadence, table size, topology churn, or radio rate changes.
Common Pitfall

Do not treat a single clean route update as proof of convergence. The evidence must include stale-route removal, alternate-route selection, and control-overhead impact.

6.5.2 Release Evidence Checklist

  • Record periodic and triggered update conditions for the deployment.
  • Show route-table decisions for new routes, stale routes, and invalidated routes.
  • Capture at least one broken-next-hop event and the resulting invalidation propagation.
  • Measure observed convergence under representative mobility, interference, and node density.
  • Compare routing-control overhead with the application traffic and power budget.
  • List retest triggers for node count, update timing, radio settings, mobility, firmware, and topology changes.

6.6 Summary

DSDV maintains route tables proactively so forwarding can use a ready next hop. Periodic updates refresh state, while triggered updates propagate important route changes sooner. Route selection uses destination sequence freshness first, then metric when freshness ties. Broken routes should be invalidated with an unreachable metric and newer freshness so stale routes are displaced.

Convergence evidence needs table-state traces, forwarding observations, and control-overhead impact, not only a topology diagram.

6.7 Key Takeaway

Review DSDV operation as a table-state audit: prove update triggers, freshness decisions, broken-route invalidation, alternate-route acceptance, convergence timing, and routing overhead for the tested topology.

6.8 See Also