11 Worked Example: Rank and Parent Choice
A new low-power node hears advertisements from two possible RPL parents and must choose a route toward the root. Rank prevents movement away from the root, while the objective function combines link evidence into a preference. The choice should be calculable from the values the node actually observed.
11.1 Calculate the Parent Before Drawing the Tree
Read Figure 11.1 from the root down to the candidate parents and joining node. Mark every labelled rank and link cost. Figure 11.2 then places those values in the comparison: candidate path cost equals the parent’s advertised cost or rank contribution plus the joining link metric under the teaching objective function.
Figure 11.3 broadens the result into formation. Follow the root’s DIO outward, parent selection at listening nodes, increasing rank away from the root, and DAO information used for downward reachability where the mode requires it. The direction of rank is a loop-avoidance constraint, not a geographic distance.
Use two candidates for node N. Parent A has path cost 40 and N measures link cost 18 to A, giving (40+18=58). Parent B has path cost 32 but link cost 31, giving (32+31=63). Under this additive example, N selects A because 58 is lower than 63. The apparently better upstream cost at B is outweighed by N’s weaker local link.
Add a hysteresis margin of 8 cost units for stability. If N currently uses A at 58 and a new measurement puts B at 54, the improvement is only 4, so N stays with A. If B later reaches 49, the improvement is 9 and crosses the margin, so a switch is allowed. State the exact objective function and policy because real RPL implementations may encode rank and metrics differently.
After choosing A, N advertises a rank that is greater than A’s according to the configured minimum increment and objective function. It must reject a neighbour whose advertised relation would violate the upward direction. Store candidate values, selected parent, previous parent, hysteresis decision, and time so route movement can be explained.
Predict the worked trace. With costs 58 and 63, expect A. Change B to 54 and expect no switch under margin 8. Change B to 49 and expect a permitted switch. Remove both parents and expect N to show no route rather than retaining an unverified path. Compare the node log with the hand arithmetic at every step.
11.2 Start With the Node That Must Join
Watch One Node Join, Fail, and Rejoin
Picture a vineyard node choosing between two neighbours before sending a frost warning. The route with the lower rank may change after a weak link or restart, so the final receiver result must stay attached to the route evidence.
RPL means the routing method used by low-power and lossy device networks. A DODAG means the root-oriented, loop-free route shape that its nodes build. Latency means the elapsed time from a stated start event to a stated finish event.
Record the node, root, candidate parents, chosen parent, join time, and warning result. Weaken one link, remove the parent, repeat the warning, and restart the node. Show no-path truth when no safe route exists.
This runway does not predict every field route or delay. The worked sections explain rank, parent choice, repair, route direction, and the calculations behind this bounded example.
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.
11.3 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.
To make Overview: Parent Choice Is a Calculation, Not a Guess reviewable, pause at Figure 11.1. It lays out how the example topology gives each node a small set of candidate parents and link-cost labels for hand calculation, so the next decision can be tied to an observable state or transition. This diagram tests Overview: Parent Choice Is a Calculation, Not a Guess.
Before accepting the overview: parent choice is a calculation, not a guess claim, examine Figure 11.1 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.
In Figure 11.1, the visual shows example RPL topology with one root, first-hop nodes A B C, second-hop nodes D E F, and leaf nodes G H I with link costs. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the overview: parent choice is a calculation, not a guess discussion to the chapter’s running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.
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.
11.3.1 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.
11.4 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.
11.4.1 First-Hop Nodes
11.4.2 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.
Before accepting the second-hop choice claim, examine Figure 11.2 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.
In Figure 11.2, the visual shows candidate parent comparison for E and F showing resulting Rank values through alternate parents. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the second-hop choice discussion to the chapter’s running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.
11.4.3 Leaf Choice
11.4.4 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.
11.5 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.
Before accepting the under the hood: parent trees and downward routes are different evidence claim, examine Figure 11.3 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.
In Figure 11.3, the visual shows rPL DODAG formation: the root advertises Rank 0 and nodes at increasing ranks of 256, 512, and 768 build the graph, with downward DIO messages carrying the DODAG ID, version, rank, and objective function so nodes compute their. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the under the hood: parent trees and downward routes are different evidence discussion to the chapter’s running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.
11.5.1 Final Parent Set
11.5.2 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.
11.6 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.
11.7 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.