713  RPL Summary and Interactive Tools

713.1 Common Pitfalls

WarningCommon 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

713.2 Summary

  • Distance-Vector Protocol: RPL is designed specifically for Low-Power and Lossy Networks (LLNs), using parent pointers and RANK values rather than complex link-state databases
  • DODAG Topology: Destination Oriented Directed Acyclic Graph structure with single root enables loop-free routing and efficient many-to-one traffic patterns
  • RANK Mechanism: Hierarchical position values prevent routing loops by enforcing that packets flow only toward lower RANK (toward root), calculated using objective functions
  • Control Messages: DIO (DODAG Information Object) advertises network, DIS (DODAG Information Solicitation) requests information, DAO (Destination Advertisement Object) builds downward routes
  • Routing Modes: Storing mode distributes routing tables across nodes for optimal paths, while Non-Storing mode centralizes routing at root to minimize node memory requirements
  • Traffic Optimization: Upward routing (many-to-one) uses minimal state with parent pointers, downward and point-to-point routing leverages mode-specific mechanisms
  • IoT-Specific Design: Trickle timer algorithm, ETX metrics, and support for multiple instances address resource constraints and lossy wireless links

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:

  1. Click β€œAdd Node” to add new nodes to the network
  2. Select different Objective Functions to see how RANK calculation changes
  3. Watch how each node selects its parent based on the objective function
  4. Observe the DIO propagation from root outward
  5. 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:

  1. Add 5-6 nodes and observe the tree structure
  2. Switch objective functions and reset - notice how the same nodes may select different parents
  3. Watch the orange DIO pulse showing message propagation
  4. Note how RANK increases as you move away from ROOT

713.3 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.

Original textbook figure showing the difference between a general Directed Acyclic Graph (DAG) with multiple roots and a DODAG (Destination-Oriented DAG) with a single root destination, illustrating how RPL creates tree-like structures for efficient IoT routing

DAG and DODAG comparison from original source

Source: CP IoT System Design Guide, Chapter 4 - Routing

Step 1 of DODAG formation showing initial network state before RPL routing begins, with nodes scattered and no parent relationships established

RPL DAG and DODAG formation step 1

Step 2 of DODAG formation showing nodes beginning to receive DIO messages from the root and establishing initial parent selections

RPL DAG and DODAG formation step 2

Step 3 of DODAG formation showing complete tree structure with all nodes having selected preferred parents and routes to the root

RPL DAG and DODAG formation step 3

Source: CP IoT System Design Guide, Chapter 4 - Routing

Complete visualization of RPL RANK values across a network showing how rank increases with distance from root, with root at rank 0 and leaf nodes at highest rank values

RPL Rank calculation overview

Step 1 of rank calculation showing root advertising rank 0 to immediate neighbors via DIO messages

RPL Rank step 1

Step 2 of rank calculation showing second-tier nodes calculating their rank based on parent rank plus link cost metric

RPL Rank step 2

Step 3 of rank calculation showing further propagation of rank values to deeper nodes in the network topology

RPL Rank step 3

Step 4 showing complete rank assignment across all nodes in the DODAG with final routing paths established

RPL Rank step 4

Source: CP IoT System Design Guide, Chapter 4 - Routing

Complete step-by-step visualization showing how a DODAG is constructed from initial state through final tree structure

Building a DODAG - Complete overview

DODAG building step 1: Root node initiates DODAG by sending first DIO message

Building a DODAG step 1

DODAG building step 2: Neighbors receive DIO, calculate rank, select root as parent

Building a DODAG step 2

DODAG building step 3: Second-tier nodes forward DIO messages to their neighbors

Building a DODAG step 3

DODAG building step 4: More nodes join DODAG, tree structure expands

Building a DODAG step 4

DODAG building step 5: Edge nodes receive DIO and select parents

Building a DODAG step 5

DODAG building step 6: Complete DODAG formed with all nodes having routes to root

Building a DODAG step 6

Source: CP IoT System Design Guide, Chapter 4 - Routing

713.4 What’s Next

Continue to RPL Labs and Quiz to apply your understanding through hands-on network design exercises and test your knowledge with comprehensive quiz questions.