700 RPL Introduction and Core Concepts

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

Learning 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

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

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

Related Chapters

Deep Dives: - RPL DODAG Construction - Construction algorithm and visual guides - RPL Worked Example - Smart lighting network step-by-step - RPL Trickle and Routing Modes - Trickle timer and Storing vs Non-Storing - 6LoWPAN Architecture - IPv6 over IEEE 802.15.4

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

700.3 Getting Started (For Beginners)

What 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

700.3.1 Why Can’t We Use Regular Routing?

The Problem with Traditional Routing

700.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:

Alternative View: Interactive DODAG Diagram

Alternative View: DODAG Formation Timeline

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!

700.3.3 RPL “Rank” Explained

Rank = 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.

{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”}

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

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.

700.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:

{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”}

700.3.5 Real-World Example: Smart Building

Alternative View: Traffic Patterns in RPL

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

700.3.6 Self-Check Questions

Before diving into the technical details, test your understanding:

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

Cross-Hub Connections

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

700.4 Introduction to RPL

Time: ~12 min | Level: Intermediate | Unit: 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.

{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”}

Common 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, 3x 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.1x (18 months to 38 months)

Key Takeaway: RANK incorporates link quality (RSSI, ETX), energy cost, latency, or custom metrics via objective functions. In lossy environments, lower RANK does not equal 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.

Knowledge Check

Test your understanding of fundamental concepts with these questions.

Understanding Check: DAO Message Timing in Storing Mode

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)

700.5 RPL Specification

Standard: RFC 6550 (IETF, March 2012)
Type: Distance-vector routing protocol
Network Layer: IPv6 (works with 6LoWPAN)
Topology: DODAG (Destination Oriented Directed Acyclic Graph)
Metrics: Flexible (hops, ETX, latency, energy, etc.)
Use Case: Low-power, lossy networks with many-to-one traffic patterns

700.6 Why Not Use Existing Routing Protocols?

Traditional routing protocols like OSPF, RIP, and AODV were designed for different network characteristics. They don’t work well for IoT because:

700.6.1 Processing, Memory, and Power Constraints

{fig-alt=“Comparison showing traditional router requirements (GHz CPU, GB RAM, watts power, complex tables) versus IoT sensor constraints (32 MHz CPU, 32 KB RAM, milliwatts battery, parent pointer only) highlighting incompatibility”}

Traditional Protocols Require: - Complex routing tables: OSPF maintains link-state database of entire network - Frequent updates: RIP sends entire routing table every 30 seconds - Heavy processing: Link-state algorithms (Dijkstra’s shortest path) - Power-hungry: Constant listening and periodic broadcasts

IoT Constraints: - Microcontroller: 8-32 MHz, single core - RAM: 10-128 KB (vs GB in traditional routers) - Flash: 32-512 KB (limited code and data storage) - Power: Milliwatts (battery-powered, years of operation)

700.6.2 Single Metric Not Always Appropriate

Traditional protocols use single metric: - RIP: Hop count only - OSPF: Cost (usually based on bandwidth)

IoT requires multiple, context-dependent metrics: - Latency: Real-time monitoring (industrial sensors) - Reliability: Critical data (medical devices) - Energy: Battery-powered devices (maximize lifetime) - Bandwidth: Mixed traffic (sensors + actuators)

RPL Solution: Supports objective functions with multiple metrics

700.6.3 Multiple Routing Instances

IoT Scenario: Single physical network, multiple applications

{fig-alt=“Multiple RPL instances on same physical network: Instance 1 optimizes for latency (temperature monitoring) with fast parent selection, Instance 2 optimizes for energy (firmware updates) with low-power parent selection”}

Example: - Instance 1: Temperature monitoring (minimize latency) - Instance 2: Firmware updates (minimize energy, can be slower) - Same devices, different routing decisions based on application

700.6.4 Point-to-Multipoint Traffic Patterns

Traditional networks: Assume peer-to-peer traffic

IoT networks: Predominantly many-to-one traffic - Many sensors to one gateway (cloud) - Data aggregation at root

RPL Optimization: Optimized for convergent traffic towards root

700.6.5 Lossy Links

Traditional networks: Assume reliable links (wired, enterprise Wi-Fi)

Low-Power and Lossy Networks (LLN): - High packet loss: 10-40% (vs < 1% wired) - Variable link quality: Interference, fading, obstacles - Asymmetric links: A can hear B, but B can’t hear A - Time-varying: Link quality changes over time

RPL Features for Lossy Networks: - Trickle timer: Adaptive control message frequency - ETX metric: Expected Transmission Count (accounts for retransmissions) - Loop avoidance: RANK prevents routing loops

Understanding Check: DODAG Loop Prevention

Scenario: You’re debugging an agricultural IoT network with 100 soil moisture sensors across 5 km squared. During a storm, several sensors lose connectivity and attempt to rejoin the network. Without proper loop prevention, sensors could form routing cycles where packets endlessly circulate.

Think about: - What happens if Sensor C (RANK 370) tries to select Sensor E (RANK 500) as its parent? - How does RPL prevent packets from bouncing between nodes indefinitely? - Why can’t traditional protocols like RIP handle this as efficiently?

Key Insight: RPL’s DODAG (Directed Acyclic Graph) structure enforces that RANK strictly increases as you move away from the root. A node at RANK 370 cannot select a parent with RANK 500 (higher rank). By definition, if you always forward to lower RANK, you eventually reach RANK 0 (root)—cycles are mathematically impossible.

