Root Advertisement
The DODAG root sends DIO information that names the graph, exposes configuration, and anchors the Rank direction toward the root.
16 How a DODAG Forms
routing
rpl
iot
Keywords
RPL DODAG construction, DIO propagation, DAO reachability, RPL parent selection, RPL Rank calculation, Trickle maintenance
16.1 Start With the Root Announcement
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?
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.
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.
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.
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.
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.
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.
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.
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.
16.2 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.
16.3 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.