7 DSR Reactive Routing
More
Depth: Practitioner
Progress saves as you read. Mark sections complete as you go; your progress appears in the sidebar.
7.1 Start Simple
This section: Start Simple — Picture a quiet field sensor waking to send one urgent reading through nearby devices.
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.
7.2 Start With a Route Request
This section: Start With a Route Request — DSR begins only when a source needs a path.
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
This section: DSR Finds Routes on Demand — Dynamic Source Routing, or DSR, is a reactive routing protocol for ad-hoc networks.
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.
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
This section: Route as Evidence — A practical DSR review should prove more than protocol vocabulary.
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.
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
This section: Source Routes Move Packet State — DSR changes where routing state lives.
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.
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. |
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
This section: How AODV Answers The Same Discovery Problem — DSR is not the only reactive protocol built on Route Request and Route Reply.
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 increase DSR per-packet header cost; AODV uses per-hop route state. Compare active destinations, route-cache policy, and packet size before choosing on memory or lookup cost.
7.7 Summary
This section: Summary — DSR is a reactive routing protocol for ad-hoc networks.
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
This section: 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.
7.9 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