13  The RPL Routing Model

Keywords

RPL core concepts, DODAG, RPL Rank, DIO, DIS, DAO, Trickle timer, Storing mode, Non-Storing mode

13.1 Start With One Parent Choice

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.

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.

RPL review starts by checking the DODAG root, Rank direction, candidate parents, and upward forwarding path.

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.

Overview Knowledge Check

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.

Record field

Question

Evidence to keep

Failure it prevents

DODAG scope

Which root, instance, and version are in scope?

Root identity, DODAG ID, RPL Instance, and observed version.

Mixing evidence from different graphs or repairs.

Selection rule

How are parents compared?

Objective Function, relevant metrics, constraints, and rejected candidates.

Treating Rank as simple hop count.

Preferred parent

Which next hop handles upward traffic?

Selected parent, backup parent conditions, local Rank, parent Rank, and link evidence.

Choosing a parent that looks valid in a diagram but fails in operation.

Control messages

What did the node hear or advertise?

DIO, DIS, DAO, and DAO-ACK observations when those messages are relevant.

Confusing discovery evidence with route reachability.

Routing mode

Where does downward route state live?

Storing or Non-Storing mode, route-state location, and root behavior.

Testing upward telemetry but missing command or reply paths.

Packet proof

Did the claimed traffic work both ways?

Packet trace, route-state snapshot, next-hop evidence, and failure retest trigger.

Accepting a formed DODAG as proof of application health.

RPL Control Messages

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.

Practitioner Knowledge Check

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.

Storing and Non-Storing modes differ mainly in where downward route state lives and how downward packets are forwarded.

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.

Review Boundaries

• A formed DODAG does not prove that every node has a return path.
• A low advertised Rank does not prove a stable or acceptable link.
• A DAO seen once does not prove current downward route health after parent repair.
• Storing and Non-Storing mode evidence should not be mixed in one explanation.
• Border-router routes must be checked separately from mesh parent selection.

Under-the-Hood Knowledge Check

13.2 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.

13.3 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.

13.4 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.