22  RPL Introduction and Core Concepts

In 60 Seconds

Traditional routing protocols (OSPF, RIP) fail in IoT because they assume stable links and have excessive memory/power requirements. RPL is an IPv6 distance-vector protocol designed for Low-Power and Lossy Networks, using a DODAG topology where RANK values encode path quality and prevent routing loops without the overhead of full topology databases.

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

Learning Objectives

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

• Analyze why traditional routing protocols (OSPF, RIP) fail for Low-Power and Lossy Networks
• Classify RPL as a distance-vector routing protocol and contrast it with link-state alternatives
• Describe the DODAG (Destination Oriented Directed Acyclic Graph) topology and its single-root constraint
• Demonstrate how the RANK mechanism prevents routing loops in constrained networks

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.

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

Key Concepts

• RFC 6550: The IETF RFC defining the RPL routing protocol for low-power and lossy networks; the normative specification for RPL behavior and message formats.
• IETF ROLL Working Group: The IETF working group (Routing Over Low-power and Lossy networks) that developed RPL and related standards.
• LLN Characteristics: Properties of Low-Power and Lossy Networks: limited CPU/RAM, lossy links, low bandwidth, duty cycling, battery operation — the constraints RPL was designed to address.
• Objective Function (OF): An RPL algorithm selecting the DODAG root and computing RANK; two standardized OFs: OF0 (hop count) and MRHOF (minimizing ETX).
• DODAG ID: The IPv6 address of the DODAG root that uniquely identifies a DODAG instance; all RPL messages include the DODAG ID for identification.

22.3 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

22.4 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

Sensor Squad: The Water Drainage System!

“Why do we need a special routing protocol for IoT?” asked Sammy the Sensor. “Can’t we just use the same ones that regular computers use?”

“Great question!” said Max the Microcontroller. “Think of it like plumbing. Big office buildings have powerful water pumps and thick pipes – that is like OSPF on enterprise routers. But we are more like a garden irrigation system with tiny tubes and gravity-fed drip lines. We need something designed for our size.”

“RPL is like a water drainage system,” explained Lila the LED. “All the water – or in our case, sensor data – naturally flows downhill toward the drain at the bottom. That drain is called the ROOT, and every sensor knows which direction is downhill. The number showing how far downhill you are is your RANK.”

“What I love most is the backup plan,” added Bella the Battery. “If one pipe gets blocked, water finds another path downhill automatically. RPL does the same thing – if my preferred parent node fails, I switch to a backup parent without anyone having to fix anything manually!”

22.4.1 Why Can’t We Use Regular Routing?

22.4.2 The Problem with Traditional Routing

Traditional router vs IoT sensor comparison

Figure 22.1: Traditional router vs IoT sensor resource comparison

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

DAG vs DODAG Comparison

Figure 22.2: Source: CP IoT System Design Guide, Chapter 4 - Networking Protocols

Alternative View: DODAG Formation Timeline

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

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!

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

Building floor analogy for RPL RANK

Figure 22.3: Building floor analogy for RANK hierarchy

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.

22.4.5 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

Figure 22.4: DIO, DIS, and DAO message exchange sequence

22.4.6 Real-World Example: Smart Building

Smart building multi-floor RPL sensor network

Figure 22.5: Smart building multi-floor sensor network hierarchy

Alternative View: Traffic Patterns in RPL

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

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

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

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

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

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

Graph diagram

Figure 22.6: LLN characteristics and IoT constraints driving RPL design

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×1.0) + (256×4.0) = 1280 (1st hop ETX 1.0, 2nd hop ETX 4.0 for 75% packet loss link) - 3-hop good links: RANK = 0 + (256×1.0) + (256×1.0) + (256×1.0) = 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)

22.6 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

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

22.7.1 Processing, Memory, and Power Constraints

Graph diagram

Figure 22.7: Traditional router vs IoT sensor constraint 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)

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

22.7.3 Multiple Routing Instances

IoT Scenario: Single physical network, multiple applications

Graph diagram

Figure 22.8: Multiple RPL instances with different optimization goals

Example:

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

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

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

Knowledge Check: Why RPL for IoT?

22.8 RPL Core Concepts

22.8.1 Directed Acyclic Graph (DAG)

DAG = Directed Acyclic Graph

Graph diagram

Figure 22.9: DAG structure with directed edges and no cycles

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)

22.8.2 DODAG (Destination Oriented DAG)

RPL uses DODAG: DAG with single root (destination)

Graph diagram

Figure 22.10: DODAG with single root and RANK-based hierarchy

RPL DODAG Structure

Figure 22.11: The DODAG (Destination-Oriented Directed Acyclic Graph) forms the core routing structure in RPL networks. Nodes select preferred parents based on rank values calculated using an objective function, creating loop-free paths that efficiently route all traffic toward the root (typically a border router connecting to the internet).

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)

22.8.3 RANK: Loop Prevention Mechanism

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

Graph diagram

