Chapters

9 How a DODAG Forms

routing
rpl
iot

An RPL root begins by announcing a routing instance, and nearby low-power nodes choose parents before advertising farther outward. The DODAG grows through control messages and rank constraints rather than from a pre-drawn tree. Its evidence is the sequence of advertisements, choices, and downward-route updates.

A protocol is a rule for exchanging routing messages. A directed acyclic graph is a loop-free directed shape. RPL means Routing Protocol for Low-Power and Lossy Networks. DODAG means destination-oriented directed acyclic graph, the RPL form that leads toward a root.

9.1 Watch the DODAG Grow One Advertisement at a Time

Start at Figure 9.5. Read the root and directed edges with rank increasing away from the root. The constraint prevents a node from selecting a parent that is farther down its own directed path. A DODAG can contain several candidate links even though each node selects a preferred parent.

Figure 9.1 follows initialization, DIO spread, candidate evaluation, parent choice, rank advertisement, and maintenance. Figure 9.2 narrows the calculation. Read parent rank and link metric before the resulting choice; rank is derived evidence, not an arbitrary depth label.

Figure 9.4 compares alternatives, while Figure 9.3 shows what to retain for review: instance and version, DIO details, neighbour metrics, preferred parent, rank, DAO state, and timestamps. Figure 9.1 should be revisited after a repair because Trickle can change advertisement timing once the network is stable or inconsistent.

Consider root R advertising base rank 256. Nodes A and B join with ranks 512 and 512 under the simplified teaching increment. Node C hears A with link cost 20 and B with link cost 35, so its additive candidates differ by 15 even though parent ranks match. It selects A and advertises a rank greater than 512 under the configured objective function.

If A disappears, C should age or invalidate that route, compare remaining candidates, choose B when acceptable, and advertise the changed state. Downward traffic also needs DAO handling according to storing or non-storing mode. A successful upward ping does not prove that the root can route a command back to C.

Predict construction evidence. Start only R and expect its DIO before any child rank. Add A and B, then expect both to select R. Add C and expect the lower-cost A path under the fixture. Remove A and expect a bounded transition to B rather than a loop or permanent stale parent. Finally test both upward telemetry and downward reachability while correlating DIO and DAO logs.

9.2 Start With the Root Announcement

Watch One Parent Choice Change

Picture vineyard sensors passing frost readings toward one field receiver. Each device needs a next step, but the strongest neighbour now may fail after rain or battery loss. The route must change without forming a loop or hiding lost data.

Internet Protocol means the addressing rules used to move network packets. IPv6 means version 6 of those rules. Routing Protocol for Low-Power and Lossy Networks (RPL) means rules for choosing paths in such a network. A directed acyclic graph means one-way paths without a loop back to the start. A destination-oriented version leads toward one root and is called a DODAG. Telemetry means readings and status sent by a remote device.

Let one sensor choose a parent. Then weaken that parent, remove it, repeat a reading, restore it, and restart the sensor. Record each choice, delay, loss, and result at the root. A map must show no path when none exists.

This runway does not prove the best parent rule or network scale. The deeper sections explain announcements, rank, joining, repair, and the evidence needed to accept the graph.

A DODAG starts to form when the root announces a graph that other nodes can evaluate. Each node that hears the announcement must decide whether it belongs, how far it is from the root, and which parent makes the graph safer or cheaper to use.

Follow that construction step by step. DIO compatibility, Rank movement, objective function, metric evidence, and loop avoidance all exist to answer one question: can this node join the graph without making the route story less trustworthy?

9.3 Overview: DODAG Construction Builds A Directional Routing Graph

RPL construction is the control-plane process that turns nearby low-power IPv6 nodes into a destination-oriented directed acyclic graph. The root advertises DIO information, each joining node chooses a parent and Rank through an Objective Function, joined nodes advertise onward, and DAO state is added when downward reachability is required.

Read those steps as evidence checkpoints. The root identity and DODAG version define the graph being joined. Candidate-parent records explain why a node accepted one neighbor and rejected another. DAO and packet evidence explain whether the constructed graph supports more than upward telemetry. Without those checkpoints, a neat tree diagram can hide a stale route, a wrong instance, or a missing command path.

Construction also has an order. A node should not be treated as fully reviewable until its DIO context, compatible parent set, resulting Rank, selected parent, and onward advertisement are tied to the same instance and version. If a repair changes that context, the construction evidence has to be refreshed rather than inherited from the old graph.

The final overview claim should name the first packet behavior the graph is expected to support, so the control-plane sequence does not get mistaken for application delivery.

