12 Storing vs Non-Storing Modes
12.1 Start With the Downward Packet
Find Where the Return Route Is Kept
Picture a control room sending a valve command down through a small field network. 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.
A directed acyclic graph is a route shape with one-way links and no loop; DODAG means destination-oriented directed acyclic graph. A protocol means the shared rules for a message exchange. RPL means Routing Protocol for Low-Power and Lossy Networks. Telemetry means measurements and status sent for remote use.
Record the root view, each router’s stored state, packet header size, node memory, route age, and valve result. Remove a router, repeat the report, send the command, restart the root, and show missing downward proof as a failure.
This runway does not prove that storing or non-storing mode is always better. The deeper sections compare state placement, source routes, memory, packet size, repair behavior, and mixed traffic evidence.
RPL routing mode matters most when a packet must travel from the root toward a node. In storing mode, intermediate routers keep downward route state. In non-storing mode, the root carries more of the path information in the packet.
Start with that downward packet and ask where the route knowledge lives. The answer changes memory pressure, header overhead, repair behavior, troubleshooting evidence, and whether a deployment can support commands as confidently as it supports upward telemetry.
12.2 Overview: The Mode Decides Where Downward State Lives
RPL builds an upward routing structure toward a DODAG root. A device can usually send traffic upward by forwarding to its preferred parent. Storing and Non-Storing mode become important when traffic must move downward from the root or across the DODAG between non-root nodes.
The core question is route-state placement. In Storing mode, router-capable nodes keep downward routes for descendants. In Non-Storing mode, the root keeps the downward path view and uses source-route information for packets that travel down the DODAG.
That placement changes the evidence, not the need for evidence. Storing mode asks whether intermediate routers have current descendant entries and enough memory to keep them. Non-Storing mode asks whether the root has the current path view and whether the resulting source-route information fits the packet and link constraints.
Mode choice also depends on the application mix. A network that mostly uploads readings may tolerate a different proof burden than a control system that sends frequent commands to sleeping devices. The overview decision should name the traffic direction before treating either mode as simpler.
The safest overview record is a comparison, not a slogan. It names where state is stored, which nodes are allowed to store it, how DAO evidence is checked, what packet overhead is expected, and what event forces retesting after the first deployment.
When a design has both telemetry and commands, review the two directions separately. The mode can be acceptable for one direction while still needing extra evidence for the other.
That discipline keeps mode selection tied to observable route state instead of preference alone.
Treat Overview: The Mode Decides Where Downward State Lives as a hypothesis to test against Figure 12.1. Because it shows how RPL routing mode changes where downward route state is kept, not whether routing evidence is needed, the diagram reveals which named component should produce each piece of evidence.
Before accepting the overview: the mode decides where downward state lives claim, examine Figure 12.1 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.
In Figure 12.1, the visual shows rPL routing modes summary contrasting storing mode, where each router keeps its own routing table for local hop-by-hop downward forwarding at higher memory cost, with non-storing mode, where the DODAG root uses source routing so nodes need no. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the overview: the mode decides where downward state lives 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.
12.2.1 Upward Traffic
Node-to-root traffic normally follows preferred parents. This direction often looks similar in both modes.
12.2.2 Storing Mode
Router-capable nodes store descendant reachability and may forward downward packets using local route entries.
12.2.3 Non-Storing Mode
The root maintains downward path knowledge and includes source-route information for downward packets.
12.2.4 Peer Traffic
Node-to-node traffic needs explicit path evidence. Do not assume it is short, root-free, or reliable from the mode name alone.
Do not choose a mode from node count alone. Name the traffic direction, route-state location, DAO evidence, packet-size behavior, and retest trigger before accepting the choice.
12.3 Practitioner: Write the Mode Choice as Evidence
A practitioner should turn the mode choice into a short review record. The record separates upward telemetry, downward commands, and peer flows because each direction exercises different route-state assumptions.
The record also names node roles. A root, router-capable intermediate node, and leaf-only node do not carry the same routing responsibility.
Add the refresh rule to the same 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.
Before accepting the practitioner: write the mode choice as evidence claim, examine Figure 12.2 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.
In Figure 12.2, the visual shows rPL traffic directions showing upward parent forwarding, downward routing differences, and peer traffic path evidence. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the practitioner: write the mode choice as evidence 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.
12.3.1 Mode Review Flow
The local turn in Figure 12.3 shows exactly what distributed descendant state buys for the E-to-F peer flow.
In Figure 12.3, E first follows its upward relation to B. The orange turn toward F is possible because B · descendant table stores both children, so E → B → F reaches the nearest common ancestor without visiting the root.
The matched topology in Figure 12.4 isolates the cost of moving that downward knowledge out of B and into A.
Trace Figure 12.4 from E through B to A, then follow the orange source-routed return through B to F. 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.
The hand-off in Figure 12.5 prevents this routing choice being mistaken for an application protocol choice.
In Figure 12.5, Interaction pattern and Budget precede Semantics; only then does Fit name MQTT, CoAP, HTTP, or WebSocket. RPL provides the network route, while Security: OSCORE / DTLS / TLS and the application contract still govern meaning, authorization, and replay behavior above it.
12.3.2 Worked Example: One Peer Path, Two Different Routes
The mode difference is easiest to see on a single peer flow. Take two leaf nodes, E and F, that share the same parent B, with B itself a child of the root A. In Storing mode, B keeps a route-table entry for every descendant in its sub-DODAG, including F, so a packet from E to F only has to climb as far as the nearest common ancestor before turning back down: E -> B -> F. 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. The same E-to-F packet has to climb all the way to the root, which looks up F's path and encloses it as a source route in the packet header, so the path becomes E -> B -> A -> B -> F, through B twice, once on the way up and once on the way back down. 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.
12.3.3 Interactive: Keep Medium Assumptions Attached to the Route Choice
Storing and non-storing mode describe downward state; they do not make every RPL-like route selector interchangeable. Use the protocol-assumptions preset below to compare RPL, CORPL, and CARP, then change the radio objective while keeping the medium fixed. The workbench labels which evidence belongs to a low-power radio mesh and which candidate is disabled when its acoustic-medium assumptions do not apply.
Carry the selected protocol, traffic direction, forwarding owner, and excluded-medium reason into the mode record. This prevents a comparison chart from silently overriding the DAO and packet evidence the deployed network actually needs.
12.4 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.
Under the hood, Storing mode and Non-Storing mode put different stress on the system. 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.
Before accepting the under the hood: dao and packet evidence carry the claim claim, inspect Figure 12.1 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.
In Figure 12.1, the visual shows rPL Routing Modes Summary: Routing Protocol for Low-Power and Lossy Networks (RFC 6550), RPL PROTOCOL, STORING MODE, ROUTING TABLES, Each router maintains, its own routing table, DOWNWARD ROUTING, Local hop-by-hop, forwarding decisions. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the under the hood: dao and packet evidence carry the claim 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.
The labels “RPL Routing Modes Summary” and “Routing Protocol for Low-Power and Lossy Networks (RFC 6550)” define the central comparison in Figure 12.1. Bring “RPL PROTOCOL” into the reading to confirm the RPL Routing Modes Summary. That evidence resolves the question posed by Under the Hood: DAO and Packet Evidence Carry the Claim. The diagram completes the evidence for Under the Hood: DAO and Packet Evidence Carry the Claim.
12.4.1 Boundary Evidence
Do not treat DAO as proof of application success. DAO supports route knowledge; application delivery still needs packet evidence and receiver behavior.
12.4.2 Mode Acceptance Checklist
Accept a mode only after following the traffic claim through its evidence. Name the upward, downward, and peer directions the application actually uses, then record which nodes may store downward state and which remain leaf-only. For the selected mode, pair DAO evidence with either router route tables or the root’s path knowledge. Test packet size and forwarding on downward and peer paths as well as upward telemetry, and finish by recording parent churn, root replacement, firmware updates, payload growth, and topology changes as retest triggers.
12.5 Summary
- RPL Storing and Non-Storing modes differ mainly in where downward route state lives.
- Upward traffic toward the root usually follows preferred parents in both modes.
- 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.
- A review record should keep traffic direction, node roles, DAO evidence, packet proof, and retest triggers together.
12.6 Key Takeaway
Choose an RPL routing mode by proving the route-state location and packet behavior for the traffic your application actually uses.