28  RPL Specification and Core Concepts

In 60 Seconds

RPL is defined in RFC 6550 as a distance-vector IPv6 routing protocol using DODAG topology with flexible metrics (hops, ETX, latency, energy). This chapter explains why existing protocols (OSPF, RIP, AODV) fail for IoT due to processing, memory, and power constraints, and details RPL’s specification as the purpose-built alternative for lossy, low-power networks.

28.1 Learning Objectives

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

• Describe the RPL specification (RFC 6550) including its distance-vector design and flexible metrics
• Explain why OSPF, RIP, and AODV fail for IoT due to processing, memory, and power constraints
• Identify the key components of DODAG topology including RANK values and objective functions
• Compare RPL’s resource requirements with traditional routing protocols for constrained devices

For Beginners: RPL Specification

The RPL specification is the official document that defines exactly how RPL works. This chapter breaks down the key parts of that specification into understandable pieces. Think of it as a guided tour of the rulebook – you do not need to memorize every detail, but understanding the structure helps you work with RPL effectively.

Sensor Squad: The Official Rulebook!

“What is RFC 6550?” asked Sammy the Sensor. “It sounds like a secret code!”

“It is the official rulebook for RPL,” explained Max the Microcontroller. “Just like sports have rulebooks so everyone plays the same game, RFC 6550 tells every IoT device exactly how to build routes, what messages to send, and how to pick the best path. Without it, devices from different manufacturers would not be able to talk to each other.”

“The specification covers everything,” added Lila the LED. “Which metrics to use for picking paths – like link reliability, energy cost, or latency. It is like choosing between the fastest route, the scenic route, or the cheapest route on a GPS. The objective function decides which one matters most.”

“And the best part is that it was designed for devices like us,” said Bella the Battery. “Traditional protocols like OSPF need gigabytes of memory and gigahertz processors. RPL works with just 32 kilobytes of RAM and a tiny processor. It is the difference between needing a supercomputer and needing a calculator!”

28.2 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

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

28.3.1 Processing, Memory, and Power Constraints

Comparison showing traditional router requirements versus IoT sensor constraints

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

28.3.2 Worked Example: OSPF vs RPL Resource Requirements

Scenario: A smart building has 200 environmental sensors on a 6LoWPAN mesh network. Each sensor has 32 KB RAM and runs on a CR2032 coin cell (220 mAh). Compare the memory and power requirements of OSPF vs RPL for this deployment.

OSPF memory requirements (link-state):

Each OSPF node maintains a Link-State Database (LSDB) of the entire network:

• 200 nodes x 16 bytes per LSA (node ID, sequence, age, link count) = 3,200 bytes
• ~400 links (average 4 neighbors per node, undirected) x 12 bytes per link (ID, metric, type) = 4,800 bytes
• SPF routing table: 200 destinations x 12 bytes (prefix, next hop, cost) = 2,400 bytes
• Dijkstra working memory: ~4,000 bytes for 200-node graph
• Total OSPF per node: ~14,400 bytes (14 KB) = 44% of 32 KB RAM

That leaves only 18 KB for the application, operating system, and network stack – too tight for most sensor firmware.

RPL memory requirements (distance-vector):

Each RPL node stores only local information:

• Preferred parent: 16 bytes (IPv6 address)
• Parent set (3 backup parents): 48 bytes
• DODAG info: 20 bytes (DODAG ID, version, RANK, instance)
• Neighbor table (8 neighbors): 8 x 24 bytes (address, RANK, ETX, link metrics) = 192 bytes
• Total RPL per node: ~276 bytes = 0.8% of 32 KB RAM

Power comparison (control message overhead):

Protocol	Update Frequency	Bytes/Update	Annual Energy
OSPF Hello	Every 10 seconds	44 bytes	247 mAh/year (exceeds battery)
RIP Full Table	Every 30 seconds	200 x 20 = 4,000 bytes	460 mAh/year (exceeds battery)
RPL DIO (Trickle)	10 ms initial, doubles to 1 hour steady-state	40 bytes	0.16 mAh/year

RPL’s Trickle timer is the key innovation: during steady state, DIO messages are sent only once per hour (vs OSPF’s every 10 seconds). When topology changes occur, the timer resets to rapid updates, then exponentially backs off as the network stabilizes.

Conclusion: OSPF requires 52x more memory and over 1,500x more energy than RPL for the same 200-node network. Neither OSPF nor RIP is viable on a 32 KB, coin-cell device. RPL was specifically designed to fit within these constraints.

Putting Numbers to It

Let’s calculate the precise battery life impact of OSPF vs RPL for the 200-sensor smart building.

OSPF Hello message energy cost:

