8  DSR Reactive Routing

emerging-paradigms
adhoc
dsr

8.1 Start Simple

Start with devices that have to pass useful data before any fixed network is guaranteed. In DSR Reactive 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.

8.2 Start With a Route Request

DSR begins only when a source needs a path. Instead of maintaining every route in advance, the node broadcasts a route request and lets the discovered path come back as evidence.

That on-demand story is attractive for IoT systems where traffic is occasional or topology changes make constant upkeep wasteful. Start with the request, the reply, and the route carried in the packet; the rest of DSR follows from those choices.

8.3 DSR Finds Routes on Demand

Dynamic Source Routing, or DSR, is a reactive routing protocol for ad-hoc networks. A node does not maintain a next-hop table for every possible destination while the network is quiet. When it has data to send and no usable cached route, it discovers a path on demand.

The discovery exchange has two visible parts. A Route Request, or RREQ, is broadcast outward and records the path it has followed. A Route Reply, or RREP, returns the chosen path to the source. The source then places that path in the data packet so relays know the next hop without running their own route lookup.

The important review distinction is between reachability and route evidence. A successful discovery says that, at that moment, the destination or an intermediate node knew a path back to the source. It does not say the path will remain valid after devices move, radio links fade, or a relay reboots. DSR is useful only when the system also records why the route was accepted, when it was cached, and what event will cause the source to stop trusting it.

In a small classroom mesh this may look like a simple broadcast and reply. In a field deployment the same exchange affects latency, airtime, and battery. A first packet waits while RREQs propagate and duplicates are suppressed; later packets are fast only if the cached source route still matches the topology. That is the trade: pay less while idle, then pay a measurable discovery and validation cost when traffic starts.

Use DSR as a routing shape when sparse traffic makes continuous route upkeep unattractive, and when the application can tolerate route discovery before the first packet on a new path.

DSR Route Request flooding from source node A toward destination node F with each relay appending itself to the path.
Figure 8.1: A DSR Route Request spreads through the ad-hoc network and accumulates a route record as intermediate nodes forward it.

8.3.1 What to Remember

  • Reactive fit: DSR avoids periodic route advertisements when there is no traffic, which can fit intermittently active devices better than always-maintained route tables.
  • Source route: the packet carries the ordered relay list. Each relay forwards to the next named hop instead of choosing a destination route from a table.
  • Discovery cost: the first packet can wait while discovery completes, and the request flood consumes shared airtime. That cost is acceptable only when it is paid infrequently enough.

8.4 Route as Evidence

A practical DSR review should prove more than protocol vocabulary. It should show when the node discovers a route, what route is cached, how packet headers carry the route, how long cached information is trusted, and what evidence shows recovery after a broken link.

DSR Route Reply returning the selected route from destination node F back to source node A along the discovered path.
Figure 8.2: The RREP returns the discovered path to the source, where it becomes a cached route for subsequent packets.

8.4.1 Evidence Ledger

Review item Evidence to capture Why it matters Failure signal
Route discovery RREQ/RREP traces, duplicate suppression behavior, selected path, and discovery trigger. Discovery flood cost is the price DSR pays instead of periodic table upkeep. Repeated floods for the same destination or routes that never reach the source.
Source route use Packet headers or logs showing the ordered relay list used for forwarding. Relays depend on the packet route being accurate enough for the current topology. Packets carry obsolete relays or the hop index advances incorrectly.
Cache policy When routes are inserted, reused, expired, invalidated, or replaced by alternatives. Caches reduce rediscovery but can become dangerous when mobility or link churn is high. Old routes are reused after a relay moved, rebooted, or lost link quality.
Repair path Route Error handling, cache cleanup, retransmission decision, and rediscovery trigger. A reactive design is only credible if broken routes are removed and retried deliberately. Failures silently drop packets or cause repeated attempts over a known-bad link.

8.4.2 Review Flow

  1. Name the traffic pattern: record who talks to whom, how often, and whether a first-packet discovery delay is acceptable.
  2. Capture discovery evidence: trace RREQ forwarding, RREP return, duplicate suppression, and the final route chosen by the source.
  3. Inspect packet forwarding: confirm that data packets carry the source route and that relays forward according to the next hop in that route.
  4. Break a link deliberately: prove that the broken route is invalidated and that the application has a defined retry or rediscovery behavior.

8.5 Source Routes Move Packet State

DSR changes where routing state lives. Table-driven protocols keep forwarding state in each router. DSR can put much of the forwarding decision into the packet itself: source, destination, route length, current hop position, relay list, and payload. The relay’s job is to read the next named hop and transmit toward it.

That design removes per-destination tables from relays, but it does not remove all cost. Longer paths create larger headers. Route caches can become stale. Discovery floods can collide with application traffic on constrained wireless links. Link failures must generate Route Errors so the source and other caches stop trusting broken path segments.

RFC 4728 describes the route record as protocol state that can be copied from a Route Request into a Route Reply and then into later data packets. That is why packet inspection matters: the route header should reveal the ordered address list, the current segment being forwarded, and whether the packet is following a fresh discovery or a cached route. Without that evidence, a team cannot separate a healthy cache hit from a lucky delivery over an outdated path.

Route maintenance is the other half of the mechanism. If a node cannot forward to the next hop, it should generate a Route Error identifying the broken link, and nodes that hear the error should remove routes containing that link from their caches. Local salvage may try an alternate cached route, but only if the implementation logs that decision and avoids looping back into the same failed segment. The under-the-hood test therefore needs both packet-header traces and negative evidence from deliberate link breaks.

DSR packet structure showing source, destination, route length, hop index, route list, and payload fields.
Figure 8.3: A DSR data packet carries the relay list, so forwarding state travels with the packet instead of living only in per-hop routing tables.

8.5.1 Under-the-Hood Boundaries

Boundary What to inspect
Header boundary Every named relay consumes header space. The review should compare route length with frame size, payload size, fragmentation risk, and airtime budget.
Cache boundary Cached routes are useful only while the topology remains close enough to the recorded path. Mobility and lossy relays make cache policy a correctness issue.
Discovery boundary RREQ broadcasts are shared-medium control traffic. A design with frequent cache misses can spend too much airtime discovering routes.
Repair boundary RERR handling must remove broken routes quickly enough that retransmissions do not keep following the same failed link.
DSR packet handling decision tree showing cache hit, cache miss, route discovery, delivery, and route error recovery.
Figure 8.4: The operational decision is simple, but each branch needs evidence: cache hit, cache miss, successful delivery, and failure recovery.

Do not treat DSR as free just because it is quiet while idle. The route-discovery flood, source-route header, cache policy, and repair behavior must all fit the actual traffic pattern and wireless link.

8.6 Summary

DSR is a reactive routing protocol for ad-hoc networks. It discovers routes when traffic needs them, returns a route to the source, and forwards later packets using the source route carried in each packet. That can reduce idle control traffic, but the design still has concrete costs: discovery floods, source-route headers, stale caches, and route-error handling after link changes.

8.7 Key Takeaway

Use DSR when the traffic pattern justifies on-demand discovery, and approve it only with evidence for route discovery, packet source routes, cache policy, and recovery after broken links.

8.8 See Also