11 Worked Example: Rank and Parent Choice

11.1 Calculate the Parent Before Drawing the Tree

This section: Calculate the Parent Before Drawing the Tree — Read Figure 11.1 from the root down to the candidate parents and joining node.

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

This section: Start With the Node That Must Join — Picture a vineyard node choosing between two neighbours before sending a frost warning.

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 worksheet starts at a zero offset and adds round(256 x link_cost) for each link; an actual RPL root does not advertise Rank 0. 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.

+

The link costs in Figure 11.1 let the second-hop nodes compare candidate paths to the root instead of choosing a parent by position. Calculate each candidate total and record the chosen parent before sending a packet from the second hop to the root.

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. For E or F, add each candidate link cost to the advertised parent Rank before testing the chosen forwarding path.

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

This worksheet starts its arithmetic at zero and adds round(256 x link_cost) at each step. Its displayed values are offsets, not advertised RPL Rank. With the RFC default MinHopRankIncrease of 256, a real DODAG root advertises Rank 256.

candidate_offset = parent_offset + round(256 x link_cost)

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

This section: Practitioner: Calculate Every Candidate Before Choosing — Start from the root, then work outward.

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.2 Second-Hop Choice

D hears only A, so D selects A at offset 512. E compares A and B. F compares B and C. The resulting Rank, not the diagram distance alone, determines the preferred parent.

The alternate Rank totals for E and F in Figure 11.2 expose which candidate parent gives the lower resulting Rank. The arithmetic selects a candidate; a later link failure requires E or F to recalculate and demonstrate a working replacement path.

+

In Figure 11.2, the visual shows candidate parent comparison for E and F showing resulting Rank values through alternate parents. A lower calculated Rank supports the choice, but the selected parent and forwarded packet still need to agree. The parent comparison is complete only after E and F send through the selected parents and the record names what would trigger recalculation.

Node

Candidate

Calculation

Decision

D

A only

256 + round(256 x 1.0) = 512

Select A

E

A or B

A gives 640; B gives 512

Select B

F

B or C

B gives 512; C gives 768

Select B

11.5 Under the Hood: Parent Trees and Downward Routes Are Different Evidence

This section: Under the Hood: Parent Trees and Downward Routes Are Different Evidence — The final parent choices create an upward structure toward the root.

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.

The DIO fields and Rank offsets in Figure 11.3 describe an upward parent tree, not a proven downward route. A downward test needs DAO-derived state and a packet from the root to the child, not the Rank diagram alone.

+

In Figure 11.3, the diagram shows zero-based teaching offsets of 0, 256, 512, and 768. With the RFC default MinHopRankIncrease of 256, an actual DODAG root advertises Rank 256. DIOs carry the DODAG ID, version, and Rank; the DODAG Configuration option identifies the Objective Function used to compute Rank. The teaching offsets begin at zero; with the default MinHopRankIncrease, the actual root advertises Rank 256, and DAO evidence is needed for downward reachability.

11.6 Summary

This section: 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

This section: Key Takeaway

11.8 See Also

This section: See Also