250  DSR Fundamentals and Route Discovery

250.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Understand DSR Protocol: Explain Dynamic Source Routing as a reactive on-demand routing protocol
  • Analyze Route Discovery: Describe how route requests and route replies establish communication paths
  • Explain Source Routing: Understand how complete paths are embedded in packet headers
  • Compare with Proactive Routing: Differentiate DSR’s on-demand approach from DSDV’s table-driven approach

250.2 Prerequisites

Before diving into this chapter, you should be familiar with:

  • Ad Hoc Routing: Proactive (DSDV): Understanding DSDV’s proactive approach and continuous overhead provides essential contrast for appreciating DSR’s on-demand discovery and why reactive routing reduces overhead for sparse communication
  • Multi-Hop Fundamentals: Multi-hop networking concepts are fundamental to DSR since route discovery builds paths hop-by-hop and intermediate nodes must forward route requests across multiple hops
  • Networking Basics: Core networking concepts including packet headers, forwarding mechanisms, and addressing are essential for understanding source routing and how complete paths are embedded in DSR packets
  • Routing Fundamentals: General routing principles including path discovery, route maintenance, and flooding mechanisms provide the foundation for DSR’s RREQ/RREP process and route error handling

Imagine you rarely travel but when you do, you look up directions on Google Maps. You don’t keep a constantly-updated map of every possible destination - that would waste data! Reactive routing (DSR) works the same way - find routes only when you need them.

Reactive = On-Demand

Unlike proactive routing (DSDV) that maintains routes to everywhere continuously, DSR discovers routes only when you have data to send: - Pro: Zero overhead when idle (perfect for battery-powered IoT) - Con: Initial delay discovering route before sending first packet

How DSR Works: The “Ask Around” Strategy

When Node A needs to send to Node F but has no route:

  1. Flood Route Request (RREQ): A broadcasts “Who knows how to reach F?” to all neighbors
  2. Build Path: Each node that hears the request adds its name and forwards: [A] → [A,B] → [A,B,D]
  3. Destination Replies: When F receives request with path [A,B,D], it sends Route Reply (RREP) back
  4. Source Sends Data: A now knows route and includes it in packet header: “Send this via B→D→F”

Source Routing - The Package Label:

Unlike DSDV where each node decides next hop independently, DSR puts the complete route in packet header like a package label saying “Deliver to F via stops at B and D.”

Route Caching - The Memory Trick:

Smart feature: Nodes “overhear” routes from nearby packets and cache them for later use.

Example: Node C overhears A sending to F via [B,D,F]. Later, if C needs to reach F, it already knows a route without flooding!

Term Simple Explanation Everyday Analogy
Reactive Routing Find routes only when needed Look up directions when you travel, not daily
Route Request (RREQ) Flood network asking for path Shouting “Does anyone know where Main St is?”
Route Reply (RREP) Destination sends back discovered path Someone replies “I know! Go left, then right”
Source Routing Complete path in packet header Package labeled “Via Chicago, then Denver, then LA”
Route Caching Remember overheard routes for future Remembering a friend’s directions for later
Route Error (RERR) Notification that link broke Call saying “Road closed, find new route”

DSR Example - Sending a Message:

Node A wants to send “Hello” to Node F:

Step 1: A broadcasts RREQ: "Looking for F: [A]"
Step 2: B hears it, forwards: "Looking for F: [A,B]"
Step 3: D hears it, forwards: "Looking for F: [A,B,D]"
Step 4: F hears it, replies: "Found! Route is [A,B,D,F]"
Step 5: A sends packet with header: [Source: A, Dest: F, Route: [B,D], Payload: "Hello"]
Step 6: B sees "Route: [B,D]", forwards to D
Step 7: D sees "Route: [D]", forwards to F
Step 8: F receives "Hello"

The Stale Cache Problem:

Imagine: C cached route [A,B,D,F] two hours ago. But D moved away! When C tries to use cached route, transmission fails. C must detect failure and discover fresh route.

