20 Storing vs Non-Storing Modes
RPL routing modes, RPL storing mode, RPL non-storing mode, RPL source routing, RPL DAO
20.1 Start With the Downward Packet
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.
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.
Upward Traffic
Node-to-root traffic normally follows preferred parents. This direction often looks similar in both modes.
Storing Mode
Router-capable nodes store descendant reachability and may forward downward packets using local route entries.
Non-Storing Mode
The root maintains downward path knowledge and includes source-route information for downward packets.
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.
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.
Mode Review Flow
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.
Boundary Evidence
Do not treat DAO as proof of application success. DAO supports route knowledge; application delivery still needs packet evidence and receiver behavior.
Mode Acceptance Checklist
- Name the traffic directions the application actually uses.
- Record which nodes may store downward route state and which nodes remain leaf-only.
- Keep DAO evidence and either router route tables or root path knowledge for the selected mode.
- Check packet size and forwarding behavior for downward and peer paths, not just upward telemetry.
- List retest triggers such as parent churn, root change, firmware update, payload growth, and topology changes.
20.2 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.
20.3 Key Takeaway
Choose an RPL routing mode by proving the route-state location and packet behavior for the traffic your application actually uses.