31  RPL DODAG Message Flow and Exchange

In 60 Seconds

RPL builds its DODAG topology through four control messages: DIO (advertise DODAG info downward), DIS (solicit DODAG info), DAO (advertise reachability upward), and DAO-ACK (confirm receipt). This chapter traces the complete message exchange during DODAG formation and analyzes RANK calculations using ETX link quality metrics.

31.1 Learning Objectives

After completing this chapter, you will be able to:

• Trace the complete message exchange during DODAG formation through all five phases
• Classify the four RPL control messages (DIO, DIS, DAO, DAO-ACK) by direction and purpose
• Analyze message flows through a concrete 12-node network example with IPv6 addresses
• Calculate RANK values using ETX link quality metrics and MinHopRankIncrease parameters

For Beginners: RPL Message Flow

RPL (Routing Protocol for Low-Power Networks) uses special messages to build and maintain routes. Think of it like a group of hikers marking trails with signs – devices send out messages saying how far they are from the destination, and their neighbors use this information to choose the best path forward.

Sensor Squad: The Four Magic Messages!

“RPL uses four types of messages to build and maintain the network,” said Max the Microcontroller. “Think of them like four types of notes you might pass in class.”

“DIO is like the teacher announcing ‘I am here, come sit near me!’” explained Sammy the Sensor. “The root sends DIOs outward so everyone knows the network exists. DIS is like raising your hand and asking ‘Where should I sit?’ – new devices send DIS when they want to join.”

“DAO is like telling the teacher your seat number,” added Lila the LED. “Each device sends DAO messages upward saying ‘I am reachable at this address, through this path.’ This is how the root learns where everyone is sitting so it can send messages back down.”

“And DAO-ACK is just a thumbs up,” said Bella the Battery. “The parent says ‘Got it, I know you are there!’ It is a simple confirmation. Together, these four messages build the entire routing tree from scratch – no human configuration needed!”

31.2 RPL Control Messages Overview

RPL builds the DODAG through control messages carried as ICMPv6 type 155 packets:

Graph diagram

Figure 31.1: RPL control messages and DODAG joining flow

Message Direction Summary:

• DIO: Flows downward (away from root) – Builds DODAG topology
• DIS: Sent to neighbors – Requests DIOs to accelerate joining
• DAO: Flows upward (toward root) – Builds downward routing tables
• DAO-ACK: Flows downward (from root/parents) – Confirms DAO received

31.3 Step-by-Step DODAG Construction

Mermaid diagram

Figure 31.2: Complete DODAG construction with DIO, DAO, and DAO-ACK

31.4 Message Flow: Complete Sequence Diagram

This enhanced sequence diagram shows the complete message exchange during DODAG formation, including timing and RANK calculation:

Mermaid diagram

Figure 31.3: Complete 7-step DODAG formation sequence with timing

Key insights from message flow:

1. RANK increases hop-by-hop based on link quality (ETX), not just hop count
2. DIO flows downward (away from root), DAO flows upward (toward root)
3. DIS accelerates discovery – nodes can solicit DIO instead of waiting for periodic broadcast
4. DAO aggregation: intermediate nodes combine child reachability into a single DAO forwarded to root
5. Convergence: 30 seconds typical for small networks, up to 120s for large or deep networks

31.5 Enhanced Message Flow: Detailed DODAG Building Sequence

This section provides an in-depth walkthrough of exactly what happens during DODAG formation, with specific message contents, timing details, and node state changes. Understanding this level of detail is crucial for troubleshooting and optimizing RPL networks.

31.5.1 Message Types and Their Roles

Graph diagram

Figure 31.4: Four RPL control message types and their purposes

31.5.2 Detailed Step-by-Step Message Exchange

Let’s walk through a concrete example with specific node addresses, message contents, and timing. This example shows a 12-node smart building network forming its DODAG.

Network Setup:

• Root: Border router (BR) at address fd00::1, connected to Internet
• Nodes: 11 sensor nodes (addresses fd00::2 through fd00::c)
• Topology: 4-layer hierarchy (root + 3 layers of sensors)
• Radio: IEEE 802.15.4, range ~30m per hop
• Objective Function: MRHOF with ETX metric

Mermaid diagram

Figure 31.5: Detailed message exchange with IPv6 addresses and ETX metrics

Key Observations from Detailed Exchange:

1. Parent Selection is Metric-Based: Node C receives DIOs from both Node A (RANK 307) and Node B (RANK 384), but chooses Node A because the total path cost (parent RANK + ETX x MinHopRankIncrease) is lower