OSPF sends Hello packets every 10 seconds on each interface. Assuming average 4 neighbors per sensor: \[\text{Hello rate} = \frac{3{,}600 \text{ s/hr}}{10 \text{ s}} \times 4 \text{ neighbors} = 1{,}440 \text{ Hellos/hr}\]

Each Hello transmission: 44 bytes × 8 bits/byte ÷ 250,000 bps = 1.41 ms airtime. At 50 mA TX current: \[E_{\text{Hello}} = 50 \text{ mA} \times 1.41 \text{ ms} = 70.5 \text{ mAms} = 0.0196 \text{ µAh}\]

Hourly energy: \(1{,}440 \times 0.0196 = 28.2\) µAh. Annual: \(28.2 \times 24 \times 365 = 247{,}032\) µAh = 247 mAh.

But a CR2032 battery is only 220 mAh! OSPF Hello messages alone exceed the battery capacity – forget application data.

RPL DIO message energy cost (with Trickle):

During steady state, RPL sends DIOs once per hour (Trickle max interval). Each DIO: 40 bytes × 8 bits/byte ÷ 250,000 bps = 1.28 ms. Energy per DIO: \[E_{\text{DIO}} = 50 \text{ mA} \times 1.28 \text{ ms} = 64 \text{ mAms} = 0.0178 \text{ µAh}\]

Hourly: 1 DIO (steady state) = 0.0178 µAh. Annual: \(0.0178 \times 24 \times 365 = 156\) µAh = 0.156 mAh.

Battery life calculation (with application data):

Assume application sends 20-byte reading every 5 minutes (288/day). Energy per reading: 1 mAms ≈ 0.28 µAh. \[E_{\text{app,year}} = 288 \times 365 \times 0.28 = 29{,}443 \text{ µAh} = 29.4 \text{ mAh}\]

Sleep current (10 µA deep sleep): \(0.01 \text{ mA} \times 24 \times 365 \times 3{,}600 \text{ s} = 87{,}600 \text{ mAs} = 87.6 \text{ mAh}\).

Total energy budget:

• OSPF: 247 + 29.4 + 87.6 = 364 mAh/year → Battery lasts 220 ÷ 364 = 0.6 years (7 months)
• RPL: 0.156 + 29.4 + 87.6 = 117 mAh/year → Battery lasts 220 ÷ 117 = 1.9 years

Result: RPL extends battery life by 3.1× compared to OSPF, enabling multi-year deployments without battery replacement.

28.4 Interactive: Protocol Resource Comparison

Compare memory and energy requirements across routing protocols for your deployment size.

viewof numSensors = Inputs.range([10, 500], {value: 200, step: 10, label: "Number of sensors"})

viewof ramKb = Inputs.range([8, 256], {value: 32, step: 8, label: "Sensor RAM (KB)"})

