42  RPL Quiz Questions

In 60 Seconds

Comprehensive RPL quiz covering RANK mechanics and loop prevention, memory and performance trade-offs between Storing and Non-Storing modes, the four control message types (DIS, DIO, DAO, DAO-ACK), and why traditional protocols like OSPF are unsuitable for IoT Low-Power and Lossy Networks.

42.1 Learning Objectives

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

• Analyze RANK mechanics: Demonstrate how RANK prevents routing loops and enables hierarchical routing
• Evaluate RPL modes: Justify memory and performance trade-offs between Storing and Non-Storing
• Differentiate control messages: Classify the purpose and flow of DIS, DIO, DAO, and DAO-ACK
• Contrast with traditional routing: Argue why OSPF is unsuitable for IoT LLNs

For Beginners: RPL Quiz

This quiz tests your understanding of RPL concepts, from DODAG construction to the Trickle algorithm. Think of it as a checkpoint that helps you confirm what you have learned and identify areas to review. Each question includes explanations so you can learn from any mistakes.

Sensor Squad: Test Your RPL Knowledge!

“Time for the big quiz!” said Max the Microcontroller. “These questions cover everything from RANK mechanics to control message flows. If you can answer these, you truly understand RPL.”

“My favorite question is about why OSPF cannot work for IoT,” said Sammy the Sensor. “The answer involves memory, processing power, and link stability – all things that make traditional routing protocols fail in our world of tiny batteries and lossy wireless links.”

“Pay attention to the mode comparison questions,” suggested Lila the LED. “Understanding when to use Storing versus Non-Storing mode is the most practical skill you can learn from this quiz. Real deployments depend on getting this right.”

“Each question has a detailed explanation,” added Bella the Battery. “Even if you get the answer right, read the explanation – it often adds context and real-world examples that deepen your understanding. Good luck!”

42.2 Prerequisites

Required Chapters:

• RPL Fundamentals - Core RPL concepts
• RPL Lab: Network Design - Practical design experience
• RPL Knowledge Check - Scenario-based understanding

Estimated Time: 45 minutes

Key Concepts

• RPL Quiz Coverage: Typical RPL quiz questions test: DODAG construction sequence, RANK calculation with specific ETX values, mode selection criteria, Trickle timer behavior, and DIO/DAO message purpose.
• Sample RANK Calculation: Given a root with RANK=256 and a link ETX=1.5, MRHOF calculates child RANK as 256 + (1.5 × 256) = 640; knowing this pattern is essential for quiz problems.
• Mode Selection Criteria: Choose Storing Mode for P2P-heavy or downlink-heavy traffic; choose Non-Storing Mode for sensor-only telemetry on nodes with <8 KB RAM.
• Trickle Reset Triggers: Trickle timer resets when a node detects an RPL inconsistency (lower-version DIO, different DODAG ID, unexpected routing behavior) to rapidly propagate corrections.

42.3 Interactive: Quiz Score Tracker

Track your progress as you work through the 4 quiz questions below. A score of 3 or higher indicates solid mastery.

viewof correctAnswers = Inputs.range([0, 4], {value: 0, step: 1, label: "Questions answered correctly"})

