Routing & RPL · Study deck

RPL Production Case Studies

Picture a dry-bed alarm travelling from a field sensor to a control room while a reset command must travel back.

Packet Pete is your guide for this deck.

productionscenariosrouting-modes

Packet Pete, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: 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.
Explain: A warehouse sensor, streetlight controller, or field gateway may each need a different balance of repair speed, memory, command reachability, and battery life.
Explain: The preferred-parent output must be checked against advertised Rank and the chosen metric, then verified with packet delivery on the required path.
Explain: It should say which claim is accepted, which claim is still unproven, and what evidence would change the decision.

Major section

Start With the Scenario Evidence

A tidy route picture can hide a one-way failure.

The scenario must name what proves both paths under stress.
A gateway means a device or service that joins two system paths.
RPL means Routing Protocol for Low-Power and Lossy Networks, which builds routes for constrained devices.
Telemetry means measurements and status sent for remote use.

Major section

Start With the Scenario Evidence (continued)

This runway does not prove that one route mode fits every deployment.

The deeper scenarios compare route state, objective choices, repair speed, memory, battery cost, and the retest trigger for each operating need.
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.

Major section

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.

Major section

Minimum Viable Understanding

A scenario is not accepted until the claim is testable.

Upward and downward paths need separate evidence.
Mode choice is about route-state placement, not a generic network-size rule.
Objective Function choice is about the metric evidence the deployment can observe.
Control-plane evidence supports routing claims but does not replace packet tests.

Major section

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 showing upward telemetry evidence, downward command evidence, route-state location, and accepted versus unproven claims.

Major section

Scenario 2: Objective Function Under Variable Links

MRHOF-style reasoning may prefer a path with stronger link-quality evidence and hysteresis.

The scenario needs to show the metric evidence, not just the chosen parent.
For ETX, forward and reverse delivery ratios combine as ETX = 1/(Df × Dr), so either direction can make a link expensive.
The preferred-parent output must be checked against advertised Rank and the chosen metric, then verified with packet delivery on the required path.
A link-quality change should trigger a bounded switch rather than oscillation.

Major section

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.
The maintenance change in the RPL scenario retest record showing an old acceptance boundary, maintenance change, affected claim, new control and packet evidence, and the updated acceptance decision diagram identifies which old acceptance boundary must be reopened.
Retest the affected direction after the change and compare its packet evidence with the earlier accepted boundary.

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

Major section

Scenario Review Record

A later troubleshooter can use the named retest trigger without treating a pending traffic path as accepted.

The handoff should retain the pending direction, its owner, and the precise event that starts another packet test.
A later reviewer can see why the decision was made and which claim was intentionally left unproven.
The handoff in the 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 diagram separates accepted and pending claims alongside mode, Objective Function, control, and packet evidence.
This record is short, but it prevents future confusion.

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.

Major section

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.
A useful scenario answer records accepted claims, missing evidence, and retest triggers.

Deck summary

Key takeaways

A tidy route picture can hide a one-way failure.

This runway does not prove that one route mode fits every deployment.
RPL production scenarios are useful only when they train evidence discipline.
A scenario is not accepted until the claim is testable.
Claim: "Nodes report telemetry to the root, and the root can occasionally send commands back to nodes.".

Retrieval practice

Recall check 1 of 4

Packet Pete says: answer from memory, then check your reasoning.

Q1A scenario answer says "use Storing mode" without naming traffic direction or route-state evidence. What is the best fix?

AKeep Storing mode based on its root-side source-routing advantage alone.

BState traffic direction, route-state proof, and open risk.

CSwitch mode because the new route organization will fit memory and deliver downward packets.

DUse quiet Trickle timing as proof of the chosen mode's route state.

Show answer

Answer: B RPL production scenarios should distinguish accepted, unproven, and change-sensitive claims.

Retrieval practice

Recall check 2 of 4

Packet Pete says: answer from memory, then check your reasoning.

Q2A scenario shows successful node-to-root telemetry packets and a DODAG diagram. The answer says root-to-node commands are also accepted. How should reviewers handle the root-to-node command claim?

AAccept the command claim because RPL paths are bidirectional by default

BAccept the command claim if the node has lower Rank than its children

CHold downward commands until route-state evidence and root-to-node tests are shown

DAccept the command claim if Trickle has reached a quiet interval

Show answer

Answer: C Scenario review must keep traffic directions separate.

Retrieval practice

Recall check 3 of 4

Packet Pete says: answer from memory, then check your reasoning.

Q3Which parts of the RPL claim can remain approved after the update?

AAccept commands from earlier upward telemetry even after firmware changes.

BIgnore firmware changes because RPL behavior cannot change with code.

CReject all RPL traffic because one downward claim lacks evidence.

DKeep upward approval; hold commands pending new route and packet tests.

Show answer

Answer: D Scenario review separates accepted claims, unproven claims, and retest triggers instead of promoting one successful path to every traffic direction.

Retrieval practice

Recall check 4 of 4

Packet Pete says: answer from memory, then check your reasoning.

Q4After a routing inconsistency, the Trickle timer settles and DIO traffic becomes quiet. Can a root-to-node command claim stay accepted without another test?

ANo; retest mode-specific route state and command packets after repair.

BYes; a quiet Trickle timer proves command packets arrived.

CYes; the old route snapshot remains valid through every repair.

DNo; repeat DIO timing alone and leave command delivery untested.

Show answer

Answer: A A timer result has a narrow scope; changed route conditions reopen the affected packet claim.

Print reference

Answers

Answer key.

B · RPL production scenarios should distinguish accepted, unproven, and change-sensitive claims.
C · Scenario review must keep traffic directions separate.
D · Scenario review separates accepted claims, unproven claims, and retest triggers instead of promoting one successful path to every traffic direction.
A · A timer result has a narrow scope; changed route conditions reopen the affected packet claim.