5 DSDV Route Updates and Convergence
More
Depth: Practitioner
Progress saves as you read. Mark sections complete as you go; your progress appears in the sidebar.
5.1 Start Simple
This section: Start Simple — Picture a relay disappearing while neighboring devices still hold different views of the path.
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.
5.2 Start With One Changed Link
This section: Start With One Changed Link — DSDV operation becomes concrete when one link changes.
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?
DSDV convergence narrated tour
Narrated audio tour. The full transcript is below.
Play the tour to open the simulator. Pause, replay a beat, or read the full transcript below.
Some beats explain situations this teaching model cannot show; those beats keep the existing frame and provide captions only.
Full transcript — DSDV convergence (8 beats)
B1 — Broken link
Imagine you are the engineer keeping sensor reports moving through a network of relays to a collection point. A relay loses a link, but another node still records the old route. Your concern is practical: reports could keep heading toward a dead next hop.
Model caption: Imagine operating this sensor network. C–D is broken, but A still records a route via C.
B2 — Ready routes
Destination Sequenced Distance Vector, or DSDV, routing keeps routes ready before application traffic arrives. Each node stores a next hop, meaning the neighbor it forwards toward. Periodic advertisements refresh those tables. Triggered updates carry urgent changes sooner, including news that a route has broken.
Model caption: Destination Sequenced Distance Vector keeps next-hop tables ready. Periodic advertisements refresh them; triggered updates carry urgent changes sooner.
B3 — Freshness and convergence
A destination sequence number tells a receiver how fresh the route information is. A higher number wins. Only when sequence numbers match does the lower hop count win. Convergence is the interval from a network change until affected nodes have consistent forwarding routes without loops.
Model caption: Higher destination sequence wins; compare hop count only on a freshness tie. Convergence spans network change to consistent, loop-free forwarding among affected nodes.
B4 — Old route
Take the workbench example. Sensor node A has a route to destination D through relay C. Its recorded distance is two hops, at sequence twenty-four. The link between C and D breaks. A still holds its old route while the failure news reaches it.
Model caption: A still records D via C: two hops, sequence twenty-four. C–D is broken; A has not processed the invalidation.
B5 — Invalidation
C advertises D as unreachable, using sequence twenty-five and an infinite distance. Infinity means unreachable, rather than a very long usable path. Twenty-five is newer than twenty-four, so A accepts the update. A records the route as broken, with no next hop toward D.
Model caption: C sends unreachable at sequence twenty-five. A replaces sequence twenty-four, marks D broken, and removes its next hop.
B6 — Stale information
The misconception is that a short advertised route must be usable. A low hop count cannot rescue older information about reachability. After the invalidation, an advertisement with an older sequence number would lose the freshness comparison, even if its distance sounded attractive. Node A must reject that stale information.
Model caption: Short does not establish usable. An older destination sequence must be rejected even with an attractive hop count. This held frame shows the invalidation, not a received stale update.
B7 — Recovery
Relay B then advertises a valid route to D at sequence twenty-six, with a distance of one hop. A adds one hop to reach B: one plus one makes two. Twenty-six beats twenty-five, so A installs the two-hop route through B. Your sensor has a usable next hop again in the model.
Model caption: B advertises one hop at sequence twenty-six. A adds one: two hops via B. Newer freshness replaces the unreachable sequence-twenty-five row.
B8 — Freshness first
Keep one sentence for the next route decision: freshness first, distance only when freshness ties.
Model caption: Freshness first, distance only when freshness ties.
5.3 DSDV Updates Before Demand
This section: DSDV Updates Before Demand — Destination-Sequenced Distance Vector routing keeps a table of next-hop routes at every node.
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 advertise routing information at scheduled intervals so neighbours can refresh their tables even when no topology change has been observed. This regular exchange maintains route state before application traffic needs it and contributes a predictable baseline of control traffic during quiet periods. Receiving an advertisement still requires a route decision: the neighbour compares destination sequence numbers first and considers the metric when freshness matches. The schedule therefore supports table maintenance rather than making each received entry suitable for installation. Review evidence should include the configured interval, table size, radio load and neighbour reception. These records connect the benefit of ready forwarding to the airtime and energy spent maintaining it.
5.3.2 Triggered Updates
A broken next hop or newly learned fresher route can prompt an advertisement before the next scheduled exchange. Sending important changes sooner can reduce the delay before neighbours revise their route tables. For a failure, the update carries an unreachable metric and newer destination freshness so outdated reachability information can be displaced. Receivers still apply the freshness and metric rules when deciding how to change their entries. Earlier transmission does not establish that propagation or convergence has completed: wireless loss, update suppression and neighbour detection timing can affect recovery. Review the triggering event, advertisement time, neighbouring table changes and observed forwarding state, alongside the control traffic generated during the change.
5.3.3 Freshness Rule
Route selection begins by comparing destination sequence numbers. A newer sequence number takes priority over a shorter metric because it represents newer route information. When sequence numbers match, the lower metric wins after accounting for the hop through the advertising neighbour. This ordering separates freshness from distance and helps reject shorter paths based on stale reachability. It also applies during recovery: an alternate route must satisfy the freshness and metric policy after invalidation, rather than being accepted simply because it appears shorter. To explain an installation decision, retain the received advertisement, previous table entry, sequence comparison, metric comparison and resulting next hop. These records show why the node changed its selected route.
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
This section: Practitioner: Trace the Update Decision — A practitioner should review DSDV as a set of table decisions.
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
This section: Convergence as State Audit — Under the hood, DSDV convergence is not just the moment one node changes a table row.
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.
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
This section: Summary — DSDV maintains route tables proactively so forwarding can use a ready next hop.
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
This section: 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.
5.8 See Also
This section: See Also
Find help
3 reviewed answers.
Where should I start in a module?
Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.
Modules and pathsReviewed
What can I try when a project does not work?
Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.
When you are stuckReviewed
How do interactive examples work?
Use the interactive guide to check how examples and simulations work before changing your project.
Interactive examples guideReviewed