{
  const total = 4;
  const pct = (correctAnswers / total * 100).toFixed(0);
  const target = Math.ceil(0.8 * total);  // 80% mastery threshold = 4 questions
  const mastered = correctAnswers >= target;
  const barColor = mastered ? "#16A085" : (correctAnswers >= 2 ? "#E67E22" : "#E74C3C");
  const barWidth = (correctAnswers / total * 100).toFixed(0);
  const msg = mastered
    ? "Mastery achieved! You understand the core RPL concepts."
    : `${target - correctAnswers} more correct answer${target - correctAnswers > 1 ? "s" : ""} needed to reach 80% mastery.`;

  return html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid ${barColor};">
    <p style="margin:0 0 0.5rem;"><strong>Score: ${correctAnswers}/${total} (${pct}%)</strong> &mdash; Mastery target: ${target}/${total} (80%)</p>
    <div style="background:#dee2e6; border-radius:4px; height:12px; width:100%; margin-bottom:0.5rem;">
      <div style="background:${barColor}; border-radius:4px; height:12px; width:${barWidth}%; transition:width 0.3s;"></div>
    </div>
    <p style="margin:0; color:${barColor};">${msg}</p>
  </div>`;
}

42.4 Quiz: RPL Routing Protocol

Question 1: RANK Purpose

What is the primary purpose of RANK in RPL?

1. To measure the distance in meters from the root
2. To prevent routing loops by defining hierarchical position
3. To prioritize packets based on importance
4. To encrypt routing information

Click to see answer

Answer: B) To prevent routing loops by defining hierarchical position

Explanation:

RANK Definition: RANK is a scalar value representing a node’s position in the DODAG hierarchy relative to the root.

Primary Purpose: Loop Prevention

How RANK Prevents Loops:

1. Root has minimum RANK (typically 0)
2. RANK increases as you move away from root
3. Upward routing rule: Packets forwarded to nodes with lower RANK
4. Parent selection rule: Node cannot choose parent with higher RANK

Loop Prevention Example:

Figure 42.1: RANK hierarchy preventing routing loops through hierarchical constraints

Attempt to create loop:

• Node C wants to choose Node A as parent:
  • Current RANK: 400
  • Node A RANK: 100
  • ALLOWED (100 < 400, moving toward root)
• Node A wants to choose Node C as parent:
  • Current RANK: 100
  • Node C RANK: 400
  • FORBIDDEN (400 > 100, moving away from root = loop!)

Without RANK (vulnerable to loops):

Figure 42.2: Routing loop vulnerability without RANK hierarchy enforcement

Option Analysis:

A) Distance in meters: RANK is not physical distance. RANK is a logical hierarchy in DODAG. Two nodes the same physical distance from the root can have different RANKs based on link quality.

B) Prevent routing loops: Correct. RANK enforces hierarchy and the acyclic property. Rule: Can only route “upward” (decreasing RANK).

C) Prioritize packets: RANK is for routing, not QoS. Packet prioritization uses the IPv6 Traffic Class field or different objective functions.

D) Encrypt routing: RANK is plaintext in DIO messages. Security is handled separately through RPL Security mode or link-layer encryption.

RANK Calculation Factors:

RANK is calculated by the objective function, which may consider: - Hop count: Each hop adds a fixed amount (MinHopRankIncrease = 256 by default per RFC 6550) - ETX: Expected Transmission Count (link quality) - Latency: Time to reach root - Energy: Remaining battery, power consumption

Example Objective Function (OF0 - Hop Count):

Figure 42.3: OF0 hop count objective function with fixed RANK increment per hop

Example Objective Function (ETX-based):

Figure 42.4: ETX-based objective function with link quality-aware parent selection

Conclusion: RANK’s primary purpose is loop prevention by establishing a strict hierarchy where packets can only flow “upward” (toward lower RANK), preventing cycles in the DODAG.

Question 2: Storing vs Non-Storing Mode

In a network of 100 battery-powered sensors sending data to a single gateway (many-to-one traffic), which RPL mode is more appropriate?

1. Storing mode (better routing efficiency)
2. Non-Storing mode (lower memory requirements)
3. Both modes have identical performance for this scenario
4. RPL doesn’t support many-to-one traffic well

Click to see answer

Answer: C) Both modes have identical performance for this scenario

Explanation:

Many-to-One Traffic is RPL’s primary use case and is handled identically in both modes.

How Many-to-One Works in RPL:

Upward Routing (toward root): - Every node knows its parent (from DODAG construction) - Default route: Send to parent - No routing table needed for upward routes

Both Modes:

Figure 42.5: Many-to-one upward routing using parent pointers toward root gateway

Storing Mode - Many-to-One:

• Upward routing: Uses parent pointer (NOT routing table)
• Routing table: Used for downward/P2P, not many-to-one
• Memory: Routing table stored but not used for this traffic

Non-Storing Mode - Many-to-One:

• Upward routing: Uses parent pointer (same as Storing)
• No routing table: Not needed for upward routing
• Memory: Lower (no table), but doesn’t matter for this traffic

Performance Comparison:

Aspect	Storing Mode	Non-Storing Mode
Hop Count	Same (upward to root)	Same (upward to root)
Latency	Same	Same
Forwarding Complexity	Same (parent lookup)	Same (parent lookup)
Memory Used	Parent pointer + routing table	Parent pointer only
Bandwidth	Same	Same

Key Insight: Routing tables are for downward/P2P routes!

Option Analysis:

A) Storing mode (better routing efficiency): Storing mode adds no efficiency for many-to-one. Routing tables help with downward (root to sensors) and P2P (sensor to sensor). Upward routing doesn’t use routing tables.

B) Non-Storing mode (lower memory): True but not more appropriate for this traffic pattern. Memory savings occur, but same routing performance.

C) Both modes have identical performance: Correct. Many-to-one uses same mechanism (parent pointers). Same hop count and latency.

D) RPL doesn’t support many-to-one: Wrong. Many-to-one is RPL’s primary design goal. RPL specifically optimized for sensors-to-gateway data collection.

When Modes Differ:

Scenario	Performance Difference
Many-to-One	Identical
One-to-Many	Similar (Non-Storing adds header)
Point-to-Point	Storing can be better

Conclusion: For many-to-one traffic, both RPL modes have identical routing performance. The choice between modes should be based on memory constraints and other traffic patterns, not many-to-one routing efficiency.

Checkpoint: RPL Mode Understanding

Question 3: RPL Control Messages

Which RPL control message is used by a node to request DODAG information from neighbors?

1. DIO (DODAG Information Object)
2. DIS (DODAG Information Solicitation)
3. DAO (Destination Advertisement Object)
4. DAO-ACK (DAO Acknowledgment)

Click to see answer

Answer: B) DIS (DODAG Information Solicitation)

Explanation:

RPL Control Messages (all ICMPv6):

Figure 42.6: RPL control message types and their sender roles in DODAG formation

DIS (DODAG Information Solicitation):

Purpose: Request DODAG information from neighbors

When Used:

1. New node joins network: Doesn’t know about any DODAG
2. Node loses DODAG info: Parent moved, connection lost
3. Proactive discovery: Node wants to find better DODAG

Message Flow:

Figure 42.7: DIS/DIO message exchange for new node DODAG discovery and parent selection

DIS Contents:

• Solicitation flags: What kind of DODAG information desired
• Predicates: Conditions for response (optional)
• Usually sent to multicast address (all RPL nodes)

Example Scenario:

Figure 42.8: Seven-step RPL network joining sequence from power-on to DODAG membership

Option Analysis:

A) DIO (DODAG Information Object): Purpose is to advertise DODAG information (not request). Sent periodically by root and nodes using Trickle timer.

B) DIS (DODAG Information Solicitation): Correct. Purpose is to request DODAG information. Triggers DIO response from neighbors.

C) DAO (Destination Advertisement Object): Purpose is to advertise reachability (not request DODAG info). Sent upward toward root to build downward routes.

D) DAO-ACK (DAO Acknowledgment): Purpose is to confirm DAO receipt (not request DODAG info). Optional reliability mechanism.

Message Relationships:

Figure 42.9: Complete RPL DODAG formation sequence with DIO propagation and DAO confirmation

Trickle Timer and DIS:

Without DIS (passive): - Nodes wait for periodic DIO - Trickle timer: DIOs sent infrequently when network stable (minutes) - Problem: New node may wait long time to join

With DIS (active): - New node sends DIS immediately - Neighbors respond with DIO promptly - Benefit: Fast joining (seconds instead of minutes)

DIS Use Cases:

Figure 42.10: Three DIS use cases: initial joining, parent loss recovery, and path optimization

Conclusion: DIS (DODAG Information Solicitation) is the RPL control message used to request DODAG information from neighbors, enabling active network discovery and faster DODAG joining compared to waiting for periodic DIOs.

Question 4: Traditional vs RPL Routing

Why is OSPF (Open Shortest Path First) not suitable for IoT Low-Power and Lossy Networks?

1. OSPF doesn’t support IPv6
2. OSPF requires too much processing power and memory
3. OSPF can’t handle mesh topologies
4. OSPF is proprietary and requires licensing

Click to see answer

Answer: B) OSPF requires too much processing power and memory

Explanation:

OSPF is a link-state routing protocol designed for traditional IP networks (enterprise, ISP). It’s fundamentally incompatible with resource-constrained IoT devices.

Resource Requirements Comparison:

Resource	OSPF	RPL
CPU	GHz, multi-core	MHz, single-core
RAM	MB-GB	KB (10-128 KB)
Flash	MB-GB	KB (32-512 KB)
Power	Watts (mains)	Milliwatts (battery)
Algorithm	Dijkstra’s SPF	Distance-vector
Database	Link-state DB (entire network)	Parent pointer / routing table

Why OSPF Doesn’t Work for IoT:

1. Memory Requirements:

OSPF:

• Link-State Database (LSDB): Stores topology of entire network
• Every router knows everything: All links, all routers
• Example: 100-node network
  • Average 3 links per node = 300 links
  • Link-state data: ~50 bytes per link
  • LSDB size: 300 × 50 = 15,000 bytes = 15 KB (topology only)
  • Add routing table, neighbor table, etc.: 50-100 KB total

IoT Device (e.g., nRF52840): - Total RAM: 256 KB - OSPF would use: 50-100 KB (~20-40% of RAM) - Application left with: 156-206 KB (including OS, app, buffers)

RPL:

• Storing mode: Routing table for sub-DODAG only (KBs)
• Non-Storing mode: Just parent pointer (2 bytes)
• Typical: 1-5 KB for routing state

2. Processing Requirements:

OSPF Algorithm:

1. Receive Link-State Advertisements (LSAs)
2. Update Link-State Database
3. Run Dijkstra's Shortest Path First (SPF) algorithm
   - For 100-node network: O(N^2) = 10,000 operations
   - Recalculate entire routing table
4. Update forwarding table

CPU Time (traditional router): - 100-node network: ~10-50ms (GHz processor) - Acceptable for mains-powered router

CPU Time (IoT device, 32 MHz): - 100-node network: ~500ms - 2 seconds - Energy: 20 mA × 1s = 20 mAs (significant battery drain) - Worse: Runs every topology change!

RPL Algorithm:

1. Receive DIO from parent
2. Update RANK = parent_RANK + increase
3. (Storing mode) Update routing table for children
4. Done

CPU Time: < 1ms (simple calculation)

3. Protocol Overhead:

OSPF:

• Hello packets: Every 10 seconds (keep neighbors alive)
• LSA flooding: Every topology change
• LSA refresh: Every 30 minutes (even if no change)
• Packets: Large (detailed link-state info)

Example overhead (10 neighbors): - Hello: 10 packets per 10s = 1 packet/s - Each hello: ~50-100 bytes - Bandwidth: ~800 bps continuous (just hellos) - Power: RX always on to receive hellos

RPL:

• DIO: Trickle timer (adaptive, minutes when stable)
• DAO: Only when topology changes
• Packets: Smaller (compressed headers with 6LoWPAN)

Example overhead (stable network): - DIO: 1 packet per 16 minutes (Trickle timer) - Bandwidth: ~10 bps average - Power: Can sleep between DIOs

4. Convergence Time:

OSPF Convergence:

Figure 42.11: OSPF convergence process with computationally expensive SPF algorithm

Problem for IoT: SPF computation drains battery

RPL Convergence:

Figure 42.12: RPL fast convergence via backup parents or DIS discovery with minimal battery impact

Option Analysis:

A) OSPF doesn’t support IPv6: Wrong. OSPFv3 fully supports IPv6 (RFC 5340, published 2008).

B) OSPF requires too much processing power and memory: Correct. OSPF’s link-state database and SPF algorithm exceed IoT capabilities.

C) OSPF can’t handle mesh topologies: Wrong. OSPF excels at mesh topologies - it was designed for arbitrary topologies.

D) OSPF is proprietary and requires licensing: Wrong. OSPF is an open standard (IETF RFC 2328, RFC 5340). Multiple open-source implementations exist.

Real-World Example:

IoT Device: nRF52840 (common for Thread, Zigbee) - CPU: 64 MHz ARM Cortex-M4 - RAM: 256 KB - Flash: 1 MB - Power: 5 mA RX, 5 µA sleep

Running OSPF:

• LSDB: 50 KB (20% of RAM)
• Hello packets: RX always on (5 mA continuous = 120 mAh per day)
• Battery (2000 mAh): Lasts 16.7 days (vs years with RPL)

Running RPL:

• Routing state: 2 KB (< 1% of RAM)
• Trickle DIOs: RX on briefly every 16 minutes
• Battery: Lasts years (duty cycle < 1%)

Conclusion: OSPF is unsuitable for IoT LLNs primarily because its link-state database and SPF algorithm require far more memory and processing power than battery-powered IoT devices can afford, while RPL is specifically designed for these constraints.

42.5 Visual Reference Gallery

Explore these visualizations that illustrate RPL concepts covered in this chapter.

Visual: DODAG Construction Process

Building A DODAG Step 1

The DODAG construction begins with the root broadcasting DIO messages, which neighboring nodes use to calculate their RANK and select parents.

Visual: DAG vs DODAG Structure

DAG and DODAG Comparison

Understanding the difference between a generic DAG and RPL’s DODAG is fundamental to grasping how RPL organizes routing hierarchies.

Visual: RPL Protocol Overview

RPL Protocol Overview

RPL coordinates routing through control messages and objective functions that optimize for IoT-specific metrics like energy consumption.

Visual: RPL Non-Storing Mode Operation

Non-Storing Mode Operation

Non-Storing mode centralizes routing state at the root, making it ideal for memory-constrained sensor networks with primarily upward traffic.

Common Mistake: Ignoring DAO Timer Expiration in Production

The Error: Deploying RPL networks with default DAO lifetime (2-4 hours) without accounting for sensor sleep schedules, causing downward routes to expire and fail.

Why It’s Problematic:

DAO messages advertise node reachability upward to the root. Each DAO has a lifetime - after expiration, the root (or intermediate routers in Storing mode) remove the routing entry. If a sensor sleeps longer than DAO lifetime, it becomes unreachable for downward traffic (commands, firmware updates).

Real-World Example - Smart Meter Deployment (2020):

A utility company deployed 5,000 smart electricity meters with RPL: - Configuration: Non-Storing mode, DAO lifetime = 2 hours (default) - Meter behavior: Report consumption every 15 minutes, deep sleep between transmissions - Problem: Meters woke at 15-minute intervals to send data (upward), but never sent DAO refresh within 2-hour window because they only woke to TX, not RX - Result: 87% of meters had expired DAO entries at root, so downward commands (disconnect service, adjust tariff) failed

Timeline of Failure:

t=0:        Meter sends DAO, root installs route (lifetime: 2 hours)
t=15 min:   Meter wakes, sends consumption data (upward), sleeps immediately
t=30 min:   Same (DAO not refreshed)
...
t=2 hours:  DAO lifetime expires, root removes route
t=2h 15min: Utility tries to send disconnect command → FAILS (no route)

The Fix:

Option 1: Extend DAO Lifetime to Match Sleep Schedule

Meter sleep cycle: 15 minutes
DAO refresh interval: 4× sleep cycle = 60 minutes
DAO lifetime: 2× refresh interval = 120 minutes (2 hours)

Better: Set DAO lifetime to 4 hours (safety margin)

Option 2: Send DAO on Every Wake-Up

Configure meters to send DAO with every upward data transmission:
t=0:        Send data + DAO
t=15 min:   Send data + DAO (refreshes route)
t=30 min:   Send data + DAO (refreshes route)
...
Route never expires (DAO refreshed every 15 minutes)

Trade-offs: | Approach | Pros | Cons | |———-|——|——| | Long DAO lifetime | Fewer DAO transmissions (saves energy) | Routes persist during sensor failures (stale entries) | | Frequent DAO refresh | Routes always current | Higher control overhead (3-5% energy increase) |

Implementation in Contiki-NG:

// Set DAO lifetime to 4 hours
#define RPL_CONF_DEFAULT_LIFETIME_UNIT 60  // 60 seconds
#define RPL_CONF_DEFAULT_LIFETIME 240      // 240 × 60 = 4 hours

// Force DAO on every transmission
rpl_set_default_route_refresh(15 * 60);  // 15 minutes

Post-Fix Results:

• Downward command success rate: 13% → 98%
• DAO transmissions increased: 1 per 4 hours → 1 per 15 minutes (16× increase)
• Battery impact: Negligible (DAO TX = 20ms × 20mA = 0.4 mAs, vs 15-min data TX = 30ms × 20mA = 0.6 mAs)
• Energy overhead: DAO refresh adds approximately 0.7% total energy (acceptable)

How to Avoid This Mistake:

Step 1: Map Sensor Wake Schedule

Wake interval: T_wake (e.g., 15 minutes)
Max sleep duration: T_sleep (e.g., 4 hours for deep sleep modes)

Step 2: Configure DAO Parameters

DAO refresh interval = min(T_wake, T_sleep / 2)
DAO lifetime = 2 × DAO refresh interval (minimum safety)

Step 3: Validate in Pilot

Monitor root routing table for 48 hours:
- Count routes that expire prematurely
- Measure downward packet delivery rate (target > 95%)
- If failures occur, halve DAO refresh interval

Best Practice: For battery-powered sensors with irregular sleep schedules, always use Option 2 (DAO on every wake-up). The energy cost is trivial (< 1%) compared to the operational cost of failed downward commands.

Match RPL Control Messages to Their Functions

Order the RPL Network Joining Sequence

Common Pitfalls

1. Memorizing Answers Without Understanding Reasoning

Quiz questions about RPL RANK calculation and mode selection require understanding the underlying mechanisms, not memorized answers. The next question will use different values — understand the calculation method, not just the result.

2. Not Connecting Quiz Questions to Real Deployment Scenarios

RPL quiz questions become meaningful when connected to real deployment decisions. For each question answered, identify which specific deployment scenario it applies to.

3. Skipping Questions on Trickle Timer

Trickle Timer questions appear in most RPL assessments. The algorithm is conceptually simple (double interval when consistent, reset when inconsistent) but detail questions about k and suppression trip up underprepared students.

🏷️ Label the Diagram

Code Challenge

42.6 Summary

This detailed quiz chapter covered the core concepts of RPL:

• RANK Mechanics: Loop prevention through hierarchical position enforcement, calculated by objective functions considering hop count, ETX, latency, or energy
• Mode Comparison: Storing vs Non-Storing modes have identical many-to-one performance; choice depends on P2P traffic and memory constraints
• Control Messages: DIS requests DODAG info, DIO advertises it, DAO builds downward routes, DAO-ACK confirms receipt
• Traditional vs RPL: OSPF’s link-state database and Dijkstra algorithm are fundamentally incompatible with IoT resource constraints

42.6.1 Quick Reference: RPL Control Messages

Message	Purpose	Direction	When Sent
DIS	Request DODAG info	Multicast	Joining, recovery
DIO	Advertise DODAG	Downward/broadcast	Trickle timer
DAO	Advertise reachability	Upward	After joining
DAO-ACK	Confirm DAO receipt	Downward	Optional

42.7 Concept Relationships

This quiz content reinforces understanding across multiple RPL topics:

• RPL Fundamentals introduces the DODAG and RANK concepts that Question 1 tests in depth
• RPL Lab: Network Design provides hands-on practice with the Storing vs Non-Storing mode trade-offs explored in Question 2
• RPL Operation details the control message flows (DIO, DIS, DAO) that Question 3 examines
• Routing Fundamentals contrasts distance-vector and link-state approaches, explaining why OSPF (Question 4) fails for IoT
• Trickle Timer governs DIO frequency, determining when nodes send the messages discussed in Question 3

42.8 See Also

Related Quiz Resources:

• RPL Knowledge Check - Scenario-based quizzes for applying these concepts
• Quizzes Hub - Additional RPL assessment questions across difficulty levels
• Knowledge Gaps Hub - Common misconceptions about RANK and routing modes

Reference Specifications:

• RFC 6550 Section 8.2 (RANK computation) - Foundation for Question 1
• RFC 6552 (OF0) and RFC 6719 (MRHOF) - Objective functions affecting RANK calculation
• RFC 2328 (OSPFv2) - Shows link-state protocol complexity compared in Question 4

42.9 What’s Next

Return to RPL Labs and Quiz Overview to explore other RPL learning resources, or continue to RPL Production and Review for real-world deployment patterns and optimizations.

Previous: RPL Lab Network Design

Next: RPL Production and Review