698  RPL Core Concepts and DODAG Construction

698.1 RPL Core Concepts

698.1.1 Directed Acyclic Graph (DAG)

DAG = Directed Acyclic Graph

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    A["Node A"]
    B["Node B"]
    C["Node C"]
    D["Node D"]
    E["Node E"]

    A --> B
    A --> C
    B --> D
    C --> D
    D --> E

    style A fill:#2C3E50,stroke:#16A085,color:#fff
    style B fill:#16A085,stroke:#2C3E50,color:#fff
    style C fill:#16A085,stroke:#2C3E50,color:#fff
    style D fill:#E67E22,stroke:#2C3E50,color:#fff
    style E fill:#7F8C8D,stroke:#2C3E50,color:#fff

Figure 698.1: Directed Acyclic Graph (DAG) with nodes connected by directed edges without cycles

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

698.1.2 DODAG (Destination Oriented DAG)

RPL uses DODAG: DAG with single root (destination)

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    ROOT["ROOT<br/>(Single Destination)<br/>Rank: 0"]
    A["Node A<br/>Rank: 256"]
    B["Node B<br/>Rank: 256"]
    C["Node C<br/>Rank: 512"]
    D["Node D<br/>Rank: 512"]
    E["Node E<br/>Rank: 768"]
    F["Node F<br/>Rank: 768"]

    ROOT --> A
    ROOT --> B
    A --> C
    A --> D
    B --> D
    C --> E
    D --> F

    style ROOT fill:#2C3E50,stroke:#16A085,color:#fff,stroke-width:4px
    style A fill:#16A085,stroke:#2C3E50,color:#fff
    style B fill:#16A085,stroke:#2C3E50,color:#fff
    style C fill:#E67E22,stroke:#2C3E50,color:#fff
    style D fill:#E67E22,stroke:#2C3E50,color:#fff
    style E fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style F fill:#7F8C8D,stroke:#2C3E50,color:#fff

Figure 698.2: DODAG topology with single ROOT (Rank 0) and hierarchical node ranks increasing away from root

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

DAG vs DODAG
Figure 698.3: Difference between DAG (any directed acyclic graph) and DODAG (destination-oriented)
RPL DAG and DODAG
Figure 698.4: RPL DAG and DODAG structure showing root and tree formation

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)

698.1.3 RANK: Loop Prevention Mechanism

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

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    ROOT["ROOT<br/>RANK = 0"]
    A["Node A<br/>RANK = 100"]
    B["Node B<br/>RANK = 250"]
    C["Node C<br/>RANK = 370"]

    ROOT -->|"Good link<br/>+100"| A
    A -->|"Poor link<br/>+150"| B
    B -->|"Good link<br/>+120"| C

    C -.->|"❌ Cannot choose<br/>(370 > 100 = loop!)"| A

    style ROOT fill:#2C3E50,stroke:#16A085,color:#fff,stroke-width:4px
    style A fill:#16A085,stroke:#2C3E50,color:#fff
    style B fill:#E67E22,stroke:#2C3E50,color:#fff
    style C fill:#7F8C8D,stroke:#2C3E50,color:#fff

Figure 698.5: RPL RANK mechanism preventing routing loops by enforcing increasing rank away from 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”}

RPL RANK mechanism
Figure 698.6: RPL RANK mechanism preventing loops by increasing rank with distance from root

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)

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

698.2 DODAG Construction Process

RPL builds the DODAG through control messages:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    DIO["DIO<br/>DODAG Information Object<br/>Advertise DODAG"]
    DIS["DIS<br/>DODAG Information Solicitation<br/>Request DODAG info"]
    DAO["DAO<br/>Destination Advertisement Object<br/>Advertise reachability"]
    DAOACK["DAO-ACK<br/>Acknowledge DAO"]

    ROOT["ROOT sends DIO"]
    NODE["Node receives DIO"]
    JOIN["Node joins DODAG"]
    ADV["Node sends DAO"]

    ROOT --> NODE
    NODE --> JOIN
    JOIN --> ADV

    style DIO fill:#2C3E50,stroke:#16A085,color:#fff,stroke-width:3px
    style DIS fill:#16A085,stroke:#2C3E50,color:#fff
    style DAO fill:#E67E22,stroke:#2C3E50,color:#fff
    style DAOACK fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style ROOT fill:#2C3E50,stroke:#16A085,color:#fff
    style NODE fill:#16A085,stroke:#2C3E50,color:#fff
    style JOIN fill:#E67E22,stroke:#2C3E50,color:#fff
    style ADV fill:#7F8C8D,stroke:#2C3E50,color:#fff

Figure 698.7: RPL control messages (DIO, DIS, DAO, DAO-ACK) and DODAG construction flow from root to nodes

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

Building a DODAG
Figure 698.8: Building a DODAG showing progressive node joining and rank assignment

698.2.1 Step-by-Step DODAG Construction

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant ROOT as ROOT (Rank 0)
    participant N1 as Node 1
    participant N2 as Node 2
    participant N3 as Node 3

    Note over ROOT: Step 1: ROOT initiates DODAG
    ROOT->>ROOT: Create DODAG ID<br/>Set RANK = 0
    ROOT->>N1: DIO (DODAG_ID, RANK=0)
    ROOT->>N2: DIO (DODAG_ID, RANK=0)

    Note over N1,N2: Step 2: Nodes receive DIO and join
    N1->>N1: Calculate RANK = 100<br/>Select ROOT as parent
    N2->>N2: Calculate RANK = 100<br/>Select ROOT as parent

    Note over N1,N2: Step 3: Nodes propagate DIO
    N1->>N3: DIO (DODAG_ID, RANK=100)
    N2->>N3: DIO (DODAG_ID, RANK=100)

    Note over N3: Step 4: Build upward routes
    N3->>N3: Calculate RANK = 200<br/>Select N1 as parent<br/>Parent pointer established

    Note over N3: Step 5: Build downward routes
    N3->>N1: DAO (I am reachable)
    N1->>ROOT: DAO (N3 reachable via me)
    ROOT->>N1: DAO-ACK

Figure 698.9: DODAG construction sequence showing DIO propagation, parent selection, and DAO route advertisement

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

698.2.2 Detailed Construction Steps

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

RPL construction steps
Figure 698.10: RPL DODAG construction steps from root initialization to completion

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

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². 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 360× transmissions!

698.4 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

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

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.