722 RPL Quiz Questions

722.1 Learning Objectives

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

Explain RANK mechanics: Understand how RANK prevents routing loops and enables hierarchical routing
Compare RPL modes: Analyze memory and performance trade-offs between Storing and Non-Storing
Describe control messages: Identify the purpose and flow of DIS, DIO, DAO, and DAO-ACK
Contrast with traditional routing: Explain why OSPF is unsuitable for IoT LLNs

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

722.3 Quiz: RPL Routing Protocol

Question 1: RANK Purpose

What is the primary purpose of RANK in RPL?

To measure the distance in meters from the root
To prevent routing loops by defining hierarchical position
To prioritize packets based on importance
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:

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

Loop Prevention Example:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TD
    Root["Root<br/>RANK 0"]
    A["Node A<br/>RANK 100"]
    B["Node B<br/>RANK 200"]
    C["Node C<br/>RANK 400"]

    Root -->|"RANK increase +100"| A
    A -->|"RANK increase +100"| B
    B -->|"RANK increase +200"| C
    C -.->|"FORBIDDEN<br/>RANK 400 to 100<br/>Moving away from root"| A

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

Figure 722.1: RANK hierarchy preventing routing loops through hierarchical constraints

RANK-based loop prevention: Node A (RANK 100) cannot choose Node C (RANK 400) as parent, preventing routing loops

Figure 722.2

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):

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#E67E22', 'primaryTextColor': '#fff', 'primaryBorderColor': '#E67E22', 'lineColor': '#E67E22', 'secondaryColor': '#E67E22'}}}%%
graph LR
    A["Node A<br/>Hop 2"]
    B["Node B<br/>Hop 3"]
    C["Node C<br/>Hop 4"]

    A -->|"Loop!"| B
    B -->|"Loop!"| C
    C -->|"Loop!"| A

    style A fill:#E67E22,stroke:#E67E22,color:#fff
    style B fill:#E67E22,stroke:#E67E22,color:#fff
    style C fill:#E67E22,stroke:#E67E22,color:#fff

Figure 722.3: Routing loop vulnerability without RANK hierarchy enforcement

Without RANK: Simple hop count allows routing loops (shown in orange/red to indicate problem)

Figure 722.4

Option Analysis:

A) Distance in meters: RANK is not physical distance. RANK is a logical hierarchy in DODAG. Two nodes same distance from 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 IPv6 Traffic Class field or different objective functions.

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

RANK Calculation Factors:

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

Example Objective Function (OF0 - Hop Count):

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
graph TD
    Root["Root<br/>RANK 0"]
    N1["Node 1<br/>RANK 256<br/>(0 + 256)"]
    N2["Node 2<br/>RANK 512<br/>(256 + 256)"]
    N3["Node 3<br/>RANK 768<br/>(512 + 256)"]

    Root -->|"+256"| N1
    N1 -->|"+256"| N2
    N2 -->|"+256"| N3

    style Root fill:#2C3E50,stroke:#16A085,color:#fff
    style N1 fill:#16A085,stroke:#16A085,color:#fff
    style N2 fill:#16A085,stroke:#16A085,color:#fff
    style N3 fill:#16A085,stroke:#16A085,color:#fff

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

OF0 (Hop Count) objective function: Fixed RANK increase of 256 per hop

Figure 722.6

Example Objective Function (ETX-based):

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
graph TD
    Root["Root<br/>RANK 0"]
    P1["Parent A<br/>RANK 100<br/>ETX 3.5"]
    P2["Parent B<br/>RANK 120<br/>ETX 1.2"]
    Node["Node<br/>RANK 240<br/>Chose Parent B"]

    Root --> P1
    Root --> P2
    P1 -.->|"ETX 3.5<br/>RANK would be 100+250=350<br/>REJECTED"| Node
    P2 -->|"ETX 1.2<br/>RANK = 120+120=240<br/>SELECTED"| Node

    style Root fill:#2C3E50,stroke:#16A085,color:#fff
    style P1 fill:#E67E22,stroke:#16A085,color:#fff
    style P2 fill:#16A085,stroke:#16A085,color:#fff
    style Node fill:#16A085,stroke:#16A085,color:#fff

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

ETX-based objective function: Node prefers 2 good hops (RANK 240) over 1 poor hop (RANK 350)

Figure 722.8

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?

Storing mode (better routing efficiency)
Non-Storing mode (lower memory requirements)
Both modes have identical performance for this scenario
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:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
graph BT
    S1["Sensor 1"] -->|"To parent"| R1["Router 1"]
    S2["Sensor 2"] -->|"To parent"| R1
    S3["Sensor 3"] -->|"To parent"| R2["Router 2"]
    S4["Sensor 4"] -->|"To parent"| R2
    R1 -->|"To parent"| Root["Root/Gateway"]
    R2 -->|"To parent"| Root

    style S1 fill:#E67E22,stroke:#16A085,color:#fff
    style S2 fill:#E67E22,stroke:#16A085,color:#fff
    style S3 fill:#E67E22,stroke:#16A085,color:#fff
    style S4 fill:#E67E22,stroke:#16A085,color:#fff
    style R1 fill:#16A085,stroke:#16A085,color:#fff
    style R2 fill:#16A085,stroke:#16A085,color:#fff
    style Root fill:#2C3E50,stroke:#16A085,color:#fff

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

