The Repair After a Failed Parent
The Repair After a Failed Parent
Ada re-derives this chapter’s own numbers step by step, at full precision
ADA · CALCULATION AUDIT
The Repair After a Failed Parent
In this worked DODAG, node B starts at Rank 256 and directly parents E and F, both at Rank 512. When B becomes unavailable, the chapter recalculates the affected descendants: E switches to parent A and lands at Rank 640, F switches to C at Rank 768, and H and I follow their repaired parents to Rank 896 and 1024. This audit asks the question that repair invites: do those recalculated Ranks still increase monotonically toward the root so the tree stays loop-free, or does the repair only prove the upward path while leaving downward DAO evidence unrefreshed?
Companion to the chapter Worked Example: Rank and Parent Choice — every number here comes from that chapter.
See the relationship before changing it
The chapter figure below shows: The example topology gives each node a small set of candidate parents and link-cost labels for hand calculation.
The retained audit below checks several chapter fixtures. This model keeps those stated values fixed and changes only e-to-parent link cost, so the numeric fixture does not switch without explanation.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 1.5 ETX.
- 2
Name the relationship. rank = parent rank 256 + 256 x link cost
- 3
Substitute with units. 256 + 256 x 1.5 = 640 rank
- 4
Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.
Predict, then change e-to-parent link cost
Try Predict the direction of rank = parent rank 256 + 256 x link cost. Test another e-to-parent link cost, then compare repaired e rank.
Observe A costlier repaired link raises the child rank while it must remain above the parent. Reset e-to-parent link cost to 1.5 and compare repaired e rank.
Explain The node adds a scaled local link cost to its parent's advertised rank, so a worse parent link increases the repaired rank linearly.
Check yourself
What should you do before trusting a moved-control result?
What does this small model leave out?
After parent B fails, assign E to A at cost 1.5 and F to C at cost 1.5; run Check audit on the new Ranks.
The repaired state displays E = 640, F = 768, H = 896, and I = 1024, each strictly above its parent.
Strictly increasing Rank, such as 896 above 640, prevents a child choosing its descendant but does not refresh downward DAO routes.
Ada: The forward pass in this chapter is clean, so let me audit the harder claim: after parent B fails, the recalculated Ranks are E = 640, F = 768, H = 896, I = 1024, and the repaired tree is “worse but still loop-avoiding.” Every value uses candidate_rank = parent_rank + round(256 x link_cost), and here all link costs are multiples of 0.5, so the rounding is exact – no precision is lost.
Recomputing the affected descendants:
- E drops B and takes A (link cost 1.5):
256 + round(256 x 1.5) = 256 + 384 = 640. - F drops B and takes C (cost 1.5):
384 + round(256 x 1.5) = 384 + 384 = 768. - H keeps E (cost 1.0), now through E’s new Rank 640:
640 + round(256 x 1.0) = 640 + 256 = 896. - I keeps F (cost 1.0), now through F’s new Rank 768:
768 + round(256 x 1.0) = 768 + 256 = 1024.
Loop-avoidance check – each child’s Rank must strictly exceed its parent’s: 640 > 256 (E over A), 768 > 384 (F over C), 896 > 640 (H over E), 1024 > 768 (I over F). All four increase toward the root, so no child can select one of its own descendants as parent.
The audit confirms the separation the chapter keeps: these repaired Ranks prove the upward tree is still loop-free and monotonic, but every one of them is an upward number – none refreshes the DAO route state a root-to-leaf command would still need.
Every number above is taken from the chapter’s own material and re-derived step by step.
Technical boundaries: The repair ledger excludes DIO and DAO timing, hysteresis, link-quality changes, packet loss, local-repair races, storing-mode capacity, and propagation of downward routes.