716 RPL DODAG Message Flow and Exchange

716.1 Learning Objectives

After completing this chapter, you will be able to:

Understand the complete message exchange during DODAG formation
Identify the four core RPL control message types (DIO, DIS, DAO, DAO-ACK)
Trace message flows through a concrete network example
Analyze RANK calculations using ETX link quality metrics

716.2 RPL Control Messages Overview

RPL builds the DODAG through control messages:

{fig-alt=“RPL control messages overview showing DIO (advertise DODAG), DIS (request info), DAO (advertise reachability), DAO-ACK (acknowledgment), and DODAG construction flow from ROOT sending DIO through node joining to DAO advertisement”}

Artistic visualization of RPL control message types: DIO broadcasting DODAG information outward from root, DIS soliciting information from new nodes, DAO advertising reachability upward toward root, and DAO-ACK confirming receipt for reliable downward routes — RPL Control Messages

Geometric visualization of RPL objective function showing multiple metrics like ETX, hop count, energy, and latency being combined into a single rank value that determines parent selection and routing path preference — RPL Objective Function

716.3 Step-by-Step DODAG Construction

{fig-alt=“DODAG construction sequence diagram showing 5 steps: ROOT initiates with DIO, nodes receive and join calculating RANK, nodes propagate DIO, upward routes established via parent pointers, downward routes built via DAO messages”}

716.4 Message Flow: Complete Sequence Diagram

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

{fig-alt=“Complete DODAG formation sequence diagram showing temporal progression from t=0s initialization through 7 steps: root DIO broadcast, first-hop join with RANK calculation, ripple expansion via DIS/DIO, DAO messages flowing upward to build downward routes, DAO-ACK confirmations, and final steady state with operational network, illustrating message types, RANK values at each hop, and timing for 50-node network convergence”}

Key insights from message flow: 1. RANK increases hop-by-hop: 0 -> 256 -> 456 -> 636 (based on link quality, not just hop count) 2. DIO flows downward (away from root), DAO flows upward (toward root) 3. DIS accelerates discovery (Node C doesn’t wait for periodic DIO from B) 4. DAO aggregation: Node B’s DAO to A includes both B and C reachability 5. Convergence: 30 seconds typical for small network, up to 120s for large/deep networks

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

716.5.1 Message Types and Their Roles

Before diving into the sequence, let’s understand the four core RPL control messages:

{fig-alt=“RPL control message types diagram showing four core message types: DIO for advertising DODAG information with RANK and configuration, DIS for requesting DODAG information to speed joining, DAO for advertising node reachability to build downward routes, and DAO-ACK for confirming route installation, with each message type showing its primary purpose and information carried”}

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

716.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: ETX (Expected Transmission Count)

{fig-alt=“Detailed RPL DODAG formation message exchange sequence showing complete protocol interaction between border router root node and three sensor nodes with specific IPv6 addresses, including exact message contents with DODAG ID, RANK calculations based on ETX link quality metrics, parent selection logic comparing multiple potential parents, DAO message aggregation as nodes forward reachability information upward, and DAO-ACK confirmations flowing back down to establish bidirectional routing”}

Key Observations from Detailed Exchange:

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 + link ETX) is lower (589 vs 896)
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
Bidirectional Confirmation: DAO-ACK messages flow back down the same path, confirming each hop that the route was successfully installed
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
Trickle Timer Behavior: After initial formation (~30s), DIO interval increases from 10s -> 30s -> 1min -> 10min to minimize overhead once topology is stable

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

Root: RANK = 0

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

Second-hop node (good link from first-hop, ETX = 1.1):
RANK = 300 + (1.1 x 256) = 300 + 282 = 582

Leaf node (poor link from second-hop, ETX = 2.5):
RANK = 582 + (2.5 x 256) = 582 + 640 = 1222

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)

Artistic visualization of RPL Objective Function concepts showing how different metrics (ETX, hop count, energy, latency) are combined to calculate RANK values, with color-coded paths demonstrating how the objective function guides parent selection by evaluating link quality, energy consumption, and path reliability to optimize routing decisions. — RPL Objective Function

