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

foundations
math-foundations
calculation-audit
routing-rpl
Ada 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 figure reads from left to right. The blue card is e-to-parent link cost. The middle card applies this page's rule. The green card is repaired e rank. Walk the arrows once: set the input, apply the rule, then read the result with its unit.

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.

E-to-parent link cost changes repaired e rank An input card leads through the rule rank = parent rank 256 + 256 x link cost to the repaired e rank result. INPUT PAGE INPUT APPLY THE RULE predict calculate check units OUTPUT RESULT
Walk the arrows. A costlier repaired link raises the child rank while it must remain above the parent.

Derive the baseline in four named moves

  1. 1

    Name the input. The chapter baseline is 1.5 ETX.

  2. 2

    Name the relationship. rank = parent rank 256 + 256 x link cost

  3. 3

    Substitute with units. 256 + 256 x 1.5 = 640 rank

  4. 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.

1.5 ETX
Chapter baseline
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 A costlier repaired link raises the child rank while it must remain above the parent.

Check yourself

What should you do before trusting a moved-control result?
Answer: Predict its direction, apply the shown relationship, keep the units, and reset to the worked baseline.
What does this small model leave out?
Answer: Only e-to-parent link cost moves here. Field effects named in the technical boundary stay fixed.
Try

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.

Observe

The repaired state displays E = 640, F = 768, H = 896, and I = 1024, each strictly above its parent.

Explain

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.

Ready: work the ledger before checking it.