Many-to-one upward routing: All nodes use parent pointer (default route), identical in both Storing and Non-Storing modes

Figure 722.10

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.

Question 3: RPL Control Messages

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

DIO (DODAG Information Object)
DIS (DODAG Information Solicitation)
DAO (Destination Advertisement Object)
DAO-ACK (DAO Acknowledgment)

Click to see answer

Answer: B) DIS (DODAG Information Solicitation)

Explanation:

RPL Control Messages (all ICMPv6):

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
graph TD
    DIO["DIO<br/>DODAG Information Object<br/>Advertises DODAG"]
    DIS["DIS<br/>DODAG Information Solicitation<br/>Requests DODAG info"]
    DAO["DAO<br/>Destination Advertisement<br/>Builds downward routes"]
    ACK["DAO-ACK<br/>Confirms DAO receipt"]

    DIO -->|"Sent by"| Root["Root & Routers"]
    DIS -->|"Sent by"| New["New Nodes"]
    DAO -->|"Sent by"| Nodes["All Nodes"]
    ACK -->|"Sent by"| Parents["Parent Nodes"]

    style DIO fill:#2C3E50,stroke:#16A085,color:#fff
    style DIS fill:#16A085,stroke:#16A085,color:#fff
    style DAO fill:#E67E22,stroke:#16A085,color:#fff
    style ACK fill:#7F8C8D,stroke:#16A085,color:#fff
    style Root fill:#2C3E50,stroke:#16A085,color:#fff
    style New fill:#16A085,stroke:#16A085,color:#fff
    style Nodes fill:#E67E22,stroke:#16A085,color:#fff
    style Parents fill:#7F8C8D,stroke:#16A085,color:#fff

