18 Worked Example: Rank and Parent Choice
RPL DODAG worked example, RPL Rank calculation, RPL parent selection example, DODAG DAO example, RPL ETX example
18.1 Start With the Node That Must Join
A worked DODAG example becomes real when one node has to join a network already in motion. It hears candidate parents, compares Rank and metrics, avoids loops, and chooses a place in the graph that affects every later packet.
Work the example from that node outward. The important result is not only the final diagram, but the evidence trail: why one parent was selected, why another was rejected, and how the resulting path supports the traffic direction being tested.
Overview: Parent Choice Is a Calculation, Not a Guess
This worked example follows a small RPL DODAG from root advertisement to final preferred parents. The arithmetic is intentionally simple: each node calculates a candidate Rank through every usable parent, compares the results, and selects the lowest valid candidate Rank under the stated teaching model.
The goal is not to memorize these numbers. The goal is to keep four ideas separate: candidate Rank, selected preferred parent, alternate-parent evidence, and DAO evidence for downward reachability.
A worked example is useful only when the assumptions are visible. This one treats the root as Rank 0, uses a fixed step, and rounds a simple link-cost contribution. A real Objective Function can add constraints, hysteresis, energy, latency, or implementation policy. The example therefore proves the arithmetic under the stated model, not a universal production choice.
Use the same caution with traffic direction. A final parent tree explains upward forwarding toward the root. It does not prove that the root has current state for every leaf, that source-route headers fit every command packet, or that a repaired path still carries the application after a parent changes.
For learners, the value is auditability. Every selected parent can be traced to a candidate calculation, every alternate can be checked against the same rule, and every unsupported delivery claim is held outside the worked example until separate route-state and packet records are added.
The final answer should therefore say what was calculated, what was assumed, and what still needs evidence before deployment.
Rank
Rank is a scalar value that represents position in the DODAG according to the Objective Function. In this example, lower Rank is better and paths move upward toward lower Rank.
Preferred Parent
The preferred parent is the selected upward next hop. It should be justified from candidate calculations, not from hop count or diagram position alone.
DAO Evidence
DAO evidence is separate from the parent tree. A parent choice supports upward forwarding; it does not by itself prove that the root can send downward commands.
Teaching Model
The root starts at Rank 0. The rank step is 256. Candidate Rank is calculated from parent Rank plus a rounded link-cost increase.
A production Objective Function may add policy, hysteresis, constraints, metric containers, or implementation-specific behavior. This chapter uses the simplified model only to make the review arithmetic visible.
Practitioner: Calculate Every Candidate Before Choosing
Start from the root, then work outward. First-hop nodes calculate directly through the root. Second-hop and leaf nodes compare every compatible parent candidate. The chosen parent is the candidate with the lowest valid resulting Rank in this simplified model.
Do the same calculation for candidates that lose. Rejected alternatives explain why the final DODAG is defensible and make later repair review possible. If a selected parent fails, the old rejected-candidate record tells the reviewer whether the fallback was compatible, merely visible, or never acceptable under the model.
Keep arithmetic and policy separate in the worksheet. If two candidates tie, the calculation has not selected a parent; the reviewer still needs a tie-break, hysteresis, implementation rule, or stability observation before accepting the final choice.
For each node, preserve the candidate list beside the final parent so another reviewer can recalculate the path after a root, metric, or link-cost change.
Keep units visible so link cost, Rank, and packet evidence are not mixed.
First-Hop Nodes
Second-Hop Choice
D hears only A, so D selects A at Rank 512. E compares A and B. F compares B and C. The resulting Rank, not the diagram distance alone, determines the preferred parent.
Leaf Choice
Boundary Check
A worked example can list an alternate candidate, but it should not call that candidate a tested backup unless trace data, route state, or implementation behavior proves the alternate is retained and usable.
Under the Hood: Parent Trees and Downward Routes Are Different Evidence
The final parent choices create an upward structure toward the root. That structure is useful, but it proves only the parent relationship under the stated assumptions. Downward traffic needs additional evidence because RPL can use different route-state behavior depending on mode and implementation.
The under-the-hood review should preserve the transition from arithmetic to state. Candidate Rank explains why a node selected a parent; DAO or route tables explain whether a downward destination is known; a packet test explains whether the application flow actually crossed the repaired or steady path.
When a parent fails, rerun the same separation. Recalculated Rank can show a loop-avoiding upward repair, while old DAO evidence may still be invalid for root-to-leaf commands until the selected mode refreshes route state.
Final Parent Set
Failure Repair Walkthrough
If B becomes unavailable and the remaining candidate evidence is still valid, affected descendants need fresh calculations. E can use A at Rank 640. F can use C at Rank 768. H through E becomes Rank 896. I through F becomes Rank 1024. The repaired DODAG is worse under the example metric, but it can still be loop-avoiding if each parent choice remains valid and Rank still progresses toward the root.
Upward Claim
Supported by preferred-parent state, Rank progression, and packet or route-table evidence showing traffic moving toward the root.
Downward Claim
Needs DAO or route-state evidence. Storing and Non-Storing behavior require different proof because the route knowledge lives in different places.
Repair Claim
Needs recalculated Rank values, current parent state, and refreshed downward-route evidence if commands or root-originated traffic are in scope.
18.2 Summary
- This example uses a simplified Rank model so each parent decision can be checked by hand.
- Parent choice compares resulting candidate Rank, not hop count alone and not local link quality alone.
- The final parent tree supports upward path reasoning, but downward reachability needs DAO or route-state evidence.
- Repair after a failed parent requires recalculating affected descendants and refreshing the evidence behind any downward-route claim.
18.3 Key Takeaway
A worked RPL DODAG example is reviewable when it states the model, calculates every candidate parent, names the selected parent, and keeps upward, downward, and repair evidence separate.