{
  // OSPF memory: LSDB per node
  const avgLinks = 4
  const lsaBytes = 16
  const linkBytes = 12
  const routeBytes = 12
  const dijkstraBytes = 4000
  const ospfMem = (numSensors * lsaBytes) + (numSensors * avgLinks / 2 * linkBytes) + (numSensors * routeBytes) + dijkstraBytes
  const ospfPct = ((ospfMem / (ramKb * 1024)) * 100).toFixed(1)

  // RPL memory: parent + DODAG info + neighbor table
  const rplMem = 16 + 48 + 20 + (8 * 24)
  const rplPct = ((rplMem / (ramKb * 1024)) * 100).toFixed(2)

  // Annual energy (mAh)
  const ospfEnergy = 247  // fixed for typical params
  const rplEnergy = 0.156
  const batteryMah = 220  // CR2032
  const ospfMonths = ((batteryMah / ospfEnergy) * 12).toFixed(1)
  const rplMonths = ((batteryMah / rplEnergy) * 12).toFixed(0)

  const ospfFeasible = ospfMem < ramKb * 1024 * 0.5
  const ospfColor = ospfFeasible ? "#E67E22" : "#E74C3C"
  const ospfLabel = ospfFeasible ? "Warning: High memory use" : "INFEASIBLE: Exceeds RAM budget"

  return html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #E67E22; font-family: Arial, sans-serif;">
    <p style="margin:0 0 0.75rem 0; font-weight:bold; color:#2C3E50;">Protocol Resource Requirements (${numSensors} nodes, ${ramKb} KB RAM)</p>
    <table style="width:100%; border-collapse:collapse; font-size:0.9rem; margin-bottom:0.75rem;">
      <tr style="background:#2C3E50; color:white;">
        <th style="padding:6px 8px; text-align:left;">Protocol</th>
        <th style="padding:6px 8px; text-align:right;">RAM per Node</th>
        <th style="padding:6px 8px; text-align:right;">% of ${ramKb} KB RAM</th>
        <th style="padding:6px 8px; text-align:right;">Annual Energy</th>
        <th style="padding:6px 8px; text-align:right;">CR2032 Life</th>
      </tr>
      <tr style="background:#ffeaea;">
        <td style="padding:6px 8px;"><strong>OSPF</strong></td>
        <td style="padding:6px 8px; text-align:right;">${(ospfMem / 1024).toFixed(1)} KB</td>
        <td style="padding:6px 8px; text-align:right; color:${ospfColor};"><strong>${ospfPct}%</strong></td>
        <td style="padding:6px 8px; text-align:right;">247 mAh</td>
        <td style="padding:6px 8px; text-align:right; color:#E74C3C;"><strong>${ospfMonths} months</strong></td>
      </tr>
      <tr style="background:#e8f5e9;">
        <td style="padding:6px 8px;"><strong>RPL</strong></td>
        <td style="padding:6px 8px; text-align:right;">276 bytes</td>
        <td style="padding:6px 8px; text-align:right; color:#16A085;"><strong>${rplPct}%</strong></td>
        <td style="padding:6px 8px; text-align:right;">0.16 mAh</td>
        <td style="padding:6px 8px; text-align:right; color:#16A085;"><strong>${rplMonths} months</strong></td>
      </tr>
    </table>
    <p style="margin:0; font-size:0.85rem; color:${ospfColor};"><strong>${ospfLabel}</strong> (routing protocol should use &lt;10% of RAM to leave headroom for application and OS)</p>
  </div>`
}

28.4.1 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

28.4.2 Multiple Routing Instances

IoT Scenario: Single physical network, multiple applications

Multiple RPL instances on the same physical network with different optimization goals

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

28.4.3 Point-to-Multipoint Traffic Patterns

Traditional networks: Assume peer-to-peer traffic

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

RPL Optimization: Optimized for convergent traffic towards root

28.4.4 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². 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 – valid (lower), Node E RANK 500 – invalid (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…→∞). 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 × 80 links × 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)

Quick Check: Why RPL for IoT?

28.5 RPL Core Concepts

28.5.1 Directed Acyclic Graph (DAG)

DAG = Directed Acyclic Graph

Directed Acyclic Graph (DAG) example showing nodes connected with directed arrows

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

28.5.2 DODAG (Destination Oriented DAG)

RPL uses DODAG: DAG with single root (destination)

Destination Oriented Directed Acyclic Graph (DODAG) with single root and RANK-based hierarchy

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

RPL DODAG Structure showing root node, routing paths, and upward data flow

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

28.5.3 RANK: Loop Prevention Mechanism

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

RANK loop prevention mechanism showing ROOT at Rank 0 and forbidden backward paths

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

Loop Prevention:

• Node C CAN choose Node A as parent (RANK 100 < 370 – valid, moving toward root)
• Node A CANNOT choose Node C as parent (RANK 370 > 100 – forbidden, would create loop)

RANK vs Hop Count

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

28.6 Knowledge Check

Quiz: RPL Specification and Core Concepts

Matching Quiz: RPL Specification Concepts

Ordering Quiz: RPL Protocol Stack Layers

Key Concepts

• RFC 6550: The primary RPL specification defining DODAG construction, RANK calculation, message formats, and routing behavior.
• RFC 6552 (OF0): Objective Function Zero — a minimal RPL Objective Function using hop count as RANK increment; a simple baseline for RPL implementations.
• RFC 6719 (MRHOF): Minimum Rank with Hysteresis Objective Function — uses ETX as link metric with hysteresis to prevent frequent parent switching.
• RFC 6206 (Trickle): The Trickle algorithm specification; used by RPL for DIO transmission rate adaptation.
• RFC 6775 (6LoWPAN-ND): Neighbor Discovery optimizations for 6LoWPAN, closely related to RPL deployment; replaces multicast-heavy IPv6 ND with unicast registration.

Common Pitfalls

1. Reading the RFC Without Implementation Context

RFC 6550 is dense and normative — reading it without a specific implementation question in mind makes it hard to absorb. Read the RFC alongside an existing RPL implementation (Contiki, RIOT) to connect specification text to actual code.

2. Implementing Partial RFC Compliance

Partial RFC 6550 implementations that omit features like DAO loop detection or RANK feasibility checking appear to work in simple networks but fail in complex topologies. Implement full RFC compliance or clearly document what is omitted and why.

3. Not Tracking RFC Updates and Errata

RFC 6550 has published errata and related RFCs (6552, 6719, 6775) that clarify and extend the base specification. Implement RFC 6550 without checking errata risks implementing known-incorrect behaviors.

28.7 What’s Next

If you want to…	Read this
Apply the specification in practical examples	RPL DODAG Worked Example
Understand Trickle algorithm in detail	RPL DODAG Trickle
Study message flow and formats	RPL DODAG Message Flow
See specification in production context	RPL Production Framework

🏷️ Label the Diagram

Code Challenge