DSR vs DSDV Trade-offs:

Metric DSDV (Proactive) DSR (Reactive)
Overhead when idle High (periodic updates) Zero (no updates)
Route availability Immediate (pre-computed) Delayed (must discover)
Best for Frequent communication Sparse communication
Energy efficiency Poor (continuous updates) Good (on-demand only)
Network size Limited (table explosion) Better (no global tables)

When to Use DSR:

  • Battery-powered IoT sensors (send data rarely)
  • Sparse communication patterns (each sensor talks to gateway occasionally)
  • Large networks (no global routing tables needed)
  • Not for real-time applications (discovery delay unacceptable)
  • Not for frequent communication (discovery overhead adds up)

Why This Matters for IoT:

Most IoT deployments have sparse communication - sensors report to gateway occasionally, not continuously. DSR’s on-demand approach saves 90-95% battery compared to proactive routing by eliminating continuous overhead. Perfect for field deployments where replacing batteries is expensive!

250.3 DSR Protocol Overview

⏱️ ~10 min | ⭐⭐ Intermediate | 📋 P04.C07.U01

Dynamic Source Routing (DSR) is a reactive (on-demand) protocol where routes are discovered only when needed for active communication.

250.3.1 What Makes DSR Unique

Reactive protocols:
Discover routes on-demand when a source needs to communicate with a destination

Characteristics: - No periodic route maintenance overhead - Route discovery latency (must find route before sending data) - Lower control overhead for sparse communication - Routes cached for reuse - Ideal for networks where nodes communicate infrequently

DSR Key Features:

  1. Source routing: Complete path embedded in packet header
  2. Route discovery: Flood network with route requests
  3. Route caching: Intermediate nodes cache overheard routes
  4. No periodic updates: Zero overhead when idle

250.4 Route Discovery Process

⏱️ ~15 min | ⭐⭐⭐ Advanced | 📋 P04.C07.U02

When Node A needs to send data to Node F, the route discovery process begins:

250.4.1 Phase 1: Route Request (RREQ)

%% fig-alt: "DSR route request (RREQ) flooding from source Node A to destination Node F. Node A broadcasts RREQ with path [A] to neighbors B and C. Node B appends itself and forwards RREQ [A,B] to D. Node C forwards RREQ [A,C] to E. Both paths eventually reach destination F with different accumulated paths showing hop-by-hop route discovery."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%

graph LR
    A["Node A<br/>Source"] -->|"RREQ: A→F, Path:A, ID:101"| B["Node B"]
    A -->|"RREQ: A→F, Path:A, ID:101"| C["Node C"]
    B -->|"RREQ: A→F, Path:A-B, ID:101"| D["Node D"]
    C -->|"RREQ: A→F, Path:A-C, ID:101"| E["Node E"]
    D -->|"RREQ: A→F, Path:A-B-D, ID:101"| F["Node F<br/>Destination"]
    E -->|"RREQ: A→F, Path:A-C-E, ID:101"| F

    style A fill:#E67E22,stroke:#2C3E50,color:#fff
    style B fill:#16A085,stroke:#2C3E50,color:#fff
    style C fill:#16A085,stroke:#2C3E50,color:#fff
    style D fill:#16A085,stroke:#2C3E50,color:#fff
    style E fill:#16A085,stroke:#2C3E50,color:#fff
    style F fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 250.1: DSR route request (RREQ) flooding from source Node A to destination Node F

RREQ Packet Format:

<Source, Destination, [Path], Request ID>

Route Request Propagation:

  1. Source (A) initiates:
    • Broadcasts RREQ: <A, F, [A], 101>
    • Request ID prevents loops
  2. Intermediate node (B) receives:
    • Checks if already processed this Request ID
    • If new, appends self to path: [A,B]
    • Rebroadcasts: <A, F, [A,B], 101>
  3. Another intermediate (D) receives:
    • Appends self: [A,B,D]
    • Forwards toward destination
  4. Destination (F) receives:
    • Multiple RREQs may arrive via different paths
    • Each contains complete path from source

