23 RPL Trickle & Routing Modes
23.1 Trickle Algorithm and Routing Modes
Learning Objectives
By the end of this section, you will be able to:
- Describe the Trickle algorithm’s adaptive control message timing and its three operating scenarios
- Compare Storing mode and Non-Storing mode trade-offs for memory, latency, and scalability
- Select the appropriate RPL routing mode for a given IoT deployment scenario
- Analyze RPL performance trade-offs across upward, downward, and point-to-point traffic patterns
For Beginners: How IoT Devices Find Routes
Imagine you’re in a large building and need to find your way to the exit. You could ask every person you meet for directions, but that would be exhausting for everyone. Instead, people naturally develop a better system: they share directions only when needed, and once everyone knows the way, they stop repeating it constantly.
This is exactly how RPL routing works in IoT networks. When devices first join a network, they need to figure out the best path to send their data to the internet gateway. They do this by listening to nearby devices and choosing a good neighbor to forward their messages through. Once the network is stable and everyone knows their routes, devices stop broadcasting updates constantly to save battery power. But if something changes like a device moves or fails, they quickly share the new information so everyone can update their routes.
The clever part is the Trickle algorithm, which automatically adjusts how often devices talk to each other. When the network is stable, they might only check in once an hour to save energy. But when something changes, they immediately switch to checking every few seconds until things settle down again. It’s like how people at that party would quietly chat once everyone knows where the exit is, but would start talking urgently if someone discovered a fire alarm.
Sensor Squad: Two Ways to Remember Routes!
“RPL has two modes, and picking the right one is super important,” said Max the Microcontroller. “In Storing mode, every device remembers the routes to all devices below it in the tree. It is like every person in a relay chain knowing the full list of people behind them.”
“But that takes memory,” Sammy the Sensor pointed out. “Tiny IoT devices might only have a few kilobytes of RAM. If there are 500 devices in the network, storing all those routes is impossible!”
“That is where Non-Storing mode comes in,” explained Lila the LED. “In this mode, only the root keeps track of where everyone is. When it needs to send a message to a specific device, it writes the full route into the message header – like writing turn-by-turn directions on an envelope instead of trusting every post office to know the way.”
“And the Trickle algorithm manages how often everyone talks,” added Bella the Battery. “When the network is calm, devices barely whisper – maybe once an hour. But when something changes, like a device failing, everyone starts chattering quickly until things settle down. It is the perfect balance between staying informed and saving energy!”
23.2 Understanding Trickle: The “Polite Gossip” Protocol
The Trickle algorithm is RPL’s secret weapon for efficient network-wide consistency. Think of it as a polite conversation at a party:
The Party Metaphor: How Trickle Works
Imagine you’re at a party where everyone should know the same information (like when dinner is served):
The Social Dynamics:
At a party, if everyone says the same thing (consistent state), you stay quiet. But if you hear something different (inconsistency), you speak up. Over time, conversation naturally decreases as consensus forms.
The Five Rules of Polite Gossip:
- Listen first: When you arrive, listen to what others are saying (gather neighbor DIOs)
- Stay quiet if consistent: If everyone’s saying the same thing, no need to repeat (suppress transmission)
- Speak up if different: If you hear something wrong, correct it immediately (reset interval on inconsistency)
- Gradually relax: As consensus forms, conversations naturally decrease (double interval on stability)
- Reset on news: When new information arrives, the buzz picks up again (interval reset)
This is exactly how RPL nodes behave when spreading DODAG information!
Technical Mapping: Party to Network:
| Party Element | Trickle Mechanism | Technical Detail |
|---|---|---|
| Party | RPL Network | DODAG topology |
| Gossip | DIO messages | DODAG Information Objects |
| Same story | Consistent state | Same DODAG Version, RANK, parent |
| Different story | Inconsistency | New Version, RANK change, topology change |
| Listen period | Interval timer I |
Current interval: Imin <= I <= Imax |
| Counter | Consistency counter c |
How many consistent DIOs heard |
| Threshold | Redundancy constant k |
Suppress if c >= k |
| Speak up | Broadcast DIO | Share DODAG information |
| Stay quiet | Suppress transmission | Save energy when c >= k |
| Conversation dying down | Double interval | I = min(2xI, Imax) |
| New gossip | Reset interval | I = Imin on inconsistency |
How Trickle Achieves Efficiency:
Academic Resource: Trickle Execution Example
The Cambridge Mobile and Sensor Systems course demonstrates Trickle timing with a 3-node example using redundancy threshold k=1:
Timeline Analysis:
| Time | Node 1 | Node 2 | Node 3 | Action |
|---|---|---|---|---|
| t=0 | c=0 | c=0 | c=0 | All start listening |
| t1a | TX | - | - | Node 1 transmits (c=0 < k=1) |
| t1a-all | - | c=1 | c=1 | Nodes 2,3 increment c on reception |
| t2a | - | SUPPRESS | - | Node 2 suppresses (c=1 >= k=1) |
| t2b | - | - | SUPPRESS | Node 3 suppresses (c=1 >= k=1) |
| interval x 2 | - | - | - | All nodes double interval (stable) |
Key Insight: When k=1, nodes suppress transmission after hearing just one consistent message from a neighbor. This exponentially reduces overhead while maintaining network awareness.
Source: University of Cambridge - Mobile and Sensor Systems (Prof. Cecilia Mascolo)
23.3 Trickle Timer Behavior: The Three Scenarios
Scenario 1: Stable Network (Doubling Interval)
What happens: Everyone at the party is saying the same thing, so conversation naturally dies down.
Technical behavior:
- Node starts interval I = Imin (e.g., 10s)
- During listening period, hears k or more consistent DIOs from neighbors
- Suppresses transmission (stays quiet)
- Doubles interval: I = min(2xI, Imax)
- Next interval: 10s to 20s to 40s to 80s to … to 1 hour
Example timeline:
t=0s: I=10s, Heard 5 DIOs (all RANK=100), Suppress, Next I=20s
t=20s: I=20s, Heard 4 DIOs (all RANK=100), Suppress, Next I=40s
t=60s: I=40s, Heard 3 DIOs (all RANK=100), Suppress, Next I=80s
t=140s: I=80s, Heard 2 DIOs (all RANK=100), Suppress, Next I=160s
...
t=3600s: I=3600s (1 hour), Heard 1 DIO, Suppress, Stay at I=3600s (Imax)Energy savings: After 10 doublings, a node that would have sent 360 DIOs/hour now sends just 1 DIO/hour = 360x reduction!
Putting Numbers to It
The exponential backoff provides dramatic energy savings. Let’s quantify the Trickle interval growth:
\[I_{n+1} = \min(2 \times I_n, I_{\max})\]
Starting from \(I_{\min} = 10s\), the interval doubles each cycle:
\[10s \to 20s \to 40s \to 80s \to 160s \to 320s \to 640s \to 1280s\]
After 7 doublings, we reach \(I_{\max} = 1280s \approx 21 \text{ minutes}\).
For example: In 1 hour, with periodic DIOs every 10s, a node would transmit \(3600s / 10s = 360\) messages. With Trickle at \(I_{\max} = 1280s\), only \(3600s / 1280s \approx 3\) messages. This means energy reduction of \((360 - 3) / 360 = 99.2\%\) for control overhead in stable networks.
Scenario 2: Network Inconsistency (Reset Interval)
What happens: Someone says something different at the party—everyone starts talking to correct it!
Technical behavior:
- Node hears DIO with different DODAG information:
- Different DODAG Version Number
- Parent changed RANK
- New Objective Function
- Immediately broadcasts DIO to share correct information
- Resets interval: I = Imin (back to minimum)
- Counter resets: c = 0
- Network rapidly converges to new consistent state
Example timeline:
t=0s: I=3600s (stable at 1 hour interval)
t=100s: INCONSISTENCY DETECTED! Parent RANK changed 100->150
-> Broadcast DIO immediately
-> Reset I=10s (Imin)
-> Reset counter c=0
t=110s: I=10s, Heard 6 DIOs (all consistent with new RANK), Suppress, I=20s
t=130s: I=20s, Heard 5 DIOs (consistent), Suppress, I=40s
t=170s: I=40s, Heard 4 DIOs (consistent), Suppress, I=80s
...
(Network re-stabilizes and returns to hourly DIOs)Why this matters: Topology changes propagate in seconds (multiple nodes reset timers), but stable network returns to hourly updates = responsive yet efficient!
Scenario 3: Insufficient Redundancy (Broadcast)
What happens: Not enough people are talking at the party—you chime in to maintain awareness.
Technical behavior:
- Node hears fewer than k consistent DIOs during interval
- Counter c < k (e.g., c=1, k=3)
- Broadcasts DIO to ensure information dissemination
- Doubles interval normally: I = min(2xI, Imax)
- Ensures at least k nodes transmit per interval (redundancy)
Example scenario:
Sparse network area (only 2 neighbors):
t=0s: I=10s, Heard 1 DIO (c=1 < k=3), BROADCAST DIO, Next I=20s
t=20s: I=20s, Heard 2 DIOs (c=2 < k=3), BROADCAST DIO, Next I=40s
t=60s: I=40s, Heard 2 DIOs (c=2 < k=3), BROADCAST DIO, Next I=80sNetwork edge behavior: Nodes at DODAG edges (fewer neighbors) broadcast more frequently to maintain connectivity, while dense core suppresses aggressively.
23.4 Why Trickle Saves Energy in Stable Networks
The genius of Trickle is exponential backoff combined with instant reset:
Energy math:
- Periodic DIO (no Trickle): Send every 10s = 360 DIOs/hour = 360 transmissions
- Trickle (stable network): Send every 1 hour = 1 DIO/hour = 1 transmission
- Savings: 99.7% reduction in control overhead!
Real-world battery impact:
Assumptions: 5mA transmit current, 3ms transmission time, 2000mAh battery
Why This Matters for IoT:
The Trickle algorithm enables RPL to achieve network-wide consistency with minimal energy expenditure:
- Stable network (99% of the time): Nodes send DIOs every 10-60 minutes, conserving battery
- Network change (1% of the time): Nodes send DIOs every 10-500ms for rapid convergence
- Polite suppression: If 5 neighbors already broadcasted the same DIO, no need to add redundancy
- Instant reaction: Inconsistency (e.g., RANK change, parent failure) triggers immediate reset to fast interval
Real-world impact: In a 100-node smart building, Trickle reduces DIO overhead from ~600,000 messages/day (periodic every 10s) to ~14,400 messages/day (adaptive, mostly hourly), extending battery life by 41x while maintaining sub-minute response to topology changes.
RFC 6206 Parameters:
- Imin: Minimum interval (10ms-1s) - fast response to changes
- Imax: Maximum interval (1min-1hr) - low overhead when stable
- k: Redundancy constant (2-8) - consistency threshold before suppression
- c: Listen-only period (0-50% of interval) - gather info before deciding
23.4.1 Interactive: Trickle Interval Calculator
Explore how the Trickle exponential backoff reduces DIO overhead:
23.5 Trickle Algorithm: Visual Explanation
Trickle is “polite gossip” - nodes share information only when needed.
23.5.1 The Algorithm in 4 Steps
23.5.2 Key Parameters
| Parameter | Meaning | Typical Value |
|---|---|---|
| Imin | Minimum interval (fast response) | 100ms |
| Imax | Maximum interval (energy saving) | 16 minutes |
| k | Redundancy constant (suppression threshold) | 1-5 |
| c | Consistency counter (heard transmissions) | Incremented per consistent message |
| t | Random transmission time in [I/2, I] | Prevents collisions |
23.5.3 Why Trickle Works
- Consistent network: Everyone agrees, intervals grow exponentially, minimal traffic
- Inconsistency detected: Reset interval to Imin, quick resync across network
- New node joins: Hears inconsistent info, triggers rapid updates from neighbors
- Suppression: If enough neighbors already transmitted (c >= k), stay silent to save energy
23.6 RPL Routing Modes
RPL supports two modes with different memory/performance trade-offs:
23.6.1 Storing Mode
Each node maintains routing table for its sub-DODAG.
How It Works:
- DAO messages: Nodes advertise reachability to parents
- Routing tables: Each node stores routes to descendants
- Packet forwarding: Node looks up destination in table, forwards to appropriate child
Example Route (E to F):
Step 1: E sends packet to parent B (upward)
Step 2: B checks routing table: "F is my child"
Step 3: B forwards directly to F (downward)
Route: E -> B -> F (optimal)Advantages:
- Efficient routing: Optimal paths (no detour through root)
- Low latency: Direct routes between any nodes
- Root not bottleneck: Distributed routing decisions
Disadvantages:
- Memory overhead: Each node stores routing table
- Scalability: Routing tables grow with network size
- Updates: DAO messages for every node change
Best For:
- Devices with sufficient memory (32+ KB RAM)
- Networks requiring low latency
- Point-to-point communication common
23.6.2 Non-Storing Mode
Only root maintains routing information; exploits source routing.
How It Works:
- DAO to root: All nodes send DAO directly to root (upward)
- Root stores all routes: Only root has complete routing table
- Source routing: Root inserts complete path in packet header
- Nodes forward: Follow instructions in packet header (no table lookup)
Example Route (E to F):
Step 1: E sends packet to parent B (upward, default route)
Step 2: B forwards to parent A (root) (upward, default route)
Step 3: A (root) checks routing table: "F via B"
Step 4: A inserts source route: [B, F]
Step 5: A sends to B with route in header
Step 6: B forwards to F following route
Route: E -> B -> A -> B -> F (via root)Advantages:
- Low memory: Nodes don’t store routing tables (just parent)
- Simple nodes: Minimal routing logic
- Scalability: Network size doesn’t affect node memory
Disadvantages:
- Suboptimal routes: All point-to-point traffic via root
- Higher latency: Extra hops through root
- Root bottleneck: All routing decisions at root
- Header overhead: Source route in every packet
Best For:
- Resource-constrained devices (< 16 KB RAM)
- Primarily many-to-one traffic (sensors to gateway)
- Point-to-point communication rare
- Large networks (many nodes)
23.6.3 Storing vs Non-Storing Comparison
| Aspect | Storing Mode | Non-Storing Mode |
|---|---|---|
| Routing Table | Distributed (all nodes) | Centralized (root only) |
| Node Memory | Higher (routing table) | Lower (parent pointer only) |
| Route Optimality | Optimal (direct paths) | Suboptimal (via root) |
| Latency | Lower | Higher (extra hops) |
| Root Load | Low | High (all routing decisions) |
| Scalability | Limited by node memory | Limited by root capacity |
| DAO Destination | Parent | Root (through parents) |
| Header Overhead | Low | High (source routing) |
| Best For | Powerful nodes, low latency | Constrained nodes, many-to-one |
23.7 RPL Traffic Patterns
RPL optimizes for different traffic directions:
23.7.1 Many-to-One (Upward Routing)
Pattern: Many sensors to Single gateway/root
How:
- Each node knows parent (from DODAG construction)
- Default route: Send to parent (toward root)
- No routing table needed (upward)
Example: Temperature sensors reporting to cloud
Sensor 3 -> Node 1 -> Root -> Internet -> Cloud
(Upward along DODAG tree)Optimization:
- Most common traffic in IoT (data collection)
- Minimal state: Just parent pointer
- Efficient: Direct path to root
23.7.2 One-to-Many (Downward Routing)
Pattern: Single controller to Many actuators
How:
- Storing mode: Each node has routing table, forwards optimally
- Non-storing mode: Root inserts source route, nodes follow
Example: Controller sends “turn off” to all lights
Root -> [Multicast or unicast to each light]Modes:
- Storing: Root to Node 1 to Light 3 (optimal)
- Non-storing: Root inserts route [Node 1, Light 3]
23.7.3 Point-to-Point (P2P)
Pattern: Sensor to Actuator (peer-to-peer)
How:
- Upward then downward (via common ancestor, often root)
- Storing mode: May find shorter path
- Non-storing mode: Always via root
Example: Motion sensor triggers light
Storing: Sensor 3 -> Node 1 -> Light 4 (3 hops, if both under Node 1)
Non-Storing: Sensor 3 -> Node 1 -> Root -> Node 2 -> Light 4 (4 hops)23.8 Common Pitfalls
Common Pitfalls
1. Choosing the Wrong RPL Mode (Storing vs Non-Storing)
- Mistake: Using Storing mode on severely memory-constrained nodes (e.g., 2KB RAM sensors), causing routing table overflow and network instability when nodes cannot store routes to all descendants
- Why it happens: Storing mode provides more efficient point-to-point routing, so developers default to it without calculating memory requirements. Each routing entry requires ~20-40 bytes; a node with 50 descendants needs 1-2KB just for routing tables
- Solution: Calculate your network’s memory budget before choosing modes. Use Non-Storing mode when: (1) nodes have <8KB RAM, (2) network depth exceeds 4-5 hops, or (3) point-to-point traffic is rare. In Non-Storing mode, all downward routes go through the root, which must have sufficient memory but leaf nodes stay lightweight. For hybrid needs, consider using Storing mode only for nodes with adequate memory
2. Aggressive Trickle Timer Settings Causing Network Storms
- Mistake: Setting Trickle timer Imin too low (e.g., 100ms) or Imax too small (e.g., 4 doublings) in dense networks, causing constant DIO flooding that overwhelms the radio channel and drains batteries
- Why it happens: Developers test with small networks (3-5 nodes) where aggressive timers converge quickly. In production deployments with 50+ nodes, the same settings cause every node to transmit DIOs simultaneously during network events
- Solution: Start with conservative Trickle settings: Imin = 2-4 seconds, Imax = 16-20 doublings (giving maximum intervals of hours). For stable networks, RPL naturally reduces DIO frequency through Trickle’s exponential backoff. Only decrease timers if convergence time is unacceptable for your application. Monitor DIO message rates - if you see >1 DIO/minute/node in steady state, your Trickle parameters are too aggressive
3. Single DODAG Root Without Redundancy
- Mistake: Deploying production RPL networks with only one border router as the DODAG root, creating a single point of failure where root failure disconnects the entire network from the Internet
- Why it happens: RPL documentation focuses on single-root DODAGs for simplicity. Adding multiple roots requires understanding RPL instances, DODAG IDs, and root coordination, which adds deployment complexity
- Solution: For production deployments, configure multiple border routers with the same DODAG ID but different root preferences. Use RPL’s multiple DODAG instance feature to provide backup paths. Alternatively, deploy redundant roots with different DODAG IDs and configure important nodes to join both. Monitor root health and implement automatic failover scripts that promote a secondary root if the primary becomes unreachable
23.9 Visual Reference Gallery
RPL and DODAG Visualizations
The following diagrams provide additional perspectives on RPL routing concepts.
23.9.1 DODAG Construction Process
23.9.2 RPL Protocol Elements
23.9.3 DODAG Structure
23.9.4 Rank Computation
23.10 Original Source Figures (Alternative Views)
The following figures from the CP IoT System Design Guide provide alternative visual representations of RPL concepts covered in this chapter.
DAG and DODAG Structures (Source Figure)
Source: CP IoT System Design Guide, Chapter 4 - Routing
RPL DAG and DODAG Formation Sequence
Source: CP IoT System Design Guide, Chapter 4 - Routing
RPL RANK Calculation Visualization
Source: CP IoT System Design Guide, Chapter 4 - Routing
Building a DODAG - Step-by-Step Process
Source: CP IoT System Design Guide, Chapter 4 - Routing
Interactive: RPL DODAG Builder
Build and visualize an RPL DODAG (Destination Oriented Directed Acyclic Graph) interactively. Watch how nodes join the network, calculate their RANK based on different objective functions, and see DIO messages propagate through the tree.
Instructions:
- Click “Add Node” to add new nodes to the network
- Select different Objective Functions to see how RANK calculation changes
- Watch how each node selects its parent based on the objective function
- Observe the DIO propagation from root outward
- Use “Reset Network” to start fresh
Objective Function Details:
| Function | RANK Calculation | Best For |
|---|---|---|
| Hop Count (OF0) | Parent RANK + 256 per hop | Simple networks, equal link quality |
| ETX | Parent RANK + (ETX x 256) | Lossy networks, reliability focus |
| Energy | Parent RANK + (Energy x 2) | Battery-powered, lifetime optimization |
Try This:
- Add 5-6 nodes and observe the tree structure
- Switch objective functions and reset - notice how the same nodes may select different parents
- Watch the orange DIO pulse showing message propagation
- Note how RANK increases as you move away from ROOT
23.11 Worked Example: Trickle Timer Overhead and Mode Selection for a 500-Node Warehouse
Scenario: A logistics warehouse deploys 500 Zigbee-based sensors (temperature, humidity, motion) across 10,000 m2 with 5 border routers (RPL roots). The network must handle three traffic patterns: sensor data upward (every 2 minutes), forklift tracking commands downward (every 5 seconds to 20 tag readers), and point-to-point alerts from motion sensors to nearby alarm panels. The team must choose between Storing and Non-Storing mode, and tune the Trickle timer to minimize control overhead without sacrificing convergence speed.
Step 1: Calculate Trickle timer overhead
Default Trickle parameters: I_min = 4 seconds, I_max = 17 minutes (2^8 x 4s), k = 1 (redundancy constant).
Stable network (no topology changes):
At steady state, each node’s Trickle interval reaches I_max = 17 minutes. With k = 1, a node suppresses its DIO if it hears at least 1 consistent DIO from a neighbor during the interval.
| Metric | Calculation | Value |
|---|---|---|
| DIO size (typical) | ICMPv6 header + RPL options | 80 bytes |
| Nodes sending (non-suppressed, ~30% in dense network) | 500 x 0.30 | 150 nodes |
| DIOs per hour | 150 x (60/17) | ~529 DIOs/hour |
| DIO traffic per hour | 529 x 80 bytes | 42.3 KB/hour |
| DIO traffic per day | 42.3 x 24 | 1,015 KB/day |
Network with one topology change per hour (forklift moves, sensor reconnects):
When inconsistency is detected, nodes reset Trickle to I_min = 4 seconds. The reset propagates through the DODAG:
| Phase | Duration | DIOs generated |
|---|---|---|
| Reset burst (all neighbors of changed node) | 4-8 seconds | ~15 nodes x 2 = 30 DIOs |
| Exponential growth | 8s, 16s, 32s, 1m, 2m, 4m, 8m, 17m | ~100 DIOs total during re-convergence |
| Total per event | ~3 minutes to stabilize | ~130 extra DIOs |
| One event per hour | 24 events/day | 130 x 24 = 3,120 extra DIOs/day |
Extra overhead from topology changes: 3,120 x 80 = 249.6 KB/day, bringing total DIO traffic to 1,265 KB/day.
Compared to naive periodic broadcast (every 10 seconds, all 500 nodes): 500 x 8,640/day x 80 = 345.6 MB/day. Trickle achieves 99.6% reduction.
Step 2: Memory requirements for Storing vs Non-Storing mode
Storing mode (each router stores routing table entries for descendants):
| Component | Size per entry | Entries per node (avg depth 4, ~100 descendants for inner nodes) |
|---|---|---|
| Routing table entry (destination + next-hop + lifetime) | 28 bytes | 100 entries for inner nodes, 0 for leaf nodes |
| Neighbor table | 48 bytes per neighbor | ~5 neighbors |
| Node type | Count | Memory per node | Total |
|---|---|---|---|
| Border routers (root, all 500 descendants) | 5 | 500 x 28 = 14,000 bytes | 70 KB |
| Inner routers (avg 100 descendants) | 50 | 100 x 28 = 2,800 bytes | 140 KB |
| Leaf sensors (0 descendants) | 445 | 0 routing + 240 neighbor = 240 bytes | 107 KB |
| Total network routing memory | 317 KB |
Non-Storing mode (only root stores routes, source routing headers):
| Component | Size | Location |
|---|---|---|
| Root routing table (all 500 nodes) | 500 x 28 = 14,000 bytes per root | 5 roots x 14 KB = 70 KB total |
| Node routing memory | 0 (no routing table) | - |
| Source routing header per downward packet | 8 + (hops x 16) bytes | Avg 4 hops = 72 bytes per packet |
| Node type | Count | Memory per node | Total |
|---|---|---|---|
| Border routers | 5 | 14,000 bytes | 70 KB |
| All other nodes | 495 | 240 bytes (neighbor table only) | 119 KB |
| Total network routing memory | 189 KB |
Step 3: Evaluate mode against traffic patterns
| Traffic Pattern | Storing Mode | Non-Storing Mode |
|---|---|---|
| Sensor data upward (480 nodes every 2 min) | Efficient: follows default parent | Efficient: follows default parent |
| Forklift commands downward (20 tags, every 5s) | Direct path via routing tables, avg 4 hops | All traffic routes through root, avg 7 hops (up 4 + down 3) |
| P2P motion-to-alarm (rare, ~10/day) | Routes through common ancestor, avg 3 hops | Routes through root, avg 8 hops |
| Downward packet overhead | 0 extra header bytes | 72 bytes source routing header per packet |
Forklift tracking bandwidth (Non-Storing penalty):
| Metric | Storing | Non-Storing |
|---|---|---|
| Commands per second | 4 (20 tags / 5s) | 4 |
| Avg hops per command | 4 | 7 |
| Command size | 48 bytes | 48 + 72 = 120 bytes |
| Bandwidth (commands only) | 4 x 4 x 48 = 768 bytes/s | 4 x 7 x 120 = 3,360 bytes/s |
| Daily bandwidth | 66 MB | 290 MB |
Non-Storing mode uses 4.4x more bandwidth for downward forklift commands because every packet must traverse the root and carry source routing headers.
Decision: Storing mode is the right choice. The warehouse has significant downward traffic (forklift tracking) and point-to-point traffic (motion alerts). The inner routers (Zigbee modules with 32 KB RAM) can accommodate 2.8 KB routing tables. Non-Storing mode would waste 224 MB/day of additional bandwidth on source routing headers.
Trickle tuning: Keep defaults (I_min = 4s, I_max = 17 min, k = 1). With one topology event per hour from forklift movement, the extra 250 KB/day DIO overhead is negligible compared to the 66 MB/day of application traffic.
Key insight: The Storing vs Non-Storing decision is driven by traffic patterns, not just memory. This warehouse’s mix of upward sensor data, downward forklift commands, and point-to-point motion alerts makes Storing mode clearly superior despite its higher per-node memory. If the deployment were sensor-only (upward traffic only), Non-Storing would save 128 KB of network memory with no bandwidth penalty. Always analyze your traffic mix before choosing.
Key Concepts
- Trickle Timer: A self-adjusting rate-limiting algorithm (RFC 6206) used by RPL to control DIO broadcast frequency adaptively.
- Storing Mode (Mode 2): RPL routing mode where each router node maintains a routing table for its subtree; enables direct P2P and efficient P2MP routing without involving the root.
- Non-Storing Mode (Mode 1): RPL routing mode where only the root maintains full routing tables; downlink packets use source routing inserted by the root.
- Mixed Mode: An RPL deployment combining storing and non-storing nodes; routers near the root may use storing mode while leaf-adjacent routers use non-storing.
- Source Routing Header: An IPv6 extension header used in Non-Storing Mode containing the explicit path for downward packet delivery.
23.12 Summary
This chapter covered the Trickle algorithm and RPL routing modes:
- Trickle Algorithm: Adaptive control message timing that achieves 99.7% reduction in DIO overhead through exponential backoff and instant reset on inconsistency
- Three Scenarios: Stable network (doubling interval), inconsistency (reset interval), insufficient redundancy (broadcast)
- Storing Mode: Distributed routing tables enable optimal paths but require more memory per node
- Non-Storing Mode: Centralized routing at root minimizes node memory but routes through root
- Traffic Patterns: Many-to-one (upward), one-to-many (downward), and point-to-point routing
- Common Pitfalls: Wrong mode selection, aggressive Trickle settings, single root without redundancy
23.13 Concept Relationships
This chapter combines two critical RPL topics and connects to the full learning path:
Trickle Algorithm:
- Builds on RPL DODAG Construction - Controls DIO timing during and after formation
- Enables energy efficiency - 99.7% reduction in control overhead
- Implements “polite gossip” - Adaptive messaging based on network consistency
Routing Modes:
- Uses DODAG structure from RPL Introduction
- Storing Mode: Distributed routing tables for optimal paths
- Non-Storing Mode: Source routing via root for memory-constrained nodes
Traffic Patterns:
- Many-to-One (MP2P): Sensor data flowing upward
- One-to-Many (P2MP): Commands flowing downward
- Point-to-Point (P2P): Direct sensor-actuator communication
Prerequisites:
- RPL DODAG Visual Guide - Understanding DODAG formation
- RPL Worked Example - RANK calculation and parent selection
Leads To:
- RPL Labs and Quiz - Design decisions: mode selection, Trickle tuning
- RPL Production Review - Real-world deployment scenarios
Contrasts:
- Trickle vs Periodic Updates - Adaptive vs fixed-rate control messages
- Storing vs Non-Storing - Memory/latency trade-off
- RPL vs OSPF/RIP - Energy efficiency through specialization
23.14 See Also
Trickle Algorithm:
- RFC 6206: “The Trickle Algorithm” - Complete specification with formal proofs
- RFC 6550 Section 8.3: “Trickle Timer” - RPL integration
- Levis et al. “Trickle: A Self-Regulating Algorithm” - Original research paper
Routing Modes:
- RFC 6550 Section 9: “Downward Routes” - Storing mode DAO processing
- RFC 6550 Section 9.7: “Non-Storing Mode” - Source routing implementation
- RFC 6550 Section 12: “Mode of Operation (MOP)” - Configuration options
Related Chapters:
- RPL DODAG Trickle - Detailed Trickle algorithm walkthrough
- RPL Production Review - Mode selection framework
- 6LoWPAN Fragmentation - Interaction with source routing headers
Implementation Guides:
- Contiki-NG RPL Configuration - Trickle parameter tuning guide
- RIOT OS RPL Module - Storing/Non-Storing mode comparison
- Thread Specification - RPL variant with Non-Storing mode
Energy Analysis:
- Wireless Sensor Networks - Energy budgeting principles
- Dunkels et al. “Powertrace: Network-level Power Profiling for Low-power Wireless Networks” - Measuring RPL overhead
Deployment Case Studies:
- Itron OpenWay Riva - Trickle tuning for 35M smart meters
- Philips Hue - Non-Storing mode in Thread-based lighting
- Industrial WSN - Storing mode for low-latency control
Tools:
- Wireshark RPL Dissector - Observe Trickle interval doubling
- Contiki Cooja Energy Estimation - Measure Trickle energy savings
- RPL-DASH Dashboard - Visualize mode comparison
Comparison Resources:
- Thread Routing - Thread’s RPL variant (Non-Storing focused)
- Zigbee Routing - Alternative low-power routing
- AODV vs RPL - On-demand vs proactive routing energy comparison
23.15 What’s Next
| Next | Chapter |
|---|---|
| Practice | RPL Labs and Quiz |
| Deploy | RPL Production Review |
| Trickle deep dive | RPL DODAG Trickle |
| Series overview | RPL Fundamentals and Construction |