705  RPL Overview and Introduction

705.1 IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL)

NoteLearning Objectives

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

  • Understand why traditional routing protocols don’t work for Low-Power and Lossy Networks (LLNs)
  • Explain RPL as a distance-vector routing protocol for IoT
  • Understand DODAG (Destination Oriented Directed Acyclic Graph) topology
  • Explain the RANK concept and loop prevention mechanisms
  • Compare Storing mode vs Non-Storing mode in RPL
  • Understand upward, downward, and point-to-point routing in RPL
  • Design RPL networks for different IoT applications
  • Analyze RPL performance trade-offs
ImportantThe Challenge: Routing in Lossy, Low-Power Networks

The Problem: Traditional routing protocols fail in IoT environments:

  • OSPF/RIP: Assume stable links, but LLNs have 10-30% packet loss
  • Link-state protocols: Flood topology changes across the network, killing batteries
  • Distance-vector protocols: Converge too slowly (minutes, not seconds needed)
  • Memory requirements: Full routing tables don’t fit in 2KB RAM

Why It’s Hard:

  • Links appear and disappear due to interference and battery depletion
  • Nodes sleep most of the time to conserve energy
  • Asymmetric links are common (A hears B, but B doesn’t hear A)
  • Multi-path routing needed for reliability, but adds complexity

What We Need:

  • Handle lossy, unreliable links gracefully
  • Minimize control message overhead (every byte costs energy)
  • Support different traffic patterns: Many-to-Point (MP2P), Point-to-Multipoint (P2MP), and Point-to-Point (P2P)
  • Work seamlessly with IPv6 and 6LoWPAN

The Solution: RPL (Routing Protocol for Low-Power and Lossy Networks) builds a DODAG—a tree-like structure that naturally routes data upward to a central collection point while supporting downward and peer-to-peer traffic when needed.

705.2 Prerequisites

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

  • Routing Fundamentals: Understanding basic routing concepts, routing tables, and routing protocols provides essential context for RPL’s specialized approach to IoT routing
  • 6LoWPAN Fundamentals: RPL often operates with 6LoWPAN to enable IPv6 over constrained networks, so understanding header compression and adaptation layer concepts is helpful
  • Wireless Sensor Networks: Knowledge of WSN architectures, energy constraints, and multi-hop communication helps explain why RPL differs from traditional routing protocols
  • LPWAN Fundamentals: Understanding low-power wide-area network characteristics provides context for RPL’s design goals and trade-offs

Deep Dives: - RPL Specification - Standards and protocol design - RPL DODAG Construction - How networks form - RPL Routing Modes - Storing vs Non-Storing - RPL Summary and Tools - Pitfalls and interactive demos

Comparisons: - Routing Fundamentals - RPL vs OSPF vs RIP - IoT Protocols Review - Routing protocol comparison

Hands-On: - RPL Labs and Quiz - Practice DODAG design - Simulations Hub - RPL network simulators

Learning: - Quizzes Hub - Test RPL knowledge - RPL Production Review - Advanced scenarios

705.3 🌱 Getting Started (For Beginners)

TipWhat is RPL? (Simple Explanation)

Analogy: RPL is like a water drainage system—water (data) always flows downhill toward the drain (root), and the system automatically finds the best path even if some pipes get blocked.

Simple explanation: - RPL creates a “tree” structure where all data flows toward one point (the root/gateway) - Each device knows which neighbor is “closer” to the root - If a path fails, devices automatically find a new route - Designed specifically for battery-powered devices with weak radios

705.3.1 Why Can’t We Use Regular Routing?

NoteThe Problem with Traditional Routing

Graph diagram

Graph diagram
Figure 705.1: Traditional router vs IoT sensor resource comparison

705.3.2 The DODAG Concept (RPL’s Secret Sauce)

DODAG = Destination Oriented Directed Acyclic Graph

Don’t let the name scare you—it’s simpler than it sounds:

Comparison between DAG (Directed Acyclic Graph) with multiple independent trees and DODAG (Destination Oriented Directed Acyclic Graph) with single root where all nodes form unified tree structure converging to one destination, illustrating RPL's single-root constraint for IoT routing efficiency.

DAG vs DODAG Comparison
Figure 705.2: Source: CP IoT System Design Guide, Chapter 4 - Networking Protocols

Graph diagram

Graph diagram
Figure 705.3: DODAG tree with backup parent paths for fault tolerance

This variant shows how the DODAG builds over time as nodes discover the network:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart LR
    subgraph T1["T=0: Root starts"]
        R1["ROOT<br/>Rank: 0"]
    end

    subgraph T2["T=1: First hop joins"]
        R2["ROOT"] --> A2["A<br/>R:100"]
        R2 --> B2["B<br/>R:100"]
    end

    subgraph T3["T=2: Network expands"]
        R3["ROOT"] --> A3["A"]
        R3 --> B3["B"]
        A3 --> C3["C<br/>R:200"]
        B3 --> D3["D<br/>R:200"]
    end

    T1 -->|"DIO broadcast"| T2
    T2 -->|"DIO propagates"| T3

    style R1 fill:#2C3E50,stroke:#16A085,color:#fff
    style R2 fill:#2C3E50,stroke:#16A085,color:#fff
    style R3 fill:#2C3E50,stroke:#16A085,color:#fff
    style A2 fill:#16A085,stroke:#2C3E50,color:#fff
    style B2 fill:#16A085,stroke:#2C3E50,color:#fff
    style A3 fill:#16A085,stroke:#2C3E50,color:#fff
    style B3 fill:#16A085,stroke:#2C3E50,color:#fff
    style C3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style D3 fill:#E67E22,stroke:#2C3E50,color:#fff

This timeline helps visualize that DODAG formation is a gradual process where DIO messages ripple outward from the root.

Key Difference: In a DODAG, nodes can maintain backup parents. If parent A fails, node M automatically switches to parent B!

705.3.3 RPL “Rank” Explained

NoteRank = Distance to Root

Analogy: Think of rank like floor numbers in a building. The root is on floor 0 (ground), and each hop away adds floors.

Graph diagram

Graph diagram
Figure 705.4: Building floor analogy for RANK hierarchy

{fig-alt=“Building floor analogy for RPL RANK showing Floor 0 as ROOT (Rank 0), Floor 1 nodes at Rank 100, Floor 2 at Rank 200, Floor 3 at Rank 300, with arrows showing data flowing upward from higher floors to lower floors toward root”}

NoteKey Insight: Rank = Distance to Root (Lower is Closer)

Flowchart diagram

Flowchart diagram
Figure 705.5: RANK values increasing with distance from root

In Plain English: Rank is like floor numbers in a building - the root is the ground floor (0), and each hop away adds to your rank. Data always flows “downhill” toward lower rank, preventing loops.

705.3.4 RPL Messages (The Three Amigos)

Message Name Purpose Analogy
DIO DODAG Information Object “Here’s the network, join me!” Town crier announcing the kingdom
DIS DODAG Information Solicitation “Hello? Anyone out there?” New person asking for directions
DAO Destination Advertisement Object “I’m here at this address!” Registering your address at city hall

How they work together:

Mermaid diagram

Mermaid diagram
Figure 705.6: DIO, DIS, and DAO message exchange sequence

{fig-alt=“RPL message flow sequence diagram showing ROOT sending periodic DIOs, neighbor node joining and forwarding DIOs, new node sending DIS to request info, receiving DIO response, and then sending DAO to register address which propagates to root and returns DAO-ACK”}

705.3.5 Real-World Example: Smart Building

Graph diagram

Graph diagram
Figure 705.7: Smart building multi-floor sensor network hierarchy

