Routing & RPL · Study deck

Storing vs Non-Storing Modes

Picture a control room sending a valve command down through a small field network.

Packet Pete is your guide for this deck.

routing-modesstoring-modenon-storing-mode

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

After studying this chapter

Learning objectives

You will be able to:

explain where downward route state lives in Storing versus Non-Storing mode
write a mode choice as an evidence record, not a default setting
use DAO and packet evidence to support a mode-choice claim
Explain: Sensor reports may arrive at the root even when the return path is broken.

A selection flow moves from interaction pattern through budget and semantics to a protocol fit, then compares MQTT, CoAP, HTTP, and WebSocket above a shared security contract. — Application interaction pattern, device constraints, and semantic contract narrow the fit among MQTT, CoAP, HTTP, and WebSocket.

Major section

Start With the Downward Packet · Overview: The Mode Decides Where Downward State Lives

Sensor reports may arrive at the root even when the return path is broken.

The first question is where each device expects the downward route record to live.
RPL means Routing Protocol for Low-Power and Lossy Networks.
Telemetry means measurements and status sent for remote use.

RPL routing mode changes where downward route state is kept, not whether routing evidence is needed.

Major section

Practitioner: Write the Mode Choice as Evidence

A practitioner should turn the mode choice into a short review record.

A root, router-capable intermediate node, and leaf-only node do not carry the same routing responsibility.
Upward packet traces, preferred-parent evidence, and command-path tests if commands exist.
Intermediate routers need correct descendant route state.

Traffic direction determines which routing-mode evidence matters.

Major section

Practitioner: Write the Mode Choice as Evidence (continued)

Parent churn, root failover, node mobility, firmware changes, payload growth, and new command flows can all invalidate an older mode decision even when the topology picture still looks familiar.

The root needs current path knowledge and source-route packet proof.
Local route state may help only if the required ancestor and route entries exist.
Peer paths may depend on the root's source-routing role.
Route tables consume memory on router-capable nodes.

Major section

Practitioner: Write the Mode Choice as Evidence (continued)

The hand-off in Figure: Application interaction pattern prevents this routing choice being mistaken for an application protocol choice.

Source-route information consumes packet space on downward paths.
The local turn in Figure: A storing-mode DODAG routes peer traffic from E shows exactly what distributed descendant state buys for the E-to-F peer flow.
The mode difference is easiest to see on a single peer flow.

A storing-mode DODAG routes peer traffic from E upward to B and directly downward to F using B's descendant table.

Major section

Practitioner: Write the Mode Choice as Evidence (continued)

The labels upward and A writes source route [B,F] expose the trade: routers keep less descendant state, but peer traffic detours through the root and carries route information.

In Figure: Application interaction pattern, Interaction pattern and Budget precede Semantics; only then does Fit name MQTT, CoAP, HTTP, or WebSocket.
B recognizes F as its own descendant and forwards directly, without involving the root.
In Non-Storing mode, only the root keeps downward path knowledge; B has no route-table entry for F even though B is the same physical common ancestor.

A non-storing-mode DODAG routes E to B to root A, then follows a root-provided source route back through B to F.

Major section

Practitioner: Write the Mode Choice as Evidence (continued)

The peer path is still correct, but it is roughly twice as long as the Storing-mode path, and it now depends on the root staying reachable and holding a current route for F.

That gap is why the review rule above insists on explicit peer-path evidence.
A design that only proves upward telemetry can look identical in both modes; the Storing-versus-Non-Storing difference only becomes visible once a peer or downward packet is traced hop by hop.
Storing and non-storing mode describe downward state; they do not make every RPL-like route selector interchangeable.

Major section

Under the Hood: DAO and Packet Evidence Carry the Claim

DAO evidence supports downward reachability, but it is not the same as application delivery.

It helps prove that the selected mode has route knowledge for a destination.
Packet tests still have to show that the claimed traffic can move through the current topology.

Major section

Under the Hood: DAO and Packet Evidence Carry the Claim (continued)

Storing mode asks router-capable nodes to keep useful descendant state.

Non-Storing mode asks the root to maintain the downward path view and fit source-route information into downward packets.
DAO registration explains how route knowledge is formed; a downward packet test checks whether those entries deliver traffic.
Nodes may join the wrong context, misunderstand the mode, or compare paths with stale assumptions.