Before applying Overview: DODAG Construction Builds A Directional Routing Graph, examine Figure 9.1 for the concrete parts of the claim. By showing how dODAG construction is a sequence: advertise, evaluate, join, propagate, register reachability, and maintain, the visual exposes what must be recorded rather than merely asserted.

RPL DODAG construction phases from root DIO to first-hop join, multi-hop expansion, DAO reachability, and steady maintenance.
Figure 9.1: DODAG construction is a sequence: advertise, evaluate, join, propagate, register reachability, and maintain.

The useful contrast in Figure 9.1 is between “Root” and “advertises.” Follow it through “DIO” to see how dODAG construction is a sequence: advertise, evaluate, join, propagate, register reachability, and maintain. That relationship is the review point carried into Overview: DODAG Construction Builds A Directional Routing Graph.

Root Advertisement

The DODAG root sends DIO information that names the graph, exposes configuration, and anchors the Rank direction toward the root.

Parent And Rank Choice

A joining node compares compatible parents by resulting Rank and policy evidence, not by radio visibility alone.

Reachability And Repair

DAO state, Trickle timing, and local or wider repair explain how the graph serves traffic after the first join.

The useful mental model is evidence, not animation. A DIO proves discovery. A preferred parent proves a local upward choice. DAO state proves a separate downward-routing claim. Packet tests prove whether the intended traffic direction actually works through the constructed graph.

9.4 Practitioner: Record The Parent Decision, Not Just The Final Tree

The release record should show why a node selected its preferred parent. A final graph can look tidy even when the parent choice is unstable, the Objective Function is misread, or a downward path is missing. The decision record ties each candidate to DIO compatibility, parent Rank, link evidence, local policy, and the traffic direction being claimed.

Include rejected candidates as well as the winner. A rejected parent with strong signal may have incompatible DODAG context, worse resulting Rank, missing mode support, or instability that would not be visible from the final tree alone.

Radio range is not guaranteed to be symmetric. A neighbor can be close enough to receive this node's transmissions clearly while this node's own transmissions arrive at that neighbor too weakly to be usable, or the reverse. Hearing a compatible DIO only proves the outbound half of that path, so a candidate parent's link should be treated as unconfirmed until the reverse direction has been verified, since RPL depends on bidirectional reachability before a neighbor is used for upward forwarding. A candidate that has not cleared that check belongs in the rejected list with that reason attached, not in the preferred-parent slot.

That record becomes operational evidence after deployment. When the selected parent changes, the reviewer can compare the new decision against the earlier candidate list instead of guessing whether the node repaired correctly or drifted into an unsupported route.

Use Figure 9.2 to test the reasoning behind Practitioner: Record The Parent Decision, Not Just The Final Tree. Its labeled path shows how RPL DODAG Rank Assignment, which makes this section’s next operational choice explicit.

Complete DODAG tree with root at RANK 0, all nodes showing calculated RANK values, and parent selection based on lowest RANK path.
Figure 9.2: RPL DODAG Rank Assignment

Read Figure 9.2 through the named checkpoints “Practitioner: Record The Parent Decision, Not Just The Final Tree,” “RPL DODAG Rank Assignment,” and “Nodes select parents with the lowest cumulative RANK to the root.” Their relationship shows how RPL DODAG Rank Assignment; that is the evidence Practitioner: Record The Parent Decision, Not Just The Final Tree needs rather than a topology label alone.

The final tree can also hide an asymmetric link. Open the MIN-T parent-flip preset below and compare both directions of each candidate path. Change only Path B reverse delivery from 0.800 to 0.300: the preferred parent changes because acknowledgements and control traffic must survive the reverse direction too.

Use the selected path and its reciprocal-link ledger as the narrative behind the parent slot. This turns the chapter’s bidirectional-reachability warning into a reproducible parent decision instead of a signal-strength guess.

Record Item
What To Capture
Why It Matters
Candidate parent
DODAG ID, version, compatible DIO, advertised Rank, and neighbor evidence.
Prevents joining a graph or parent that only appears valid from a partial packet capture.
Link direction
Confirmed bidirectional reachability for the candidate, not only a received DIO.
Prevents forwarding through a neighbor that can hear this node but cannot be heard back.
Rank result
Parent Rank plus the link or metric increase used by the Objective Function.
Explains the actual comparison when a low-Rank parent has a weak link or a higher-Rank parent has a better local path.
Stability rule
Tie handling, hysteresis, backup parent, and parent-switch evidence during a test window.
Separates a valid one-time choice from a route that will churn under normal loss or mobility.
Traffic claim
Whether the test proves upward telemetry, downward command, bidirectional exchange, or only control-plane formation.
Keeps DIO discovery, DAO route state, and application packet delivery from being blended into one claim.
Review shortcut: if the record cannot name the selected parent, candidate Rank evidence, and the packet direction under test, the DODAG construction claim is not yet reviewable.