2. DAO Aggregation: When Node C sends its DAO to Node A, Node A aggregates both its own reachability (fd00::2) and Node C’s reachability (fd00::4) into a single DAO forwarded to the root

3. Bidirectional Confirmation: DAO-ACK messages flow back down the same path, confirming each hop that the route was successfully installed

4. Timing Dependencies: Each step depends on the previous completing:

   • DIOs must arrive before nodes can calculate RANK
   • RANK must be calculated before nodes send DAO
   • DAO must arrive before DAO-ACK can be sent

5. Trickle Timer Behavior: After initial formation (~30s), DIO interval increases from 10s -> 30s -> 1min -> 10min to minimize overhead once topology is stable

31.6 Understanding RANK Calculation in Formation

As the DODAG forms, each node calculates its RANK based on the Objective Function (OF):

Example with ETX (Expected Transmission Count) metric using MinHopRankIncrease = 256:

Root: RANK = 0

First-hop node (good link, ETX = 1.2):
RANK = 0 + (1.2 × 256) = 307

Second-hop node (good link from first-hop, ETX = 1.1):
RANK = 307 + (1.1 × 256) = 307 + 282 = 589

Leaf node (poor link from second-hop, ETX = 2.5):
RANK = 589 + (2.5 × 256) = 589 + 640 = 1229

RANK increases as you move away from root. Nodes always forward upward to lower RANK (toward root), preventing loops. The rate of increase depends on link quality – poor links cause larger RANK jumps, discouraging routes through unreliable paths.

Objective Functions:

• OF0 (RFC 6552): Hop count or ETX (simple, widely supported)
• MRHOF (RFC 6719): Minimum Rank with Hysteresis (avoids parent flapping)
• Custom OFs: Energy-aware, latency-optimized, security-enhanced (application-specific)

Conceptual Diagram

RPL Objective Function

Comparison View

RPL Objective Functions Comparison

Figure 31.6: RPL Objective Functions determine how RANK is calculated and influence parent selection decisions

31.7 Interactive: RPL Control Overhead Calculator

Calculate how RPL control traffic scales with your network deployment:

viewof nodeCount = Inputs.range([10, 1000], {value: 500, step: 10, label: "Number of nodes"})

viewof avgHops = Inputs.range([1, 10], {value: 6, step: 1, label: "Average path length (hops)"})

viewof trickleInterval = Inputs.range([1, 60], {value: 10, step: 1, label: "Trickle DIO interval (minutes)"})

