24  RPL Production Case Studies

routing
rpl
iot
Keywords

RPL production scenarios, RPL scenario review, RPL mode selection evidence, RPL Objective Function evidence, RPL retest triggers

24.1 Start With the Scenario Evidence

A production scenario is useful only when it names the evidence that would make the routing decision acceptable. A warehouse sensor, streetlight controller, or field gateway may each need a different balance of repair speed, memory, command reachability, and battery life.

Start by writing the evidence requirement next to the scenario. Then the route mode, objective function, packet test, and retest trigger can be judged against the operating need instead of against a generic RPL preference.

24.2 In 60 Seconds

RPL production scenarios are useful only when they train evidence discipline. Each scenario should begin with a claim, identify the traffic direction, state the route-state assumption, name the Objective Function evidence, and then decide which packet tests are required. A scenario answer should not say “use Storing” or “use Non-Storing” as a slogan. It should say which claim is accepted, which claim is still unproven, and what evidence would change the decision.

24.3 Learning Objectives

By the end of this chapter, you will be able to:

  • Review an RPL scenario without importing unsupported deployment claims.
  • Separate upward telemetry acceptance from downward command acceptance.
  • Use route-state evidence to defend Storing or Non-Storing mode.
  • Use metric evidence to defend Objective Function choice.
  • Decide when local repair, Trickle behavior, or route-state changes require retesting.
  • Write a scenario review record that is useful for later troubleshooting.

24.4 Minimum Viable Understanding

  1. A scenario is not accepted until the claim is testable.
  2. Upward and downward paths need separate evidence.
  3. Mode choice is about route-state placement, not a generic network-size rule.
  4. Objective Function choice is about the metric evidence the deployment can observe.
  5. Control-plane evidence supports routing claims but does not replace packet tests.
  6. Scenario records should state what remains unproven.

24.5 Prerequisites

24.6 How To Read A Scenario

Read every scenario in this order:

  1. State the traffic claim.
  2. Identify the RPL context, root, and DODAG evidence.
  3. Separate upward, downward, and peer traffic.
  4. Decide where route state is expected to live.
  5. Check the Objective Function evidence.
  6. Match control-plane evidence to the claim.
  7. Require packet tests for the accepted path.
  8. Record what would require retest.

If a scenario gives a design decision but no packet evidence, the decision is still a hypothesis. If a scenario gives packet evidence but no routing-mode context, the result may not generalize to the next change.

24.7 Scenario 1: Telemetry With Occasional Commands

Claim: “Nodes report telemetry to the root, and the root can occasionally send commands back to nodes.”

The scenario contains two different claims. Telemetry is upward. Commands are downward. A clean review accepts or rejects each claim separately.

RPL scenario mode record shows upward telemetry evidence, downward command evidence, route-state location, and accepted versus unproven claims.
Figure 24.1: RPL scenario mode record showing upward telemetry evidence, downward command evidence, route-state location, and accepted versus unproven claims.

Review the scenario like this:

  • Upward telemetry needs DIO evidence, parent choice, Rank context, Objective Function context, and node-to-root packet results.
  • Downward commands need routing-mode context, DAO or route-state evidence, root-to-node packet results, and retest triggers.
  • Storing mode can be accepted only if intermediate route-state behavior is inspected or tested.
  • Non-Storing mode can be accepted only if root-held route knowledge and source-route behavior are tested.
  • A successful upward packet does not prove a downward command path.

Scenario decision: accept the upward telemetry claim if the node-to-root packet tests pass. Hold the downward-command claim open until the route-state evidence and root-to-node packet tests are present.

24.9 Scenario 3: Maintenance Change And Retest

Claim: “The RPL design was accepted earlier, so the same acceptance still applies after a local change.”

This claim is often wrong. A previous acceptance record can expire when the design, topology, traffic direction, firmware, root, routing mode, or Objective Function changes.

RPL scenario retest record links an old acceptance boundary, maintenance change, affected claim, new control and packet evidence, and the updated acceptance decision.
Figure 24.3: RPL scenario retest record showing an old acceptance boundary, maintenance change, affected claim, new control and packet evidence, and the updated acceptance decision.

Review the change like this:

  • Identify which old claim the change affects.
  • Decide whether the change touches parent choice, route-state location, control messages, packet direction, or monitoring.
  • Reuse old evidence only if it still proves the current claim.
  • Capture new control-plane evidence when the DODAG, Rank, DAO behavior, or Trickle behavior changes.
  • Run new packet tests for every traffic direction affected by the change.

