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: This ordered reading connects the scenario review record discussion to the chapter's running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.
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: This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.
Explain: The scenario contains two different claims.

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.
A protocol means the shared rules for a message exchange.
Telemetry means measurements and status sent for remote use.

Major section

Start With the Scenario Evidence (continued)

RPL means Routing Protocol for Low-Power and Lossy Networks, which builds routes for constrained devices.

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.

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.
This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.

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.

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

This ordered reading connects the scenario review record discussion to the chapter's running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.

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.

RPL means Routing Protocol for Low-Power and Lossy Networks, which builds routes for constrained devices.
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 3

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 because distributing downward routes can reduce root-side source-routing work

BState claim, direction, route-state evidence, open risk, and retest trigger

CSwitch to Non-Storing mode without adding evidence

DUse the Trickle timing record to demonstrate that the selected mode has converged

Show answer

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

Retrieval practice

Recall check 2 of 3

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. What is the strongest review response?

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 3

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

Q3A scenario passed node-to-root telemetry before a firmware update. After the update, the team also claims root-to-node commands are still accepted, but no DAO, route-state, or root-to-node packet evidence was rerun. What is the best review decision?

AAccept all claims because one earlier telemetry path worked.

BIgnore the firmware update because RPL control messages are independent of implementation behavior.

CReject RPL entirely because one downward claim lacks evidence.

DKeep valid upward acceptance; hold downward commands until route-state and packet tests rerun.

Show answer

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

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.