6 The RPL Routing Model
An orchard leaf hears two neighbours that can forward toward the root. The nearest radio is not automatically the best parent. The routing decision needs both a valid upward direction and an objective-function result for the available paths.
6.1 Start With One Parent Choice
Ask Why This Neighbour Became the Parent
Picture orchard sensors passing soil readings toward one collection point. A leaf sensor hears two neighbours. One is close but nearly full; the other is farther away but has a steadier path. The useful record explains which parent it chose and why that choice still leads upward.
A protocol means agreed rules for exchanging messages. IPv6 is an addressing system for networked devices. The Routing Protocol for Low-Power and Lossy Networks (RPL) builds routes for constrained links. A directed acyclic graph is a set of paths with no loops. RPL aims this graph at one root; that form is called a Destination-Oriented Directed Acyclic Graph (DODAG). Name the root, both candidate parents, the choice rule, and the traffic direction.
Remove the chosen parent, replay an old route notice, restart the leaf, and send a command downward. Check that rank still rises away from the root, a new parent is justified, loops are refused, and downward delivery has its own proof.
This one choice does not prove the whole network. The deeper sections show control messages, route state, operating modes, repair, and packet evidence for the complete graph.
RPL becomes concrete when one node must choose a parent. It hears DIO information, calculates Rank, applies an objective function, checks constraints, and decides which neighbor gives it a safe path toward the DODAG root.
That parent choice carries the core model. DODAG identity, Rank, metrics, control messages, and routing mode all matter because they explain why the node joined the graph in that place and what traffic the resulting route state can support.
6.2 Peer Routing and DODAG Formation
Inspect Figure 6.1 to compare the same peer packet without changing endpoints or deployment shape, isolating where routing state lives.
Read Figure 6.1 by comparing STORING MODE, where routers keep route tables and can use the common ancestor shortcut, with NON-STORING MODE, where the root keeps downward state. The latter trades constrained-router memory for a source-route header and greater root-path cost.
Inspect Figure 6.2 next to separate an acyclic candidate graph from RPL’s rooted control-plane result and forwarding evidence.
Trace ROOT SENDS DIO through RANK MUST INCREASE in Figure 6.2, then connect DAO ADVERTISES DOWN to DATA FOLLOWS PARENT. The final definition distinguishes any acyclic DAG from a destination-oriented DAG with one root.
6.3 Overview: RPL Turns Local Evidence Into a DODAG
RPL is the IPv6 routing protocol used when low-power and lossy networks need routes around constrained nodes, lossy links, small buffers, and duty-cycled radios. It organizes participating routers into a Destination-Oriented Directed Acyclic Graph, or DODAG, rooted at a border router or collection point.
The important idea is local evidence. A node does not need a complete network map before it can join. It listens to DODAG advertisements, compares candidate parents through the configured Objective Function, computes Rank, and chooses a preferred parent for upward traffic toward the root.
The DODAG is therefore a scoped claim, not a universal delivery guarantee. Review the root, instance, DODAG version, parent choice, and traffic direction before accepting the result. Upward telemetry can be credible with parent and Rank evidence, while downward commands still need mode-specific DAO or source-route state and packet proof.
This evidence model also keeps troubleshooting narrow. A bad parent choice, stale DAO, wrong instance, missing source route, and application timeout are different failures, so the review should not collapse them into a single "RPL is broken" conclusion.
If you only need the intuition, this layer is enough: DIO messages explain the graph, Rank keeps upward movement oriented toward the root, DAO messages support downward reachability when that traffic is required, and packet tests prove whether the claimed route actually works.
Before accepting the overview: rpl turns local evidence into a dodag claim, examine Figure 6.3 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 6.3, the visual shows rPL DODAG mapped onto a three-story building: a border router at the roof holds Rank 0, intermediate routers on floor two hold Rank 256, and leaf sensor nodes on floor one hold Rank 512, illustrating the rank formula. 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: rpl turns local evidence into a dodag 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.
DODAG Root
The destination anchor for the constrained routing domain, commonly a border router or gateway.
Rank
A scalar position relative to the root. Upward forwarding should progress toward lower Rank.
Parent Choice
The selected next hop for upward traffic, chosen from compatible candidates using objective and link evidence.
Route Evidence
Control messages show route formation. Packet and route-state checks prove the traffic claim.
6.3.1 Overview Knowledge Check
6.4 Practitioner: Build the RPL Evidence Record
A useful RPL record is not a long protocol dump. It is a compact set of claims that another engineer can recheck when a parent changes, a route disappears, a command path fails, or the border router is replaced.
Before accepting the practitioner: build the rpl evidence record claim, inspect Figure 6.4 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 6.4, the visual shows rPL Control Messages: DIO, DIS, and DAO messages for DODAG construction, DIO - DODAG INFORMATION OBJECT, Multicast, Sent by DODAG root & routers to advertise the DODAG and invite nodes to join, KEY FIELDS, RPLInstanceID, DODAGID, Version. 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: build the rpl evidence 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.
6.4.1 Worked Record: Greenhouse Mesh
A greenhouse mesh sends telemetry upward to a border router and occasionally receives schedule updates from the gateway. The review record should name the root, the RPL Instance, the Objective Function, each node's selected parent, and whether schedule updates need Storing or Non-Storing downward routing evidence.
The upward telemetry test is not enough by itself. If the gateway must send a command to a sensor, the record also needs DAO or source-route evidence, the selected mode, and packet proof from the gateway back to the node.
6.4.2 Practitioner Knowledge Check
6.5 Under the Hood: Rank, Modes, and Failure Boundaries
RPL's loop-avoidance structure depends on Rank increasing away from the root. A joining node receives DIO information, filters incompatible candidates, applies the Objective Function, computes candidate Rank values, and selects a preferred parent. The selected parent for upward forwarding should have a lower Rank than the child.
Rank is not simply hop count. An Objective Function can prefer a path with better link evidence over a path that appears closer by hop count. The review question is therefore not "which neighbor advertised the smallest number?" It is "which compatible parent is acceptable under the Objective Function, and does forwarding still move toward the root?"
Failure review has the same boundary. After a parent switch, DODAG version change, or DAO lifetime expiry, old route evidence can become stale. The reviewer should refresh the selected parent, backup parent, downward route state, and packet test for the direction that matters.
A sound reading of Under the Hood: Rank, Modes, and Failure Boundaries begins with the evidence pictured in Figure 6.5. The diagram shows how storing and Non-Storing modes differ mainly in where downward route state lives and how downward packets are forwarded, turning the surrounding explanation into a checkable claim.
Use “RPL Storing vs Non-Storing” as the anchor in Figure 6.5. Compare it with “Two modes of operation for downward routing in RPL DODAGs” and finish at “STORING MODE (MOP 1-2)”; the progression makes clear how storing and Non-Storing modes differ mainly in where downward route state lives and how downward packets are forwarded. This is the concrete connection back to Under the Hood: Rank, Modes, and Failure Boundaries.
DIO Is Graph Evidence
DIO messages advertise DODAG context and Rank. They do not prove the application path by themselves.
DAO Is Reachability Evidence
DAO behavior matters when downward routes or root-to-node traffic are part of the claim.
Trickle Is Maintenance Evidence
Trickle changes DIO timing during stable and inconsistent periods. It is not a delivery guarantee.
Packets Close the Claim
Route state becomes credible only when packet traces and failure checks match the intended traffic direction.
6.5.1 Review Boundaries
Keep the review boundaries separate. A formed DODAG establishes structure, not a return path for every node; a low advertised Rank establishes position, not stable link quality. A DAO seen once cannot establish downward health after parent repair. Interpret route state under the selected Storing or Non-Storing mode, then check border-router routes separately from mesh parent selection. This sequence prevents one control-plane observation from being stretched into an end-to-end delivery claim.
6.5.2 Under-the-Hood Knowledge Check
6.6 Change the Orchard Parent without Confusing Rank with Distance
Use the chapter’s simplified illustration: the root has Rank 0, a router has Rank 256, and its leaf has Rank 512. The leaf-to-parent difference is 256. Those values show Rank increasing away from the root in this teaching model; they do not mean the leaf is 512 metres away or that all real objective functions add the same amount per hop.
Suppose the current parent stops answering. The leaf hears an alternative neighbour that advertises a usable route toward the same graph. Before switching, it checks identity, constraints and the rule used to calculate its new Rank. A radio signal alone cannot establish that the neighbour offers a safe upward path. The subsequent data trace must show that packets actually follow the selected parent.
Read Figure 6.2 through root advertisements, parent scoring, Rank direction and downward advertisement. These are different stages. A leaf can send upward through its parent while the downward route remains missing or stale. Test a command from the root separately rather than inferring it from a successful soil reading.
For an illustrative recovery clock, remove the parent at 0 s, select the alternative at 4 s and observe the first accepted reading at 7 s. The routing-state change takes 4 s, while useful delivery resumes after 7 s. If the alarm deadline was 5 s, the new parent selection alone does not make the service pass.
Predict where a peer packet travels in storing mode when a common ancestor already has the needed downward route. It may turn at that ancestor rather than visiting the root. Compare that with the root-held state and source-route path in Figure 6.1. Next, remove the ancestor’s downward entry. The earlier shortcut is no longer proven simply because the upward parents remain unchanged.
This module uses the rooted graph to connect local decisions with complete traffic paths. Keep the advertised information, chosen parent, Rank calculation and observed forwarding together. That evidence explains why a node joined where it did and what must be re-established after a neighbour disappears.
6.7 Summary
- RPL forms IPv6 routes for low-power and lossy networks by building a DODAG around a root.
- DIO, DIS, DAO, and DAO-ACK messages answer different route-formation and reachability questions.
- Rank is a directional review signal, not a synonym for hop count.
- Objective Functions shape parent selection and Rank calculation from available routing evidence.
- Storing and Non-Storing modes differ in where downward route state lives.
- DODAG formation, downward reachability, and packet delivery should be reviewed as separate claims.
6.8 Key Takeaway
Review RPL as evidence, not as a diagram: name the root and instance, prove the selected parent and Rank direction, identify the routing mode, and test the traffic direction being claimed.
6.9 See Also
RPL Introduction and Motivation
Use this before the core-concepts record when you need the design reason for RPL in constrained IPv6 networks.
RPL DODAG Construction Process
Continue from parent-selection evidence into the sequence that forms and repairs a DODAG.
RPL DODAG Message Flow and Exchange
Trace how DIO, DIS, DAO, and DAO-ACK observations support the control-plane record.
RPL Routing Modes
Compare Storing and Non-Storing mode evidence before accepting downward routing claims.