250.4.2 Phase 2: Route Reply (RREP)

%% fig-alt: "DSR route reply (RREP) unicast from destination Node F back to source Node A. After receiving RREQ, Node F sends RREP containing complete discovered path [A,B,D,F] back through reverse route. RREP travels F to D to B to A, delivering full source route to originating node."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%

graph RL
    F["Node F<br/>Destination"] -->|"RREP: Route A-B-D-F"| D["Node D"]
    D -->|"RREP: Route A-B-D-F"| B["Node B"]
    B -->|"RREP: Route A-B-D-F"| A["Node A<br/>Source"]

    style F fill:#E67E22,stroke:#2C3E50,color:#fff
    style D fill:#16A085,stroke:#2C3E50,color:#fff
    style B fill:#16A085,stroke:#2C3E50,color:#fff
    style A fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 250.2: DSR route reply (RREP) unicast from destination Node F back to source Node A

RREP Options:

Option 1: Symmetric Links (Common) - Destination reverses the path from RREQ - Sends RREP back along reverse route - Example: RREQ path [A,B,D] → RREP follows D→B→A

Option 2: Cached Route - If destination has cached route to source - Use that route to send RREP - Avoids reverse-path assumption

Option 3: Piggyback on Route Discovery - Destination initiates its own RREQ to source - Discovers forward path - Sends RREP using discovered path

250.5 Alternative Views of DSR Operation

250.5.1 Timeline View

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant SRC as Source A
    participant INT as Network<br/>(Intermediate)
    participant DST as Destination F
    participant CACHE as Route Cache

    Note over SRC,DST: ROUTE DISCOVERY PHASE

    SRC->>INT: RREQ: Path [A]
    Note over INT: Append self to path
    INT->>INT: Forward: Path [A,B,D]
    INT->>DST: RREQ arrives: Path [A,B,D]

    Note over SRC,DST: ROUTE REPLY PHASE

    DST->>INT: RREP: Complete route [A,B,D,F]
    INT->>SRC: RREP delivered

    Note over CACHE: Cache route for reuse
    SRC->>CACHE: Store [A,B,D,F]

    Note over SRC,DST: DATA TRANSMISSION PHASE

    SRC->>DST: Data via source route header [B,D,F]

    Note over SRC,DST: ROUTE MAINTENANCE

    DST--xINT: Link breaks!
    INT->>SRC: RERR: Link D-F failed
    SRC->>CACHE: Invalidate route

Figure 250.3: Timeline view showing DSR protocol phases: Route Discovery floods RREQ accumulating path, Route Reply returns complete route to source, Data Transmission uses cached source route, and Route Maintenance handles link failures with RERR messages.

250.5.2 Decision Tree View

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TD
    START([Node A needs to<br/>send to Node F]) --> CHECK{Check Route<br/>Cache}

    CHECK -->|Route Found| VALID{Is cached<br/>route valid?}
    CHECK -->|No Route| DISCOVER[Initiate Route<br/>Discovery RREQ]

    VALID -->|Fresh cache| USE[Use Cached Route<br/>Send Data Immediately]
    VALID -->|Stale/expired| DISCOVER

    DISCOVER --> FLOOD[Flood RREQ<br/>to Neighbors]
    FLOOD --> WAIT{Wait for<br/>RREP}

    WAIT -->|RREP received| CACHE[Cache New Route]
    WAIT -->|Timeout| RETRY{Retry<br/>count?}

    CACHE --> USE

    RETRY -->|< 3 retries| FLOOD
    RETRY -->|>= 3 retries| FAIL[Route Discovery<br/>Failed]

    USE --> SEND[Send Data with<br/>Source Route Header]
    SEND --> LINK{Link<br/>OK?}

    LINK -->|Success| DONE([Data Delivered])
    LINK -->|Failure| RERR[Generate RERR<br/>Remove from Cache]
    RERR --> DISCOVER

    style START fill:#16A085,color:#fff
    style CHECK fill:#2C3E50,color:#fff
    style VALID fill:#2C3E50,color:#fff
    style DISCOVER fill:#E67E22,color:#fff
    style CACHE fill:#16A085,color:#fff
    style USE fill:#16A085,color:#fff
    style FAIL fill:#E74C3C,color:#fff
    style DONE fill:#16A085,color:#fff
    style RERR fill:#E74C3C,color:#fff