Figure 722.11: 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:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
sequenceDiagram
    participant New as New Node
    participant R1 as Router 1
    participant R2 as Router 2
    participant Root as Root

    New->>R1: DIS (multicast)
    New->>R2: DIS (multicast)
    R1->>New: DIO (RANK 256)
    R2->>New: DIO (RANK 512)
    Note over New: Selects R1 as parent<br/>(lower RANK)
    New->>R1: DAO (I'm reachable via you)
    R1->>New: DAO-ACK

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

DIS/DIO message flow: New node requests DODAG information and receives responses from multiple neighbors

Figure 722.13

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:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
graph TD
    S1["1. Sensor powers on"]
    S2["2. Send DIS multicast"]
    S3["3. Receive DIO from neighbors"]
    S4["4. Calculate RANK for each"]
    S5["5. Select best parent"]
    S6["6. Send DAO upward"]
    S7["7. Joined DODAG!"]

    S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7

    style S1 fill:#E67E22,stroke:#16A085,color:#fff
    style S2 fill:#E67E22,stroke:#16A085,color:#fff
    style S3 fill:#16A085,stroke:#16A085,color:#fff
    style S4 fill:#16A085,stroke:#16A085,color:#fff
    style S5 fill:#16A085,stroke:#16A085,color:#fff
    style S6 fill:#16A085,stroke:#16A085,color:#fff
    style S7 fill:#2C3E50,stroke:#16A085,color:#fff

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

Complete RPL joining scenario: Sensor powers on, discovers neighbors via DIS/DIO exchange, and joins DODAG

Figure 722.15

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:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
sequenceDiagram
    participant Root
    participant R1 as Router 1
    participant R2 as Router 2
    participant S1 as Sensor 1

    Note over Root: 1. Root sends DIO (RANK 0)
    Root->>R1: DIO (RANK 0, DODAG ID)
    Root->>R2: DIO (RANK 0, DODAG ID)
    Note over R1,R2: 2. Routers calculate RANK
    Note over R1: RANK = 0 + 256 = 256
    Note over R2: RANK = 0 + 256 = 256
    Note over R1,R2: 3. Routers send DIO
    R1->>S1: DIO (RANK 256)
    R2->>S1: DIO (RANK 256)
    Note over S1: 4. Sensor selects parent
    S1->>R1: 5. DAO (I'm reachable)
    R1->>Root: 6. DAO (S1 reachable via R1)
    Root->>R1: 7. DAO-ACK
    R1->>S1: 7. DAO-ACK

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

RPL network formation sequence: Seven-step process from root DIO to complete DODAG construction

Figure 722.17

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:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TD
    UC1["Use Case 1:<br/>Initial Network Join"]
    UC2["Use Case 2:<br/>Parent Loss Recovery"]
    UC3["Use Case 3:<br/>Path Optimization"]

    UC1 --> A1["New node powers on"]
    A1 --> A2["Send DIS"]
    A2 --> A3["Receive DIOs"]
    A3 --> A4["Join DODAG"]

    UC2 --> B1["Parent link fails"]
    B1 --> B2["Send DIS"]
    B2 --> B3["Find new parent"]

    UC3 --> C1["Detect better path"]
    C1 --> C2["Send DIS"]
    C2 --> C3["Switch to better parent"]

    style UC1 fill:#2C3E50,stroke:#16A085,color:#fff
    style UC2 fill:#16A085,stroke:#16A085,color:#fff
    style UC3 fill:#E67E22,stroke:#16A085,color:#fff
    style A1 fill:#2C3E50,stroke:#16A085,color:#fff
    style A2 fill:#2C3E50,stroke:#16A085,color:#fff
    style A3 fill:#2C3E50,stroke:#16A085,color:#fff
    style A4 fill:#2C3E50,stroke:#16A085,color:#fff
    style B1 fill:#16A085,stroke:#16A085,color:#fff
    style B2 fill:#16A085,stroke:#16A085,color:#fff
    style B3 fill:#16A085,stroke:#16A085,color:#fff
    style C1 fill:#E67E22,stroke:#16A085,color:#fff
    style C2 fill:#E67E22,stroke:#16A085,color:#fff
    style C3 fill:#E67E22,stroke:#16A085,color:#fff

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

Three primary DIS use cases: Initial joining (Navy), recovery from parent loss (Teal), and path optimization (Orange)

Figure 722.19

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?

OSPF doesn’t support IPv6
OSPF requires too much processing power and memory
OSPF can’t handle mesh topologies
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 x 50 = 15 KB (minimum, just topology) - 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 (~40% of RAM!) - Application left with: 150 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 x 1s = 20 mA-s (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/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 / 16 minutes (Trickle timer) - Bandwidth: ~10 bps average - Power: Can sleep between DIOs

4. Convergence Time:

OSPF Convergence:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#E67E22', 'primaryTextColor': '#fff', 'primaryBorderColor': '#E67E22', 'lineColor': '#E67E22', 'secondaryColor': '#E67E22'}}}%%
graph TD
    LSA["1. Receive LSA<br/>(Link State Advertisement)"]
    DB["2. Update Link-State Database<br/>Stores entire network topology<br/>(50-100 KB RAM)"]
    SPF["3. Run Dijkstra's SPF Algorithm<br/>O(N squared) complexity<br/>(500ms-2s on IoT CPU)"]
    RT["4. Rebuild Routing Table<br/>High CPU usage"]
    BAT["Battery Drain:<br/>20 mA x 1s = 20 mA-s per convergence"]

    LSA --> DB --> SPF --> RT --> BAT

    style LSA fill:#E67E22,stroke:#E67E22,color:#fff
    style DB fill:#E67E22,stroke:#E67E22,color:#fff
    style SPF fill:#E67E22,stroke:#E67E22,color:#fff
    style RT fill:#E67E22,stroke:#E67E22,color:#fff
    style BAT fill:#E67E22,stroke:#E67E22,color:#fff

Figure 722.20: OSPF convergence process with computationally expensive SPF algorithm

OSPF convergence (Orange): Computationally expensive SPF algorithm drains IoT device batteries

Figure 722.21

Problem for IoT: SPF computation drains battery

RPL Convergence:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#16A085', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#16A085'}}}%%
graph TD
    FAIL["1. Parent Link Fails"]
    BP["2. Switch to Backup Parent<br/>Less than 1ms (already computed)"]
    ALT["OR: Send DIS"]
    DIO["3. Receive DIOs from neighbors"]
    SEL["4. Select new parent<br/>Simple RANK comparison<br/>(O(N) complexity, less than 1ms)"]
    DONE["Converged!<br/>Minimal battery impact"]

    FAIL --> BP
    FAIL --> ALT
    BP --> DONE
    ALT --> DIO --> SEL --> DONE

    style FAIL fill:#16A085,stroke:#16A085,color:#fff
    style BP fill:#16A085,stroke:#16A085,color:#fff
    style ALT fill:#16A085,stroke:#16A085,color:#fff
    style DIO fill:#16A085,stroke:#16A085,color:#fff
    style SEL fill:#16A085,stroke:#16A085,color:#fff
    style DONE fill:#2C3E50,stroke:#16A085,color:#fff

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

RPL convergence (Teal): Fast recovery via backup parents or DIS, minimal battery impact

Figure 722.23

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. Designed for arbitrary topologies.

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

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 uA sleep

Running OSPF: - LSDB: 50 KB (20% of RAM) - Hello packets: RX always on (5 mA continuous = 120 mA-h per day) - Battery (2000 mAh): Lasts 16 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.

722.4 Visual Reference Gallery

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

Visual: DODAG Construction Process

Modern visualization of RPL DODAG construction first step showing root node initiating DIO messages, neighbor nodes receiving and calculating RANK values using IEEE color palette with navy root, teal routers, and orange sensors

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

Modern comparison of generic Directed Acyclic Graph versus Destination-Oriented DAG, showing how DODAG ensures all paths lead to a single root destination using IEEE color palette

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

Modern overview of RPL protocol showing control messages (DIO, DAO, DIS), RANK mechanism, and objective function integration using IEEE color palette with clear protocol flow visualization

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

Modern visualization of RPL Non-Storing mode showing how source routing headers are used for downward traffic, with root maintaining complete routing information using IEEE color palette

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.

722.5 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

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

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