This variant shows the three traffic types RPL supports and how data flows:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TB
    subgraph MP2P["Many-to-Point (MP2P)<br/>Sensor Data Collection"]
        S1["Sensor 1"] -->|temp=22°C| GW1["Gateway"]
        S2["Sensor 2"] -->|temp=23°C| GW1
        S3["Sensor 3"] -->|motion| GW1
    end

    subgraph P2MP["Point-to-Multipoint (P2MP)<br/>Commands/Updates"]
        GW2["Gateway"] -->|config| D1["Device 1"]
        GW2 -->|update| D2["Device 2"]
        GW2 -->|alert| D3["Device 3"]
    end

    subgraph P2P["Point-to-Point (P2P)<br/>Device-to-Device"]
        DA["Switch"] -->|toggle| DB["Light"]
    end

    style GW1 fill:#2C3E50,stroke:#16A085,color:#fff
    style GW2 fill:#2C3E50,stroke:#16A085,color:#fff
    style S1 fill:#16A085,stroke:#2C3E50,color:#fff
    style S2 fill:#16A085,stroke:#2C3E50,color:#fff
    style S3 fill:#16A085,stroke:#2C3E50,color:#fff
    style D1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style D2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style D3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style DA fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style DB fill:#7F8C8D,stroke:#2C3E50,color:#fff

RPL’s DODAG naturally optimizes for MP2P (upward) traffic, but also supports P2MP (downward) and P2P (peer) communication patterns.

{fig-alt=“Smart building RPL network with 3 floors: ground floor has gateway (Rank 0), floor 1 has temp and motion sensors (Rank 100), floor 2 has temp, smoke, door sensors (Rank 200-250), floor 3 has temp and light sensors (Rank 300) with primary and backup parent connections”}

Smart Building with 100 sensors using RPL:

The diagram above shows a simplified multi-floor RPL mesh network where: - Gateway/Root at ground level (Rank 0) - Each floor has multiple sensors forming mesh connections - Sensors on higher floors have higher rank (farther from root) - Multi-hop paths allow coverage throughout building

How RPL helps: - All sensors form a tree toward the gateway - Smoke detector can reach gateway via multiple paths - If one sensor’s battery dies, data routes around it - Gateway knows exactly how to reach each sensor

705.3.6 Self-Check Questions

Before diving into the technical details, test your understanding:

  1. Basic Concept: What does “Rank” mean in RPL?
    • Answer: A number indicating how far (how many hops) a node is from the root. Lower rank = closer to root.
  2. Why Trees?: Why does RPL create a tree structure instead of a flat mesh?
    • Answer: Trees prevent routing loops and reduce memory needs—each node only needs to know its parent(s), not the entire network.
  3. Failure Recovery: What happens if a sensor’s parent node fails in RPL?
    • Answer: The sensor selects an alternate parent (backup) or uses DIS/DIO messages to find a new parent.

Explore RPL Across Learning Resources:

  • Knowledge Map: See how RPL fundamentals connect to 6LoWPAN, routing protocols, and IoT architectures in the interactive concept graph
  • Quizzes Hub: Test your understanding of DODAG construction, RANK calculation, and routing modes with targeted quiz questions
  • Simulations Hub: Experiment with RPL network simulators (Cooja, NS-3) to visualize DODAG formation and parent selection in real-time
  • Videos Hub: Watch video explanations of RPL protocol operation, message flows, and network self-healing mechanisms
  • Knowledge Gaps Hub: Address common RPL misconceptions like “RANK = hop count” and “Storing mode is always better”

Recommended Learning Path: 1. Start here to understand RPL fundamentals and DODAG construction 2. Use Simulations Hub to visualize how nodes join DODAGs and calculate RANK 3. Test knowledge in Quizzes Hub with DODAG construction scenarios 4. Watch Videos Hub for protocol message timing and trickle algorithm explanations 5. Check Knowledge Gaps Hub to avoid common RANK vs hop count confusion

