9 How a DODAG Forms

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.

+

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.

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.

+

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.

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.

Use Figure 9.3 to review C’s switch from A to B in the opening example. Keep the same instance and version with the new parent and Rank, then check downward state under the selected mode. Finally, send a command from R to C. The parent switch explains upward repair; the command result checks whether the downward path recovered too.

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.