Scenario decision: do not accept the old record wholesale. Keep the unaffected claims, retest the affected claims, and update the monitoring or retest trigger list.

24.10 Scenario Review Record

A useful scenario answer should look like this:

  • Claim accepted: the exact traffic path and RPL context that passed.
  • Claim not yet accepted: the traffic path or behavior that lacks evidence.
  • Mode evidence: where route state lives and how it was observed.
  • Objective Function evidence: what metric or rule selected the parent.
  • Control evidence: the messages and Rank context that support the claim.
  • Packet evidence: the tested source, destination, and direction.
  • Retest trigger: the change that would require fresh evidence.
RPL production scenario handoff record shows accepted claim, pending claim, mode and Objective Function evidence, control evidence, packet evidence, and retest trigger for later troubleshooting.
Figure 24.4: RPL production scenario handoff record showing accepted claim, pending claim, mode and Objective Function evidence, control evidence, packet evidence, and retest trigger for later troubleshooting.

This record is short, but it prevents future confusion. A later reviewer can see why the decision was made and which claim was intentionally left unproven.

24.11 Review Checklist

Before accepting a scenario answer, ask:

  • Did it state the traffic direction?
  • Did it identify the routing mode and route-state location?
  • Did it name the Objective Function evidence?
  • Did it avoid using a DODAG picture as packet proof?
  • Did it separate DIO discovery from DAO route-state evidence?
  • Did it require packet tests for downward or peer traffic?
  • Did it state which claim remains unproven?
  • Did it define retest triggers for changes that affect the claim?

24.12 Common Mistakes

  • Answering with a mode name but no route-state evidence.
  • Accepting downward commands because upward telemetry worked.
  • Treating a preferred parent as “best” without naming the Objective Function.
  • Treating Trickle reset behavior as a complete health check.
  • Reusing an old acceptance record after the traffic direction changes.
  • Adding exact capacity, timing, device-life, or product claims that the scenario did not measure.

24.13 Knowledge Check

24.14 Matching Quiz

24.15 Ordering Quiz

Overview: Scenarios Are Claim Tests

A production scenario is not a story with one correct routing slogan. It is a test of which claim the evidence can support. The same scenario can contain an accepted upward telemetry claim, an unproven downward command claim, and a retest trigger that affects only one part of the design.

Read each case as a set of claim boundaries. The reviewer should ask what traffic direction is being accepted, where route state lives, which Objective Function evidence selected the path, which packet test matches the claim, and what changed since the last acceptance record.

The handoff matters because scenario answers often mix several claims in one paragraph. A telemetry path may be accepted, a command path may be pending, and a maintenance change may require only one fresh packet test. If the answer says only "scenario passed," the next reviewer cannot tell which part passed and which part was never proven.

Use the scenario as a sorting exercise. Accepted claims move to monitoring: what signal should be watched so the team notices when the accepted condition changes? Missing evidence moves to the next chapter or next lab: what trace, route-state record, or packet test would close the gap? Retest triggers move to change control: what future event makes the old answer stale?

This does not make the review slower. It makes the decision narrower and more reusable. A narrow accepted claim can be trusted later because it names its traffic direction, context, evidence, and expiry condition. It also makes rejected or pending claims easier to finish.

Accepted Claim

The exact traffic direction, RPL context, and operating condition that passed both control-plane and packet checks.

Unproven Claim

A plausible behavior that the current evidence does not prove, such as downward commands after only upward telemetry tests.

Changed Assumption

A firmware, topology, route-state, root, metric, or traffic change that can narrow or expire old evidence.

Retest Decision

The reviewer keeps unaffected claims and reruns the tests for only the claims touched by the change.

Scenario rule:

Write the answer as "accepted, unproven, retest" rather than "choose mode X." That form prevents one clean trace from becoming an unsupported production promise.

Practitioner: Write The Scenario Decision Record

The decision record turns a scenario answer into something a maintainer can use later. It should explain why the decision was made, which evidence was attached, and what would force the team to revisit the scenario after a change.

Start by writing the scenario as a table of claims rather than as a paragraph of recommendations. One row can cover upward telemetry, another can cover root-to-node command delivery, and another can cover repair behavior after a parent change. Each row gets its own mode evidence, Objective Function evidence, control-plane evidence, packet evidence, open gap, and retest trigger.