Figure 22.12: RANK-based loop prevention with forbidden backward paths

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

Putting Numbers to It

RANK calculation depends on the objective function. With MRHOF using ETX (Expected Transmission Count):

\[\text{RANK}_{\text{child}} = \text{RANK}_{\text{parent}} + \text{ETX} \times 256\]

For example: Parent has RANK 300, link ETX = 1.5 (lossy link requiring 1.5 transmissions on average):

\[\text{RANK}_{\text{child}} = 300 + (1.5 \times 256) = 300 + 384 = 684\]

Compare to a good link with ETX = 1.1:

\[\text{RANK}_{\text{child}} = 300 + (1.1 \times 256) = 300 + 282 = 582\]

This means RPL prefers the reliable 1.1 ETX link even if it’s farther in hop count, because lower RANK always wins during parent selection.

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)

22.8.4 Interactive: RANK Calculator

Explore how parent RANK and link ETX combine to determine a child node’s RANK:

viewof parentRank = Inputs.range([0, 1024], {value: 256, step: 256, label: "Parent RANK"})

viewof linkEtx = Inputs.range([1.0, 4.0], {value: 1.5, step: 0.1, label: "Link ETX (Expected Transmission Count)"})

viewof minHopRankIncrease = Inputs.range([128, 512], {value: 256, step: 128, label: "Min Hop Rank"})

childRank = parentRank + Math.round(minHopRankIncrease * linkEtx)

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #3498DB;">
<p><strong>RANK Calculation:</strong> ${parentRank} + (${minHopRankIncrease} &times; ${linkEtx.toFixed(1)}) = <strong style="color: #16A085; font-size: 1.1em;">${childRank}</strong></p>
<p style="color: #7F8C8D; font-size: 0.9em;">
  ${linkEtx <= 1.2 ? "Excellent link (ETX &le; 1.2): minimal retransmissions, prefer this parent." :
    linkEtx <= 1.8 ? "Good link (ETX 1.2&ndash;1.8): acceptable for most deployments." :
    linkEtx <= 2.5 ? "Marginal link (ETX 1.8&ndash;2.5): consider alternate parent if available." :
    "Poor link (ETX &gt; 2.5): high retransmission overhead, avoid if alternate exists."}