Geometric comparison diagram of different RPL objective functions including OF0 (hop count based), MRHOF (ETX with hysteresis), and energy-aware variants, showing how each function calculates RANK differently and leads to different parent selections in the same network topology. — RPL Objective Function

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

Four-stage RPL DODAG formation process showing temporal progression: stage 1 root node initializes DODAG and broadcasts first DIO messages, stage 2 first-hop neighbor nodes receive DIOs and calculate RANK values to join as direct children, stage 3 second-hop nodes receive propagated DIOs from first-hop nodes and establish parent relationships, stage 4 complete DODAG topology with all nodes organized in hierarchical layers by RANK distance from root — Figure 716.9: RPL DODAG construction steps from root initialization to completion

716.8 Step 2: Nodes Receive DIO and Join

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 + increase 3. Select parent: Choose sender of DIO (if acceptable) 4. Update state: Store DODAG ID, parent, RANK

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

Quiz 1: Step 2: Nodes Receive DIO and Join

Question 7: An agricultural IoT network using RPL experiences a node failure. Node D was the parent for three child nodes (E, F, G). What happens during network self-healing?

Explanation: RPL’s self-healing is distributed and automatic. Each node expects periodic DIO messages from its parent. When nodes E, F, G stop receiving DIOs from D (typically after 3-4 missed intervals based on trickle timer), they: 1. Mark parent D as unreachable 2. Select new best parent from cached DIO information of other neighbors 3. Update their RANK based on new parent 4. Send updated DAO messages (in Storing mode) to advertise their reachability via new path 5. Resume normal operation

This process is local - no global reconstruction needed. The trickle timer algorithm balances responsiveness (fast recovery) with efficiency (infrequent messages when network is stable). DIS messages can accelerate discovery but aren’t required. Global reconstruction only occurs for major events (root failure, DODAG version increment).

Question 10: A battery-powered soil moisture sensor network uses RPL with 50 nodes over 15 km square. Nodes are 3-7 hops from the root. What RPL optimization would most significantly extend battery life?

Explanation: For battery-powered sensor networks with primarily many-to-one traffic (sensors -> gateway), the biggest energy drain is control message overhead (DIO, DAO transmissions). Optimization A addresses this: - Non-Storing mode: No DAO messages propagating between nodes (only to root), reducing TX overhead - Trickle timer: RPL’s adaptive timer sends DIOs frequently when network changes, but exponentially backs off to very infrequent transmissions (minutes/hours) when stable. Aggressive suppression means nodes listen for redundant DIOs and skip their own transmission if neighbors already sent

Why not others: - B (Storing mode): Increases DAO overhead; P2P traffic is rare in sensor networks - C (Disable DAO): Breaks downward routing; needed for configuration updates - D (More DIOs): Increases energy consumption, opposite of goal

Energy calculation: In stable network, trickle timer can reduce DIOs from every 10s to every 1 hour, saving 360x transmissions!

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

Node sends DAO to parent:
- “I am reachable via you”
- Includes node’s address and prefixes
Parent updates routing table:
- “Node X is reachable via this child”
Parent propagates DAO towards root:
- Aggregates reachability information
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)

Question 3: A parking sensor network uses RPL in Storing mode. Sensor A (RANK 5) needs to send data to Sensor B (RANK 6). How is this point-to-point traffic routed?

Explanation: In Storing mode, each node maintains routing tables populated by DAO messages. When Sensor A needs to reach Sensor B, it looks up B’s address in its routing table and forwards the packet accordingly. The routing may go through intermediate nodes, but doesn’t necessarily go through the root. This is the key advantage of Storing mode for P2P traffic - direct/optimized paths. In Non-Storing mode, the packet would go up to the root, which then source-routes it down to B. Storing mode trades memory (routing tables) for lower P2P latency.

716.10 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 (ETX, hop count, energy)
Parent Selection: Nodes choose parents with lowest cumulative path cost
DAO Aggregation: Intermediate nodes combine reachability from multiple children
Five Construction Steps: Root init, DIO reception, DIO propagation, upward routes, downward routes

716.11 What’s Next

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