{
  const appMessagesPerHour = nodeCount * 12; // 1 message per 5 minutes per node
  const appTransmissions = appMessagesPerHour * avgHops;
  const dioPerHour = nodeCount * (60 / trickleInterval);
  const daoPerHour = Math.round(nodeCount * 0.02) * avgHops; // 2% churn
  const daoAckPerHour = daoPerHour;
  const controlTotal = dioPerHour + daoPerHour + daoAckPerHour;
  const overheadPct = (controlTotal / (appTransmissions + controlTotal) * 100).toFixed(1);
  return html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #16A085; font-family: Arial, sans-serif;">
    <p style="margin:0 0 0.5rem 0;"><strong style="color:#2C3E50;">Steady-State Traffic Analysis</strong></p>
    <p style="margin:0 0 0.25rem 0; font-size:0.9em;">Application transmissions/hr: <strong>${appTransmissions.toLocaleString()}</strong> (${nodeCount} nodes × 12 msgs/hr × ${avgHops} hops)</p>
    <p style="margin:0 0 0.25rem 0; font-size:0.9em;">DIO transmissions/hr: <strong>${dioPerHour.toLocaleString()}</strong> (${nodeCount} nodes × ${(60/trickleInterval).toFixed(1)} DIOs/hr)</p>
    <p style="margin:0 0 0.25rem 0; font-size:0.9em;">DAO + DAO-ACK/hr: <strong>${(daoPerHour + daoAckPerHour).toLocaleString()}</strong> (2% topology churn)</p>
    <p style="margin:0; font-size:0.95em; padding-top:0.5rem; border-top:1px solid #dee2e6;"><strong style="color:#16A085;">Control overhead: ${overheadPct}%</strong> of total traffic</p>
  </div>`;
}

31.8 Detailed Construction Steps

Step 1: Root Initiates DODAG

Root node (border router/gateway): 1. Creates DODAG: Assigns unique DODAG ID 2. Sets RANK = 0: Root has minimum RANK 3. Broadcasts DIO: Sends DODAG Information Object (multicast)

DIO Contents:

• DODAG ID (IPv6 address)
• RANK (0 for root)
• Objective function (routing metric)
• DODAG configuration (timers, etc.)

## Step 2: Nodes Receive DIO and Join {#net-rpl-fund-step2}

Node receives DIO:

1. Decision: Join this DODAG or wait for others?
   • Compare DODAG rank, objective function
   • May receive DIOs from multiple DODAGs
2. Calculate RANK: RANK = parent_RANK + ETX x MinHopRankIncrease
3. Select parent: Choose sender with lowest resulting RANK
4. Update state: Store DODAG ID, parent, RANK

Multiple DIO Sources:

• Node may hear DIOs from multiple neighbors
• Chooses best parent (lowest resulting RANK, best link quality)
• May maintain backup parents (loop-free)

Quiz 1: Step 2: Nodes Receive DIO and Join

31.9 Step 3: Nodes Propagate DIO

After joining DODAG:

1. Node becomes part of DODAG
2. Sends own DIO: Advertises DODAG to neighbors
3. DIO contents: Own RANK, DODAG ID, etc.
4. Trickle timer: Controls DIO frequency (adaptive)

Trickle Algorithm:

• Stable network: Send DIOs infrequently (minutes)
• Network changes: Send DIOs frequently (seconds)
• Reduces overhead while maintaining responsiveness

Step 4: Build Upward Routes

Upward routes (towards root) established automatically: - Each node knows its parent (from DIO selection) - Default route: Send to parent (towards root) - No routing table needed for upward routes (just parent pointer)

Example:

Node 3 -> Node 1 -> Root
(N3 knows parent is N1, N1 knows parent is Root)

Step 5: Build Downward Routes (Storing Mode)

Downward routes (from root to nodes) require DAO messages:

1. Node sends DAO to parent:
   • “I am reachable via you”
   • Includes node’s address and prefixes
2. Parent updates routing table:
   • “Node X is reachable via this child”
3. Parent propagates DAO towards root:
   • Aggregates reachability information
4. Root knows all nodes:
   • Complete routing table for downward routes

DAO-ACK (optional): - Parent confirms DAO receipt - Reliability for critical networks

Quiz 2: Step 5: Build Downward Routes (Storing Mode)

Interactive: RPL Message Flow Animation

31.10 Real-World RPL Convergence Characteristics

Understanding theoretical message flow is essential, but real-world RPL deployments reveal convergence behaviors that differ significantly from textbook examples.

Deployment Data: Smart Street Lighting (Copenhagen, 2019-2022)

Copenhagen’s Lighting Metropolis project deployed RPL-based 6LoWPAN networks connecting 20,000 LED street lights across 43 km of roads. Each light acts as both a sensor node (ambient light, traffic volume) and a mesh router.

Measured convergence times by network depth:

Network Depth (hops)	Nodes in Subtree	Initial DODAG Formation	Recovery After Gateway Restart	Recovery After Single Node Failure
1-2 hops	50	8 seconds	12 seconds	2 seconds
3-4 hops	200	35 seconds	45 seconds	8 seconds
5-7 hops	800	90 seconds	120 seconds	15 seconds
8-10 hops	2,000+	180 seconds	240 seconds	25 seconds

Key observations:

1. DIO propagation delay is linear with depth but convergence is quadratic because DAO messages must propagate back up after each layer joins
2. Trickle timer reset storms: When the gateway restarts, all 20,000 nodes detect topology change and reset their trickle timers to minimum interval (500 ms). The resulting DIO flood consumed 40% of network capacity for the first 2 minutes
3. ETX vs. hop count: Nodes using ETX-based MRHOF selected paths 1-2 hops longer but with 23% higher packet delivery rate than minimum-hop OF0
4. Parent flapping: 3.2% of nodes changed preferred parent more than 5 times per hour due to variable link quality from passing vehicles. Enabling MRHOF hysteresis (threshold = 1.5) reduced flapping to 0.4%

Worked Example: DODAG Control Message Overhead Budget

Scenario: A building management system uses RPL with 500 sensor nodes across 15 floors. The border router is on the roof. Average depth is 6 hops. Nodes report temperature every 5 minutes. Network uses MRHOF with ETX.

Question: What fraction of total network traffic is RPL control overhead?

Calculation:

Application traffic:
  500 nodes x 1 message/5 min x 12 messages/hour = 6,000 app messages/hour
  Average path length: 6 hops -> 6,000 x 6 = 36,000 app packet transmissions/hour

RPL control traffic (steady state):
  DIO messages: Trickle timer at steady state = ~10 min interval
    500 nodes x 6 DIOs/hour = 3,000 DIO transmissions/hour
  DAO messages: Triggered by topology changes (~2% of nodes/hour)
    10 nodes/hour x 6 hops average = 60 DAO transmissions/hour
  DIS messages: Negligible in steady state
  DAO-ACK messages: 60 (matching DAOs)

Total control: 3,000 + 60 + 60 = 3,120 control transmissions/hour
Total application: 36,000 transmissions/hour

Control overhead: 3,120 / (36,000 + 3,120) = 8.0%

During topology change (e.g., node failure affecting 50 child nodes):

Trickle resets for 50 affected nodes:
  50 nodes x 12 DIOs/min (reset interval) x 5 min convergence = 3,000 DIOs
  50 nodes x 1 DAO x 6 hops = 300 DAO transmissions
  300 DAO-ACK transmissions

Burst overhead: 3,600 control messages in 5 minutes
  = 720/min vs. normal 52/min = 14x spike

Impact: For those 5 minutes, control traffic is 54% of total

Design implication: RPL networks must reserve at least 15-20% of channel capacity for control traffic to handle topology change bursts without dropping application data.

Putting Numbers to It

How does RPL’s control overhead scale with network depth? Consider two deployment options for connecting 500 sensors:

Option A - Shallow network (3 hops max, dense deployment): - Average path length: 2.5 hops - Application traffic: 500 × 12 packets/hr × 2.5 hops = 15,000 transmissions/hr - DIO overhead (10 min trickle): 500 × 6/hr = 3,000 DIOs/hr - DAO overhead (stable): ~10 nodes change/hr × 2.5 hops = 25 DAOs/hr - Control %: \((3,025) / (15,000 + 3,025) = 16.8\%\)

Option B - Deep network (8 hops max, sparse deployment): - Average path length: 6 hops - Application traffic: 500 × 12 × 6 = 36,000 transmissions/hr - DIO overhead: still 3,000/hr (per-node, not per-path) - DAO overhead: 10 × 6 = 60 DAOs/hr - Control %: \((3,060) / (36,000 + 3,060) = 7.8\%\)

Insight: Deeper networks have lower relative control overhead (7.8% vs 16.8%) because application traffic scales with depth (6x hops) but DIO messages don’t (per-node rate is constant). This counters intuition that “more hops = more overhead.”

But deeper networks have worse latency (6 × 30ms = 180ms vs 75ms) and lower reliability (0.95^6 = 73.5% vs 0.95^2.5 = 88.3% delivery). Choose shallow when possible!

Match the RPL Message to Its Role

Order the RPL Message Exchange During DODAG Formation

Key Concepts

• DIO (DODAG Information Object): Downward-flowing RPL messages containing DODAG ID, version, RANK, and objective function information; nodes use DIOs to join and maintain DODAG.
• DIS (DODAG Information Solicitation): A message sent by a new node requesting DIO responses from neighbors; triggers faster DODAG joining without waiting for scheduled DIO transmission.
• DAO (Destination Advertisement Object): Upward-flowing messages sent in Storing Mode by nodes to register their prefixes with ancestors; builds downward routing tables toward the root.
• DAO-ACK: An acknowledgment sent in response to a DAO message confirming that the route registration was received; used for reliable DAO delivery.
• Trickle Timer: A self-adjusting timer controlling DIO transmission frequency; doubles the interval when the network is stable (reducing overhead), resets when inconsistency is detected.
• Consistency: A Trickle Timer state where a node has heard consistent DIO messages, causing the timer to slow down DIO transmission rate to reduce overhead.

Common Pitfalls

1. Not Understanding DIO Trickle Behavior

Trickle Timer doubles the DIO interval when the network is stable, so DIO rate is low in steady state. When debugging RPL, developers sometimes mistake the low DIO rate for a protocol failure — first check whether the trickle interval is simply large.

2. Expecting Immediate DAO Propagation

DAO messages propagate hop-by-hop upward to the root; in a deep DODAG, full route registration can take several minutes. Applications that check route availability immediately after boot will fail — allow time for DAO propagation.

3. Ignoring DAO-ACK Timeout Handling

If a DAO-ACK is not received, the node must retransmit the DAO. Missing DAO-ACK retransmission logic causes route registration failures that appear as intermittent downlink connectivity issues.

🏷️ Label the Diagram

Code Challenge

31.11 Summary

This chapter covered the detailed message flow during DODAG construction:

• Four Control Messages: DIO (topology), DIS (solicitation), DAO (reachability), DAO-ACK (confirmation)
• Message Directions: DIO flows downward, DAO flows upward, DIS to neighbors
• RANK Calculation: Based on objective function using ETX x MinHopRankIncrease; RANK = Parent_RANK + ETX x 256 for default settings
• Parent Selection: Nodes choose parents with lowest cumulative path cost (RANK)
• DAO Aggregation: Intermediate nodes combine reachability from multiple children
• Five Construction Steps: Root init, DIO reception, DIO propagation, upward routes, downward routes
• Real-world convergence: 8-second formation for shallow networks (2 hops), up to 180 seconds for deep networks (10 hops); reserve 15-20% channel capacity for control overhead

How It Works: RPL Four-Message Exchange

RPL uses four control messages to build and maintain the DODAG. Here’s how they work together:

Phase 1: DODAG Advertisement (DIO)

• Who sends: Root and all DODAG members
• Direction: Downward (away from root)
• Contents: DODAG ID, RANK, Objective Function, configuration
• Purpose: “I am part of this DODAG at RANK X - you can join through me”
• Trigger: Trickle timer (adaptive: seconds when unstable, minutes when stable)

Phase 2: Information Request (DIS) - Optional

• Who sends: New nodes or nodes that lost parent
• Direction: Multicast to neighbors
• Contents: Request for DIO
• Purpose: “Send me your DODAG info immediately - I need to join”
• Trigger: Node startup, parent loss, no DIO received in expected timeframe

Phase 3: Reachability Advertisement (DAO)

• Who sends: All nodes (except root)
• Direction: Upward (toward root)
• Contents: Node’s IPv6 prefix, path information
• Purpose: “I am reachable at this address - install downward route”
• Trigger: Joined DODAG, parent changed, periodic refresh

Phase 4: Route Confirmation (DAO-ACK) - Optional

• Who sends: Parent or root
• Direction: Downward (toward DAO sender)
• Contents: Acknowledgment of DAO receipt
• Purpose: “Got your DAO - route installed successfully”
• Trigger: DAO reception (if DAO requested ACK)

Message Flow Timeline:

1. Root sends DIO (t=0s)
2. First-hop nodes receive DIO, calculate RANK, join (t=2-5s)
3. First-hop nodes send DAO upward (t=5-10s)
4. Root sends DAO-ACK downward (t=10-12s)
5. First-hop nodes send DIO outward (t=12-15s)
6. Second-hop nodes receive DIO, repeat process…
7. Network fully converged (t=30-120s depending on depth)

Energy Optimization: After initial formation, Trickle algorithm reduces DIO frequency from every 10s to every hour+, saving 99%+ battery life.

Concept Relationships

Message flow builds upon:

• RPL Core Concepts - DODAG, RANK, control messages overview
• RPL DODAG Construction - Five-phase construction process
• ICMPv6{target=“_blank”} - RPL uses ICMPv6 type 155 for control messages

Message flow connects to:

• RPL DODAG Visual Guide - Visual representation of message exchange
• RPL Trickle Algorithm - Adaptive DIO timing
• RPL Routing Modes - How DAO differs in Storing vs Non-Storing

Applications:

• Debugging RPL networks with Wireshark (capture DIO/DAO messages)
• Estimating network convergence time
• Configuring Trickle parameters for energy vs responsiveness trade-off

See Also

Protocol Details:

• RFC 6550 Section 6 - RPL Control Messages
• RFC 6206 - Trickle Algorithm
• ICMPv6 Type 155 - RPL Message Type

Analysis Tools:

• Wireshark RPL Dissector - Capture and analyze RPL messages
• 6LoWPAN Analyzer - Border router sniffer
• Contiki-NG RPL Debug

Visualization:

• Interactive RPL Animation - See message flow in action
• Multi-Hop Network Simulator

Related Topics:

• 6LoWPAN Compression - How RPL messages are compressed
• Thread Protocol - Uses modified RPL

31.12 What’s Next

Previous	Up	Next
RPL DODAG Construction	RPL DODAG Construction	RPL DODAG Visual Guide

Continue learning about DODAG construction details:

• RPL DODAG Visual Guide: Step-by-step visual progression
• RPL DODAG Worked Example: Complete 10-node network calculation
• RPL Trickle Algorithm: Energy-efficient maintenance mechanism
• RPL DODAG Construction Overview: Return to overview