705.4 Introduction to RPL

⏱️ ~12 min | ⭐⭐ Intermediate | 📋 P07.C22.U01

RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is a distance-vector routing protocol specifically designed for resource-constrained IoT devices operating in challenging network conditions.

IoT routers, like other devices in an IoT environment, are resource constrained. As they operate in Low Power and Lossy Networks (LLN), there are limitations that make it almost impossible to use traditional routing protocols.

Graph diagram

Graph diagram
Figure 705.8: LLN characteristics and IoT constraints driving RPL design

{fig-alt=“Diagram showing Low-Power and Lossy Network characteristics including 10-40% packet loss, variable link quality, asymmetric links, and battery-powered devices alongside IoT device constraints of 8-32 MHz CPU, 10-128 KB RAM, 32-512 KB flash, and milliwatt power consumption, both converging to RPL protocol as the specialized solution designed for these challenging conditions”}

WarningCommon Misconception: “RANK = Hop Count”

The Myth: Many beginners assume RPL RANK is simply the number of hops from the root, like traditional hop-count routing.

The Reality: RANK is a calculated metric based on link quality, not just hop count. A 3-hop path with good links can have lower RANK than a 2-hop path with poor links.

Real-World Impact - Agricultural IoT Network:

In a 2019 deployment of 150 soil moisture sensors across 12 hectares of farmland: - Initial assumption: Shortest hop path (2 hops) chosen by default - Problem: 2-hop path used unreliable 802.15.4 link at field edge (40% packet loss) - Result: 60% of sensor data lost, 3× battery drain from retransmissions - RPL solution: Objective function (OF0 with ETX metric) calculated RANK based on Expected Transmission Count - 2-hop poor link: RANK = 0 + 256 + 1024 = 1280 (ETX 4.0 for lossy link) - 3-hop good links: RANK = 0 + 256 + 256 + 256 = 768 (ETX 1.0 each hop) - Outcome: Network automatically chose 3-hop path despite more hops, reducing packet loss to 5% and extending battery life by 2.1× (18 months → 38 months)

Key Takeaway: RANK incorporates link quality (RSSI, ETX), energy cost, latency, or custom metrics via objective functions. In lossy environments, lower RANK ≠ fewer hops—it means better overall path quality. The 150-sensor farm saved $18,000 in replacement batteries over 3 years by using RANK correctly.

How to verify: Check your RPL implementation’s objective function—OF0 (RFC 6552) and MRHOF (RFC 6719) both use ETX, not hop count alone.

ImportantKnowledge Check

Test your understanding of fundamental concepts with these questions.

Scenario: You’re deploying a smart building with 50 temperature sensors organized in a 4-level RPL network. Sensor E (on the 4th floor) just joined the DODAG by selecting Node D as its parent. The building manager needs to send firmware updates directly to specific sensors.

Think about: - When does Sensor E advertise its presence so the root can reach it? - What information does Node D need to forward messages down to Sensor E? - How does the root learn the complete path to reach Sensor E?

Key Insight: In Storing mode RPL, nodes send DAO (Destination Advertisement Object) messages to build downward routing paths. When Sensor E joins, it sends a DAO to parent D saying “I am reachable via you.” Node D stores this routing entry, then propagates a DAO upward to its parent C saying “E and D are reachable via me.” This continues until the root has complete routing information.

Real-world impact: In your 50-sensor building, without proper DAO messaging, the root cannot send firmware updates to specific sensors—all downward communication would fail. DAO messages are triggered when: joining the network, changing parents, receiving DAOs from children, or during periodic refresh intervals.

Verify Your Understanding: If Sensor E stops sending DAOs after network disruption, what happens when the root tries to update its firmware? (Answer: The root’s routing table expires, and downward packets to E are dropped until E sends fresh DAO messages)

705.5 What’s Next

Now that you understand RPL fundamentals and the DODAG concept, continue to: