Root Advertisement
The DODAG root sends DIO information that names the graph, exposes configuration, and anchors the Rank direction toward the root.
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.
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.
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?
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 DODAG root sends DIO information that names the graph, exposes configuration, and anchors the Rank direction toward the root.
A joining node compares compatible parents by resulting Rank and policy evidence, not by radio visibility alone.
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.
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.
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.
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 advertises DODAG information. DIS can solicit fresh information when a node needs to discover or recover graph context.
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.
Local parent change, Trickle reset, and wider reconstruction are different responses. The review should name which one occurred.
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.
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.
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.
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.
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.