5 DSDV Route Updates and Convergence
5.1 Start Simple
Prove a Changed Route Becomes Believable Again
Picture a relay disappearing while neighboring devices still hold different views of the path. Forwarding is safe only after stale information loses to a newer valid route.
A protocol means an agreed set of rules for exchanging information. For this routing method, record who advertised each path, its freshness value, next hop, cost, and invalid state.
Remove one link, add another, and trace periodic, triggered, invalid, and settled updates. Keep each table snapshot, message time, chosen route, dropped traffic, and settle time so another person can replay convergence.
This test covers one small network and change, not every mobile pattern. The deeper sections develop update rules, freshness, loops, overhead, timers, and failure handling.
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.
5.2 Start With One Changed Link
DSDV operation becomes concrete when one link changes. A neighbor disappears, a better path appears, or an old route is invalidated, and the table update has to move through the network without creating stale loops.
Start with that changed link, then trace the update. The chapter’s convergence details are easier when every message is tied to the question: which route did this node believe, and why did that belief change?
5.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. Inspect Figure 5.1 to connect that evidence to the proactive maintenance cycle rather than to the protocol label alone.
Read Figure 5.1 from the nodes to their maintained route state and then to packet forwarding. The route is available without an on-demand discovery pause because updates have already distributed reachability and freshness. Carry that benefit forward with its cost: the deployment record must show update traffic during both quiet and changing intervals.
5.3.1 Periodic Updates
Nodes send routing information on a schedule so neighbors can refresh table state even when no topology event was observed.
5.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.
5.3.3 Freshness Rule
A route with a newer destination sequence number wins. If sequence numbers match, the route with the lower metric wins.
5.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.
Do not approve a DSDV design from a topology diagram alone. The review needs update triggers, freshness handling, broken-route handling, and convergence evidence.
5.4 Practitioner: Trace the Update Decision
A practitioner should review DSDV as a set of table decisions. Figure 5.2 shows the positive path: when an advertisement arrives, the receiving node checks destination, next hop, metric, sequence number, and local route state, and installs it only when the freshness and metric rules justify the change.
In Figure 5.2, start at newly joined node K, follow the metric as it increases at A and then at the next neighbours, and verify that the destination sequence number stays tied to the same advertisement generation. The same discipline applies to the failure path in Figure 5.3: begin at the broken link, then trace the infinity metric and newer sequence number outward so stale good news loses the comparison.
Read Figure 5.3 through detection, invalidation, sequence-number change, and broadcast. Each step prevents a neighbour from continuing to prefer the dead path. The update review should therefore name the fields that decide whether a route is installed, ignored, or invalidated, and retain the before-and-after rows as convergence evidence.
5.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. |
5.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. |
5.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.
Before convergence as State Audit, inspect Figure 5.4 to compare “sequence” with “Timeline sequence showing DSDV operation over time with peri”. Their juxtaposition makes DSDV timing variant showing route advertisement, invalidation, alternate route, and convergence evidence stages visible.
Read Figure 5.4 from “sequence” to “Timeline sequence showing DSDV operation over time with peri”. Taken together, “sequence” and “Timeline sequence showing DSDV operation over time with peri” express DSDV timing variant showing route advertisement, invalidation, alternate route, and convergence evidence stages. For convergence as State Audit, the observed relationship between “sequence” and “Timeline sequence showing DSDV operation over time with peri” is evidence that “sequence” carries into the next decision.
Convergence evidence should show when stale state is invalidated and when the selected alternate path becomes stable.
5.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. |
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.
5.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.
5.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.
5.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.