Figure 250.4: Alternative view: Decision tree showing DSR packet handling flow. When a node needs to send data, it first checks the route cache. If a valid route exists, it uses it immediately. Otherwise, route discovery floods the network. Failed transmissions trigger route errors and cache invalidation.

250.6 Complete DSR Example

%% fig-alt: "Complete DSR route discovery and data transmission sequence. Node A needs route to F, broadcasts RREQ with path [A]. RREQ propagates through network accumulating path: [A] to [A,B] to [A,B,D]. Node F receives RREQ, sends RREP back with complete path [A,B,D,F]. Node A caches route and sends data packets with source route embedded in header [B,D,F], each hop extracts next destination from route."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%

sequenceDiagram
    participant A as Node A<br/>(Source)
    participant B as Node B
    participant D as Node D
    participant F as Node F<br/>(Dest)

    Note over A: Need route to F
    A->>B: RREQ: [A]
    A->>D: RREQ: [A]
    B->>D: RREQ: [A,B]
    D->>F: RREQ: [A,B,D]
    Note over F: Route discovered
    F->>D: RREP: [A,B,D,F]
    D->>B: RREP: [A,B,D,F]
    B->>A: RREP: [A,B,D,F]
    Note over A: Route cached
    A->>B: DATA via [B,D,F]
    B->>D: DATA via [D,F]
    D->>F: DATA

Figure 250.5: Complete DSR route discovery and data transmission sequence

Data Packet Format (Source Routing):

+--------+--------+--------+---------+
| Src: A | Dst: F | Route  | Payload |
|        |        | [B, D] |         |
+--------+--------+--------+---------+
  • Complete route embedded in packet header
  • Each hop looks up next hop from route field
  • No per-hop routing table lookups needed

250.7 Knowledge Check

TipTest Your Understanding

Question 1: In DSR, what does “source routing” mean for each data packet?

Explanation: C. DSR embeds the discovered route inside the packet. Intermediate nodes forward by following the hop list, which reduces per-node routing table needs but increases header overhead on longer paths.

Question 2: Reactive routing protocols like DSR are typically most efficient in which traffic pattern?

Explanation: B. Reactive protocols avoid periodic control overhead when the network is idle, at the cost of route discovery latency when communication starts. This fits many IoT/WSN patterns where nodes talk occasionally.

250.8 Summary

This chapter introduced DSR (Dynamic Source Routing) fundamentals and the route discovery process:

  • Reactive On-Demand Approach: DSR discovers routes only when needed, eliminating periodic routing overhead but introducing discovery latency before first packet transmission
  • Source Routing Mechanism: Complete route embedded in packet headers, allowing intermediate nodes to forward without routing table lookups but increasing header overhead
  • Route Discovery Process: Floods RREQ (Route Request) through network with cumulative path, destination replies with RREP (Route Reply) containing complete discovered route
  • RREQ Propagation: Each intermediate node appends itself to the path and rebroadcasts, with Request ID preventing duplicate processing
  • RREP Options: Routes can return via symmetric link reversal, cached routes, or piggybacked route discovery

Continue Learning: - DSR Caching and Maintenance - Route caching strategies and error handling - DSR Worked Examples - Practical scenarios and calculations

Comparisons: - Ad Hoc Routing: Proactive (DSDV) - Table-driven continuous route maintenance - Ad Hoc Routing: Hybrid (ZRP) - Balancing proactive and reactive approaches

250.9 What’s Next

The next chapter covers DSR Caching and Maintenance, exploring how nodes cache overheard routes, manage cache lifetimes, and handle route errors when links break.