9.5 Under The Hood: DAO, Trickle, And Repair Are Separate Evidence Layers

DODAG formation is not the same as complete route acceptance. DIO evidence says that a node discovered a compatible graph and selected an upward direction. DAO evidence says the network has route state for downward traffic. Trickle evidence explains control-message timing. Repair evidence explains whether a lost parent was handled locally or through wider reconstruction.

That separation matters most during change. A local parent repair can preserve upward telemetry while invalidating old downward route state. A global version change can make the old DIO context irrelevant. A Trickle reset can explain faster control traffic without proving that the application path recovered.

For a fail-closed review, attach each repair event to the evidence it invalidates. Parent state, DAO lifetime, root path knowledge, packet-size behavior, and application packet results may all need different refresh checks after the same topology change.

Under The Hood: DAO, Trickle, And Repair Are Separate Evidence Layers turns on evidence that is easy to blur in prose. Figure 9.3 isolates how the evidence map keeps discovery, parent choice, route state, timing, repair, and packet confirmation as distinct review claims, giving the reader a specific result to check before continuing.

DODAG construction evidence map linking root identity, DIO discovery, Rank calculation, parent choice, DAO reachability, Trickle state, and packet-level confirmation.
Figure 9.3: The evidence map keeps discovery, parent choice, route state, timing, repair, and packet confirmation as distinct review claims.

Locate “Root” in Figure 9.3, then ask how “DODAG ID” changes the claim. “DIO” completes the pictured test: the evidence map keeps discovery, parent choice, route state, timing, repair, and packet confirmation as distinct review claims. The result gives Under The Hood: DAO, Trickle, And Repair Are Separate Evidence Layers an observable meaning.

DIO / DIS Layer

DIO advertises DODAG information. DIS can solicit fresh information when a node needs to discover or recover graph context.

DAO Layer

DAO state is relevant when downward reachability matters. In storing and non-storing designs, the owner of route state differs, so the evidence location differs too.

Repair Layer

Local parent change, Trickle reset, and wider reconstruction are different responses. The review should name which one occurred.

Common failure: accepting a DODAG diagram as proof of application reachability. A diagram can show formation while downlink state, parent stability, or border-router forwarding is still unproven.

A strong final review pairs control-plane captures with route state and packet-level tests. Upward telemetry should show preferred parent forwarding toward the root. Downward commands should show DAO or source-route evidence appropriate to the mode. Repairs should show what changed and when the graph returned to acceptable behavior.

Calculate the parent choice under the stated objective in the diagram Figure 9.4.

RPL parent selection comparing hop-count and ETX costs, with a blocked-link alternative and the monotonic Rank loop rule.
Figure 9.4: RPL parent selection comparing hop-count and ETX costs, with a blocked-link alternative and the monotonic Rank loop rule.

In the diagram Figure 9.4, d chooses B because ETX 1.2 + 1.0 yields 2.2, below C’s 2.9. HOPS, QUALITY, and LOOP RULE show why the same topology can produce different Rank values while still requiring a parent with lower Rank.

Use the diagram Figure 9.5 to separate a graph property from an RPL routing contract.

Generic multi-root directed acyclic graph contrasted with a single-root RPL destination-oriented DAG and increasing Rank.
Figure 9.5: Generic multi-root directed acyclic graph contrasted with a single-root RPL destination-oriented DAG and increasing Rank.

In the diagram Figure 9.5, dAG permits Several roots as long as its edges remain acyclic; DODAG requires One RPL root with root rank 0. DIO advertises the graph while DAO handles downward reach, so neither a tree shape nor Rank alone proves packet delivery.

9.6 Summary

RPL DODAG construction starts when the root advertises graph information and expands as nodes evaluate compatible DIO messages, calculate candidate Rank, choose preferred parents, and advertise onward. DAO state is a separate requirement for downward reachability, and Trickle timing is a maintenance mechanism rather than proof of application success. A strong review records the parent decision, the route-state owner, the traffic direction, and the packet evidence that confirms the claim.

9.7 Key Takeaway

DODAG construction is reviewable only when root identity, DIO discovery, parent and Rank choice, DAO reachability, repair behavior, and packet direction are kept as separate evidence layers.

9.8 See Also