10 DSR Caching and Route Maintenance
10.1 Start Simple
Start with devices that have to pass useful data before any fixed network is guaranteed. In DSR Caching and Route Maintenance, the first question is not the protocol name; it is which neighbors, routes, failure signals, and degraded behaviors you would trust in the field.
10.2 Start With a Cached Route That Might Be Wrong
A DSR cache is helpful until it becomes stale. The node remembers a route so it can avoid rediscovery, but mobility, failed links, and changing traffic can turn that memory into a bad forwarding decision.
Start with one cached route and ask what evidence would make you trust it today. Maintenance is the discipline of detecting broken links, removing bad assumptions, and deciding when discovery must run again.
10.3 Cached DSR Routes Expire
Dynamic Source Routing can reuse paths it has discovered or overheard. That reuse is valuable in quiet ad-hoc IoT networks because a sender can avoid another Route Request flood when the same destination is needed again.
The cache is not a permanent map. A cached source route names specific relays, so a moving node, a sleeping device, or a changed radio link can make the route wrong even though it is still stored locally. DSR route maintenance is the discipline that removes broken promises before they become repeated packet loss.
The practical question is therefore not “does the node have a route?” but “can this particular hop list still be defended?” A route learned seconds ago from a stable rack of sensors may be safe enough for another burst, while a route learned before a robot turned a corner may be stale. The cache policy has to match the deployment’s movement, duty cycle, and traffic pattern.
Maintenance also needs the right fault scope. If one adjacent hop fails, every cached source route containing that hop is suspect, but unrelated routes do not have to be discarded. That distinction matters in constrained IoT devices: clearing too little repeats the same broken path, while clearing too much forces avoidable floods, latency, and battery cost. Good DSR operation keeps those two mistakes visible in logs and tests.
For a learner, the mental model is a route notebook with expiration and correction marks. The notebook speeds up forwarding only when each entry has a source, an age, a recent success signal, and a rule for what happens when a relay reports that part of the path no longer works.
Think of DSR caching as a short-lived operational record: it is useful only while the path, link quality, and application tolerance still match the route that was learned.
10.3.1 What to Remember
- Cache hit: a valid cached route can skip discovery delay and reduce control traffic for repeated sparse communication.
- Cache age: the acceptable lifetime depends on link churn. Faster movement or more variable links require shorter trust windows.
- Broken link: when a relay cannot reach the next hop in the source route, the route must be invalidated instead of retried blindly.
10.4 Bind Cache to Field Signals
A field-ready DSR cache policy needs more than a fixed timeout. The team should record how routes enter the cache, which destinations are worth caching, when a route is too old to trust, what happens after a forwarding failure, and whether a relay is allowed to salvage a packet with an alternate cached route.
10.4.1 Cache Maintenance Ledger
| Decision | Record | Why it matters | Failure signal |
|---|---|---|---|
| Cache admission | Which learned or overheard routes may be stored, and whether partial or overheard routes are trusted. | Unfiltered caching can fill memory with routes that will never be reused. | Many entries age out unused or crowd out the route actually needed. |
| Cache lifetime | Expiration rule tied to observed mobility, link churn, traffic cadence, and device sleep behavior. | A route that is safe in a stable sensor mesh may be stale in a moving robot or vehicle scenario. | Packets repeatedly fail on routes that are old but still accepted. |
| Route Error handling | How the source receives a Route Error and removes every cached route containing the failed hop. | Targeted invalidation preserves good alternatives while removing known-bad paths. | The source keeps retrying the same broken relay sequence. |
| Salvage policy | Whether an intermediate relay may replace a broken route with another cached path, and how that action is logged. | Salvage can save a packet, but hidden rerouting can make debugging difficult if it is not bounded. | Packets arrive by unexpected paths with no record of the repair. |
10.4.2 Operational Flow
- Learn the route: store routes from successful discovery or trusted overhearing with a timestamp and destination.
- Reuse deliberately: use a cached source route only if its age and link history still fit the deployment.
- Detect the break: treat failed next-hop delivery, link-layer feedback, or missing acknowledgement as a route-maintenance event.
- Purge narrowly: remove routes containing the failed hop, then use a valid alternate or begin fresh discovery.
10.5 Maintenance as State Transition
Inside a DSR node, a cache entry is not just a list of hops. It has a destination, a source-route sequence, a time learned, a confidence boundary, and a removal trigger. Route maintenance moves entries between usable, suspect, invalidated, and replaced states as link observations arrive.
The invalidation key is usually more precise than the destination. A Route Error identifies an adjacent-hop pair that failed, so cache maintenance should search for every stored source route containing that pair and mark only those entries unusable. This keeps unrelated paths available while preventing the failed hop from reappearing through a different cached route for the same destination.
Age is a separate signal. A route can be old without being proven broken, and a route can be young but already invalid because a relay reported a failed next hop. Robust implementations keep those reasons distinct: timeout removes entries because confidence has decayed, while a Route Error removes entries because evidence says a specific link no longer carries traffic.
Salvage adds another state transition. If an intermediate relay has an alternate cached path, it may forward the packet without sending it all the way back to the source first. That can reduce delay, but it must still generate maintenance evidence: which route was replaced, which hop failed, which alternate was used, and whether the source cache should be corrected. Without that record, a successful salvage can hide the original fault and let the sender reuse the bad path later.
Backoff closes the loop. When no valid cached path remains, the node returns to route discovery, but repeated discovery floods for the same unreachable destination should be paced. The implementation state machine should therefore connect cache lookup, expiration, Route Error processing, salvage, and discovery backoff rather than treating them as isolated helper functions.
10.5.1 Cache States
- Usable: the route is young enough, the destination is still needed, and no known failed hop appears in the sequence.
- Suspect: the route is aging, a relay has weak recent delivery, or mobility suggests that a fresh discovery may be cheaper than repeated failure.
- Invalidated: a Route Error or delivery failure has identified a broken hop. All entries containing that hop are removed or marked unusable.
Do not let salvage hide failure. If an intermediate relay substitutes another cached path, the source still needs a record that the original hop failed, otherwise the same stale route may be reused later.
10.5.2 Implementation Checks
- Cache lookup rejects expired routes before packet transmission.
- Route Error processing removes every route containing the failed adjacent-hop pair.
- Alternate cached routes are checked for the same failed hop before reuse.
- Discovery backoff prevents rapid repeated floods for the same unreachable destination.
- Logs expose the route used, the cache age, the invalidation trigger, and the final retry action.
10.6 Summary
DSR route caching reduces route discovery overhead when cached source routes remain valid. The same mechanism becomes a liability when mobility, sleep cycles, or link churn make cached relay sequences stale. Route maintenance keeps the cache trustworthy by expiring old entries, reacting to forwarding failures, sending Route Error information back toward the source, and purging only the routes affected by the failed hop.
The practical rule is qualitative: trust cached DSR routes only for as long as the deployment can defend them. Stable, sparse sensor traffic can benefit from longer reuse windows; moving nodes and unstable radio links need shorter trust windows, targeted invalidation, and clear retry behavior.
10.7 Key Takeaway
A DSR cache entry is not proof of a current path. It is a temporary route promise that must expire, be invalidated by Route Errors, or be replaced by fresh discovery when the topology changes.
10.8 See Also
- DSR Reactive Routing: review DSR discovery and source-routed packet forwarding.
- DSR Worked Examples: practice cache-hit, cache-miss, and repair reasoning.
- DSDV Proactive Routing: compare reactive discovery with always-maintained route tables.
- ZRP Hybrid Zone Routing: contrast DSR with a zone-limited hybrid routing approach.