When evidence is missing, write that fact in the row instead of softening the conclusion. "Downward command pending DAO and root-to-node packet test" is a stronger review result than "commands probably work." It tells the next person exactly what to collect and prevents the scenario answer from becoming a production promise. It also keeps a partial pass useful: the accepted telemetry row remains accepted while the command row stays pending.

Question
Record The Answer
Evidence To Attach
Common Failure
What is accepted?
Name the specific traffic direction, endpoints, mode, Objective Function, and test condition.
Packet result, DODAG context, parent state, route-state evidence, and firmware or configuration identifier.
The record says "scenario passed" without naming the accepted path.
What is not accepted?
Name the direction or behavior that still lacks evidence, even if it sounds likely.
Missing DAO, absent route table, no root-to-node packet result, or no peer-path proof.
Upward success is reused as proof for downward or peer traffic.
What changed?
Identify the topology, firmware, root, Objective Function, traffic profile, radio condition, or maintenance action.
Change ticket, before/after configuration, trace metadata, and affected node set.
The team assumes a previous acceptance record still covers a different operating state.
What gets retested?
Map each affected claim to a fresh control-plane check and packet test.
Rerun output, packet capture, route-state snapshot, and updated monitoring trigger.
Every test is rerun blindly, or no test is rerun because one old result was clean.
1. Split the scenario.

Separate upward telemetry, downward commands, peer traffic, repair behavior, and monitoring promises.

2. Match evidence.

Pair each claim with the specific control-plane and packet evidence that can prove it.

3. Mark gaps.

Write unproven claims explicitly so a later reviewer does not infer more than the test showed.

4. Set retests.

Connect each change trigger to the smallest fresh test that can re-accept the affected claim.

Under the Hood: A Passed Path Can Hide A Failed Claim

RPL evidence is directional and context-bound. A node-to-root packet can pass while the root has no valid route-state evidence for commands. A parent can remain stable during a short test while an Objective Function would flap under a different ETX range. A Trickle interval can look quiet while stale downward state remains untested.

The technical reason is that each RPL signal answers a narrow question. DIO supports DODAG and parent context. DAO supports downward route-state review. Rank supports loop-aware direction in the context of the Objective Function. Packet tests prove only the source, destination, direction, size, security overhead, and timing that were actually exercised.

The hidden failure is usually not that the visible evidence is wrong. It is that the evidence was asked to prove too much. A successful telemetry packet can truthfully prove that one node reached the root, while still saying nothing about root-held source routes, intermediate route tables, or peer traffic. A stable parent trace can truthfully prove one observation window, while saying little about a new interference pattern or firmware change.

That is why production scenarios should be reviewed by claim width. A narrow claim can survive later comparison because the reviewer knows exactly what was tested. A broad claim breaks down during troubleshooting because nobody knows whether the failure contradicts the old evidence or exposes a path that was never tested. Splitting the claim before changing the design keeps the diagnosis technical instead of argumentative.

The under-the-hood discipline is to map every signal to the RPL state it can actually support. DIO belongs to discovery and parent context, DAO belongs to downward reachability, Objective Function evidence belongs to parent selection, and packet evidence belongs to the exercised path. If a scenario answer crosses those boundaries, mark the crossed claim as pending.

Direction Mismatch

Upward delivery does not prove root-to-node commands, and a downward command test does not prove peer traffic.

Metric Mismatch

A preferred parent is only as defensible as the metric evidence and stability rule used to select it.

Time Mismatch

A short acceptance window can miss repairs, parent churn, queue buildup, or Trickle behavior after inconsistency.

Scope Mismatch

Evidence from one firmware, root, channel plan, or topology should not be promoted to every deployment state.

Failure analysis rule:

When a scenario feels contradictory, split the claim before changing the design. Often one claim passed, another was never tested, and the missing evidence is the real issue.

24.16 Summary

  • Scenario review starts with a testable claim.
  • Upward, downward, and peer traffic require separate evidence.
  • Mode choice must be defended with route-state evidence.
  • Objective Function choice must be defended with metric and stability evidence.
  • Control-plane evidence and packet evidence prove different things.
  • A useful scenario answer records accepted claims, missing evidence, and retest triggers.

24.17 Key Takeaway

Production RPL scenarios should reveal how link loss, parent churn, traffic direction, gateway placement, and maintenance access affect the design.

24.18 Concept Relationships

24.19 What’s Next

Continue to RPL Production Summary for a compact production review synthesis, or return to RPL Production Framework if the evidence stack needs another pass.