</p>
</div>`

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

Interactive: RPL Objective Function Selection Animation

22.9 Worked Example: Why OSPF Fails for a Smart Street Lighting Network

Scenario: A city is deploying 500 smart LED street lights with 802.15.4 mesh radios (MCU: 32 KB RAM, 128 KB flash). Each light reports energy consumption and ambient light levels to a central controller every 5 minutes. A network engineer proposes using OSPF, which they know from enterprise networking. Demonstrate quantitatively why OSPF is unsuitable and why RPL is the correct choice.

Step 1: OSPF Memory Requirements

OSPF is a link-state protocol. Every node must store the complete network topology:

OSPF per-node memory:
  Link-State Database (LSDB): 500 nodes x 4 neighbors avg x 32 bytes/LSA = 64,000 bytes
  Routing table: 500 entries x 20 bytes = 10,000 bytes
  SPF computation workspace: ~8,000 bytes
  OSPF protocol state: ~4,000 bytes
  Total: ~86,000 bytes = 84 KB

Available RAM: 32 KB

Result: OSPF requires 2.6x more RAM than the device has.
          Cannot run OSPF on these devices.

RPL per-node memory (Non-Storing mode):

  Parent entry: 20 bytes (preferred parent IPv6 + RANK)
  Backup parent: 20 bytes
  Instance/DODAG ID: 20 bytes
  Trickle timer state: 8 bytes
  Total: ~68 bytes

Uses 0.2% of available RAM. Fits easily with room for application code.

Step 2: Control Traffic Overhead

Protocol	Mechanism	Messages/Day per Node	Bytes/Day per Node
OSPF	Hello packets every 10s	8,640	345,600
OSPF	LSA refresh every 30 min	48	9,600
OSPF	LSA flood on any topology change	Variable (~50/day)	25,000
OSPF total		~8,738	~380,200
RPL (stable)	DIO (Trickle-suppressed)	~4	160
RPL (stable)	DAO	~2	60
RPL total		~6	~220

RPL uses 1,728x less control traffic than OSPF in steady state. For battery-powered variants of this deployment, OSPF’s hello packets alone would drain a CR2032 coin cell in 3 days.

Step 3: Convergence After a Node Failure

When light 247 fails (power outage on its street segment), both protocols must reroute traffic from downstream lights:

Phase	OSPF	RPL
Detection	Hello timeout: 40 seconds (4 x 10s hello)	Trickle reset: 1-17 minutes
Notification	LSA flooded to ALL 500 nodes	Only affected children recalculate
Computation	Each node runs Dijkstra’s SPF	Children select new parent from DIO
SPF CPU cost	O(N log N) = O(500 x 9) per node	O(k) where k = number of candidate parents (~3)
Network-wide impact	500 nodes x 200 bytes LSA = 100 KB flood	~5 affected nodes x 40 bytes DIO = 200 bytes
Convergence complete	5-10 seconds	30-90 seconds

OSPF converges faster (5s vs 60s), but at 500x the network cost. For street lights reporting every 5 minutes, losing 60 seconds of data from 5 downstream lights is inconsequential. The 500x reduction in convergence traffic is the decisive factor.

Key Insight: OSPF’s design assumes three things that IoT violates: (1) nodes have enough RAM for full topology databases, (2) the cost of periodic hello messages is negligible, and (3) fast convergence justifies flooding the entire network. RPL inverts all three assumptions – it uses minimal per-node state, suppresses control messages when the network is stable, and accepts slower convergence as a deliberate trade-off for energy efficiency. This is not a limitation of RPL; it is a design choice optimized for networks where energy is the scarcest resource.

Match: RPL Core Concepts

Order: Why Traditional Routing Fails for IoT

Common Pitfalls

1. Skipping RFC 6550 and Only Reading Summaries

RPL has many subtle behaviors (DODAG inconsistency detection, DAO loop handling, floating DODAG behavior) that summaries miss. At least skim RFC 6550 sections 3–8 to understand normative behavior before implementing.

2. Assuming One Objective Function Fits All Deployments

OF0 (hop count) minimizes hops but may choose unreliable links; MRHOF (ETX-based) chooses reliable paths but may use more hops. Match the Objective Function to your application’s priority: latency vs reliability.

3. Not Checking IoT Platform’s RPL Compliance Level

Embedded RPL implementations (Contiki, RIOT, OpenThread’s RPL) may implement different subsets of RFC 6550. Verify your platform’s compliance level against the RPL features you depend on before committing to a design.

🏷️ Label the Diagram

Code Challenge

22.10 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

22.11 Concept Relationships

This introduction establishes RPL’s foundations and connects to the complete learning path:

Prerequisites:

• Routing Fundamentals - Distance-vector vs link-state concepts
• 6LoWPAN Fundamentals - IPv6 adaptation layer
• Wireless Sensor Networks - Energy and memory constraints

Core Concepts Introduced:

• DODAG (Destination Oriented Directed Acyclic Graph) - Tree topology
• RANK - Hierarchical position metric
• DIO, DIS, DAO - Control message types
• Storing vs Non-Storing modes - Memory trade-offs

Leads To:

• RPL DODAG Construction - How networks form
• RPL Worked Example - Concrete calculations
• RPL Trickle and Modes - Energy efficiency

Contrasts With:

• OSPF - Link-state protocol requiring full topology knowledge
• RIP - Fixed-rate updates waste energy in IoT
• AODV - On-demand routing adds discovery latency

Related Protocols:

• Thread Routing - Uses RPL variant in Thread/Matter
• Zigbee Routing - Alternative hierarchical approach

22.12 See Also

Official Specifications:

• RFC 6550: “RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks” - Complete standard
• RFC 6552: “Objective Function Zero (OF0)” - Simple hop-count/ETX objective function
• RFC 6719: “MRHOF” - Minimum Rank with Hysteresis Objective Function
• RFC 6206: “Trickle Algorithm” - Adaptive timer for control messages

Books:

• Vasseur & Dunkels “Interconnecting Smart Objects with IP” (2010) - Chapters 5-6 cover RPL design rationale
• Shelby, Hartke & Bormann “The Constrained Application Protocol (CoAP)” (2014) - RPL + CoAP integration
• Dunkels “The Contiki Operating System” - RPL implementation details

Related Chapters:

• RPL Fundamentals and Construction - Complete series overview
• IoT Protocols Review - RPL compared to other routing protocols
• Routing Fundamentals - General routing concepts

Implementation Resources:

• Contiki-NG RPL Stack - Reference implementation with detailed documentation
• RIOT OS RPL Module - Alternative implementation
• Zephyr Project RPL - Embedded Linux RPL stack

Academic Papers:

• Winter et al. “RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks” - RFC 6550 authors’ paper
• Korte et al. “A Survey on Routing Metrics Used in LoWPAN” - Objective function comparison
• Tripathi et al. “Performance Evaluation of RPL” - Empirical analysis

Tools and Simulators:

• Simulations Hub - Cooja, NS-3, OMNeT++ RPL simulators
• Wireshark RPL Dissector - Packet capture and analysis
• RPL Visual Tool - DODAG visualization

Real-World Deployments:

• Itron OpenWay Riva - 35+ million smart meters
• Philips Hue - Thread-based smart lighting (RPL variant)
• Industrial IoT - Emerson SmartMesh IP, ABB industrial sensors

22.13 What’s Next

Next	Chapter
Construction	RPL DODAG Construction
Worked example	RPL Worked Example
Trickle and modes	RPL Trickle and Modes
Series overview	RPL Fundamentals and Construction