Major section

Under the Hood: DAO and Packet Evidence Carry the Claim (continued)

Counting the example's links gives two forwarding steps for E → B → F and four for E → B → A → B → F; those counts alone do not establish latency.

Root change, firmware change, Objective Function change, or topology reset.
Downward route claims can be stale, missing, or stored at the wrong place for the selected mode.
Payload growth, security wrapper change, link setting change, or new traffic direction.

Major section

Summary · Key Takeaway

RPL Storing and Non-Storing modes differ mainly in where downward route state lives.

Storing mode lets router-capable nodes keep descendant reachability for downward forwarding.
Non-Storing mode places downward path responsibility at the root and uses source-route information.
Peer traffic and downward commands need explicit path evidence, not assumptions from the mode name.

Deck summary

Key takeaways

Sensor reports may arrive at the root even when the return path is broken.

A practitioner should turn the mode choice into a short review record.
Parent churn, root failover, node mobility, firmware changes, payload growth, and new command flows can all invalidate an older mode decision even when the topology picture still looks familiar.
The hand-off in Figure: Application interaction pattern prevents this routing choice being mistaken for an application protocol choice.
The labels upward and A writes source route [B,F] expose the trade: routers keep less descendant state, but peer traffic detours through the root and carries route information.

Retrieval practice

Recall check 1 of 4

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

Q1Which question best distinguishes RPL Storing mode from Non-Storing mode?

AWhether upward traffic uses a preferred parent in both modes.

BWhere downward state resides and how command packets travel.

CWhether RPL can use DIO control messages at all.

DWhether Rank is replaced by hop count in either mode.

Show answer

Answer: B A mode review starts by locating downward route state and then proving packet behavior for the traffic direction being claimed.

Retrieval practice

Recall check 2 of 4

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

Q2A greenhouse mesh sends sensor readings upward and sends valve commands downward to selected controllers. What is the strongest review habit?

AAccept the selected mode after three readings reach the root, and leave valve-command packet traces for the production pilot.

BChoose Storing mode when routers have enough memory because available RAM also covers descendant entries and repairs.

CSeparate upward telemetry from downward commands, then prove DAO and command-packet behavior.

DChoose Non-Storing mode when the root knows the topology because its source routes fit each packet and acknowledge commands.

Show answer

Answer: C A practical RPL mode decision is evidence-bound: traffic direction, route-state location, control-plane evidence, packet proof, and retest triggers.

Retrieval practice

Recall check 3 of 4

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

Q3A greenhouse mesh uses RPL Non-Storing mode so the root can send irrigation-valve schedule updates to bed controllers. The team has DAO logs for one controller and wants to declare the command path proven. What should the reviewer require next?

AApproval from the DAO logs alone because RPL control evidence and irrigation command delivery are equivalent.

BOnly upward soil-moisture telemetry from the controller because downward routing is implied by parent selection.

CA note that packet size can be ignored because Non-Storing mode never changes packet behavior.

DA downward command trace with source-route data, packet-size fit, receiver acknowledgement, and accepted schedule state.

Show answer

Answer: D Under-the-hood RPL review connects control-plane evidence, route-state placement, packet behavior, and retest ownership.

Retrieval practice

Recall check 4 of 4

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

Q4A mesh needs downward commands, but relays have little route memory. Which mode-choice record is reviewable?

ACompare relay memory and root/source-route cost; require DAO and packet proof.

BChoose Storing mode because commands move downward in the mesh.

CChoose Non-Storing mode because the root can encode downward routes in packets at negligible cost.

DChoose by DIO count because more control messages indicate more reliable command delivery.

Show answer

Answer: A Mode selection must compare state placement and packet overhead with actual DAO and command evidence.

Print reference

Answers

Answer key.

B · A mode review starts by locating downward route state and then proving packet behavior for the traffic direction being claimed.
C · A practical RPL mode decision is evidence-bound: traffic direction, route-state location, control-plane evidence, packet proof, and retest triggers.
D · Under-the-hood RPL review connects control-plane evidence, route-state placement, packet behavior, and retest ownership.
A · Mode selection must compare state placement and packet overhead with actual DAO and command evidence.