Real-world metrics: In your 100-sensor network, each sensor stores only its parent pointer (~4 bytes) instead of full routing tables (~10 KB for 100 nodes). When Node C’s parent fails, it checks neighbors’ DIOs: “Node A RANK 250 (lower), Node E RANK 500 (higher).” Simple comparison, no complex loop detection needed.

Verify Your Understanding: Traditional distance-vector protocols like RIP suffer “count-to-infinity” during failures (routing metric keeps incrementing: 1, 2, 3…infinity). How does RPL’s RANK mechanism bound this problem? (Answer: Maximum RANK is limited by objective function; nodes at max RANK cannot increase further, forcing them to find alternate parents or go offline instead of counting to infinity)

Understanding Check: Distance-Vector vs Link-State for IoT

Scenario: You’re comparing two routing approaches for a factory with 50 vibration sensors monitoring machinery. Option A (link-state like OSPF) requires each sensor to maintain a map of all 50 sensors and 80 connections. Option B (distance-vector like RPL) only requires storing: “My parent is Node 7, cost is 150.”

Think about: - How much memory does each sensor need for Option A vs Option B? - When a new sensor joins, which approach requires less communication overhead? - What’s the trade-off between local knowledge and network-wide visibility?

Key Insight: RPL is distance-vector: each node knows “next hop” (parent) and “distance” (RANK/cost) to root, but NOT the complete network topology. This minimal state fits in constrained devices (8 KB RAM typical for IoT sensors).

Real-world comparison: - Distance-vector (RPL): Node E stores: “Parent=D, RANK=768, Cost=120” (12 bytes) - Link-state (OSPF): Node E stores: Complete topology graph for 50 nodes x 80 links x 16 bytes/entry = 64 KB (exceeds sensor RAM!)

Why “distance-vector” name: “Distance” = RANK value (metric space distance to root). “Vector” = direction (points to parent/next-hop). Node doesn’t compute paths using Dijkstra—it trusts parent’s advertised distance.

Verify Your Understanding: If a link quality changes in the middle of the network, how does each approach detect it? (Answer: Distance-vector learns slowly via neighbor advertisements propagating; Link-state floods update immediately to all nodes. RPL accepts slower convergence for lower overhead—acceptable for IoT where topology changes are infrequent)

700.7 RPL Core Concepts

700.7.1 Directed Acyclic Graph (DAG)

DAG = Directed Acyclic Graph

{fig-alt=“Directed Acyclic Graph (DAG) example showing nodes A through E connected with directed arrows flowing downward, demonstrating no cycles - cannot return to same node following edges”}

Key Properties: - Directed: Edges have direction (arrows) - Acyclic: No cycles (cannot return to same node following edges) - Graph: Nodes connected by edges

Why DAG? - Loop-free routing: By definition, no cycles = no routing loops - Hierarchical structure: Natural parent-child relationships - Efficient aggregation: Data flows towards root(s)

700.7.2 DODAG (Destination Oriented DAG)

RPL uses DODAG: DAG with single root (destination)

{fig-alt=“Destination Oriented Directed Acyclic Graph (DODAG) with single ROOT node at top (Rank 0), intermediate nodes at Rank 256 and 512, leaf nodes at Rank 768, all paths flowing toward root”}

Artistic visualization of RPL DODAG showing root node as border router gateway, multiple routing paths with rank values increasing from root, parent selection based on objective function, and upward data flow toward root destination — RPL DODAG Structure

DODAG Properties: - Single root: One destination (typically border router/gateway) - Upward routes: All paths lead to root - RANK: Position in DODAG hierarchy (root = 0, increases going down)

700.7.3 RANK: Loop Prevention Mechanism

RANK is a scalar representing a node’s position relative to the root.

{fig-alt=“RANK loop prevention mechanism showing ROOT at Rank 0, Node A at 100, B at 250, C at 370, with valid forward links and forbidden backward link from C to A that would create a loop”}

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

RANK Calculation:

RANK(node) = RANK(parent) + RankIncrease

RankIncrease calculated based on:
- Link cost (ETX, RSSI, etc.)
- Number of hops
- Energy consumed
- Objective function

Example:

ROOT: RANK = 0
Node A (parent: ROOT): RANK = 0 + 100 = 100
Node B (parent: Node A): RANK = 100 + 150 = 250
Node C (parent: Node B): RANK = 250 + 120 = 370

Loop Prevention: - Node C cannot choose Node A as parent (RANK 100 < 370 is OK) - Node A cannot choose Node C as parent (RANK 370 > 100 - would create loop)

RANK vs Hop Count

RANK is not the same as Hop Count (although hop count can be a factor)

RANK is calculated using objective function which may consider: - Hop count - Expected Transmission Count (ETX) - Latency - Energy consumption - Link quality (RSSI, LQI)

Example: - Good link, 1 hop: RANK increase = 100 - Poor link, 1 hop: RANK increase = 300 - Good link, 2 hops: RANK increase = 200

Node may prefer 2 hops via good links (total RANK increase: 200) over 1 hop via poor link (RANK increase: 300).

700.8 Summary

This chapter introduced RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) and its core concepts:

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

700.9 What’s Next

Continue to RPL DODAG Construction to learn the step-by-step process of how RPL builds its DODAG topology, including visual guides and message flow sequences.