7 DSR Reactive Routing
7.1 Start Simple
Discover a Path Only When the Sensor Needs It
Picture a quiet field sensor waking to send one urgent reading through nearby devices. A protocol means the agreed rules and message order devices follow to exchange routing information.
Name the source, destination, route request, forwarding nodes, route reply, and carried path. Test first discovery, a duplicate request, a missing reply, and a broken link after discovery.
Keep packet identifiers, recorded path, delay, control traffic, and final delivery. This proves one on-demand route in one layout, not universal savings; the deeper sections explain source routes, caches, errors, maintenance, and limits.
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.
7.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.
7.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.
Before DSR Finds Routes on Demand, inspect Figure 7.1 to compare “Path 1” with “[A, B]”. Their juxtaposition makes A DSR Route Request spreads through the ad-hoc network and accumulates a route record as intermediate nodes forward it visible.
Read Figure 7.1 from “Path 1” to “[A, B]”. Taken together, “Path 1” and “[A, B]” express A DSR Route Request spreads through the ad-hoc network and accumulates a route record as intermediate nodes forward it. For DSR Finds Routes on Demand, the observed relationship between “Path 1” and “[A, B]” is evidence that “Path 1” carries into the next decision.
7.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.
7.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.
Before route as Evidence, inspect Figure 7.2 to compare “Node D” with “SOURCE”. Their juxtaposition makes the RREP returns the discovered path to the source, where it becomes a cached route for subsequent packets visible.
Read Figure 7.2 from “Node D” to “SOURCE”. Taken together, “Node D” and “SOURCE” express the RREP returns the discovered path to the source, where it becomes a cached route for subsequent packets. For route as Evidence, the observed relationship between “Node D” and “SOURCE” is evidence that “Node D” carries into the next decision.
7.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. |
A discovery review should also watch for a specific failure shape: the RREP storm. Because any node holding a cached route to the destination may reply to a passing RREQ on the destination’s behalf, several nodes along the flood can all answer at once, hitting the source with a burst of near-simultaneous, possibly stale replies instead of one clean answer. A defensible implementation does not let every cache hit reply immediately; it holds the reply for a short, evidence-based delay and stays silent if it overhears a shorter route going by first. That single design choice turns the “duplicate suppression behavior” row above from a footnote into the difference between a quiet discovery and a self-inflicted flood.
7.4.2 Review Flow
- Name the traffic pattern: record who talks to whom, how often, and whether a first-packet discovery delay is acceptable.
- Capture discovery evidence: trace RREQ forwarding, RREP return, duplicate suppression, and the final route chosen by the source.
- Inspect packet forwarding: confirm that data packets carry the source route and that relays forward according to the next hop in that route.
- Break a link deliberately: prove that the broken route is invalidated and that the application has a defined retry or rediscovery behavior.
7.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.
Before source Routes Move Packet State, inspect Figure 7.3 to compare “Hop Index” with “Route List”. Their juxtaposition makes A DSR data packet carries the relay list, so forwarding state travels with the packet instead of living only in per-hop routing tables visible.
Read Figure 7.3 from “Hop Index” to “Route List”. Taken together, “Hop Index” and “Route List” express A DSR data packet carries the relay list, so forwarding state travels with the packet instead of living only in per-hop routing tables. For source Routes Move Packet State, the observed relationship between “Hop Index” and “Route List” is evidence that “Hop Index” carries into the next decision.
7.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. |
Before under-the-Hood Boundaries, inspect Figure 7.4 to compare “Flood RREQ” with “hop by hop”. Their juxtaposition makes the operational decision is simple, but each branch needs evidence: cache hit, cache miss, successful delivery, and failure recovery visible.
Read Figure 7.4 from “Flood RREQ” to “hop by hop”. Taken together, “Flood RREQ” and “hop by hop” express the operational decision is simple, but each branch needs evidence: cache hit, cache miss, successful delivery, and failure recovery. For under-the-Hood Boundaries, the observed relationship between “Flood RREQ” and “hop by hop” is evidence that “Flood RREQ” carries into the next decision.
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.
7.6 How AODV Answers The Same Discovery Problem
DSR is not the only reactive protocol built on Route Request and Route Reply. Ad-hoc On-Demand Distance Vector, or AODV, uses the same RREQ/RREP vocabulary but stores the result differently, and that difference is worth reviewing alongside DSR rather than in isolation.
Where DSR lets the RREQ accumulate a full ordered address list that the RREP carries back and the source then places in every data packet, AODV’s RREQ does not collect addresses at all. Instead, each intermediate node that forwards the RREQ creates a temporary distance-vector-style table entry pointing back toward the source. When the RREQ reaches the destination, or a node with a fresh-enough cached route, the RREP retraces that same trail hop by hop, and each node along the way installs a forward-path entry from the breadcrumbs the RREQ left behind. The result is a next-hop table at every relay instead of a source-route header in every packet: AODV trades DSR’s per-packet header growth for per-node table maintenance along active paths.
That table is soft state, not a permanent route. Entries expire if a data packet has not used them recently, so an idle path quietly disappears instead of accumulating stale routes the way an unmanaged DSR cache can. AODV also carries a destination sequence number with every route, the same freshness idea DSDV uses, so a node can tell a fresher route from a stale one; the same mechanism guards against the count-to-infinity problem and routing loops that plain distance-vector routing is prone to. Reviewing an AODV deployment therefore means checking things DSR review does not need: table-entry lifetime and expiry policy, sequence-number freshness comparisons at every hop rather than only at the source, and evidence that a broken active-route entry is invalidated the same way a DSR cache entry is.
DSR and AODV solve the same reactive-discovery problem with the same RREQ/RREP exchange, but they disagree about where the route lives: in the packet header for DSR, or in a per-hop table entry for AODV. Long paths and constrained relay memory favor the table; frequent per-hop lookup cost favors the source route.
7.7 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.
7.8 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.