6 Routing in Low-Power IoT Networks
LLN Constraints, RPL Fit, Parent Choice, and Repair Evidence
IoT routing, RPL, low-power lossy network, DODAG, parent selection, route repair, ETX
6.1 Start With the Weakest Link
IoT routing usually becomes interesting at the weakest part of the path: a battery node that sleeps, a link that fades, a parent that moves, a gateway that restarts, or a radio channel that carries only short bursts of traffic.
Start there before choosing a protocol. The routing design has to explain how packets keep moving when energy, memory, link quality, addressing, and maintenance windows are all limited. RPL exists because ordinary routing assumptions often break at that boundary.
Overview: IoT Routing Starts With Constraints
IoT routing is not just ordinary IP forwarding with smaller devices. The design has to account for lossy wireless links, sleeping nodes, small routing tables, limited power, gateway dependence, and traffic that is often strongly many-to-one. A route can look valid in a diagram and still fail if a relay sleeps, a weak parent is selected, or the return path was never tested.
RPL exists for one important case: constrained IPv6 nodes that must forward for one another across a low-power and lossy network. It builds a Destination-Oriented Directed Acyclic Graph rooted at a border router, then lets each node choose a preferred parent using the configured Objective Function and observed link evidence.
The review should therefore start with workload shape. A metering fleet that reports every hour has different routing evidence than an irrigation controller that needs a bounded downlink command or a mobile asset that changes parents during the day.
If you only need the intuition, this layer is enough: use simple static or gateway routing when the network is small and stable, use infrastructure routing for capable routers and backhaul, and consider RPL when constrained nodes form a lossy mesh that needs parent choice, repair, and traffic-direction evidence.
Static or Default Route
Best for small, stable paths where the next hop rarely changes and a simple table entry is enough to inspect.
RPL
Best for constrained IPv6 meshes where nodes forward for one another and parent choice must react to link quality.
Infrastructure Routing
Best for gateways, routers, and backhaul links with enough power, memory, bandwidth, and operations support.
Do Not Guess
Hold the design when traffic direction, return path, repair behavior, or route-health evidence is missing.
Overview Knowledge Check
Practitioner: Write the RPL Fit Record
A practical routing record should let another engineer decide whether RPL is appropriate and whether the chosen parent, repair behavior, and return path were proven. Keep the record small, but make every claim testable.
Use the record to choose the simplest routing approach that satisfies the claim. A fixed gateway subnet may need only a default route and return-path proof. A constrained mesh with lossy parent options may need RPL with an Objective Function that accounts for link quality and relay role. A mains-powered backhaul can use ordinary infrastructure routing outside the constrained domain.
Accept RPL
Nodes forward for one another, links vary, route repair matters, and route-health evidence can be observed.
Keep It Simple
Use static or gateway routing when endpoints are stable and no constrained node needs to relay traffic.
Split the Domain
Use RPL inside the LLN and a different routing approach at the border router or backhaul boundary.
Hold Review
Do not approve when downward traffic, root failure, parent churn, or route repair has not been tested.
Practitioner Knowledge Check
Under the Hood: Parent Choice and Repair Are the Boundary
RPL parent selection is local but not arbitrary. A node hears DIO information, filters incompatible candidates, applies the Objective Function, computes Rank, and chooses one or more candidate parents. Upward forwarding should move toward lower Rank, while downward reachability depends on the selected routing mode and DAO behavior when that traffic is required.
Rank is not just hop count. A design can prefer a slightly longer path if it has better link evidence, a more suitable relay role, or a lower expected transmission cost. Hysteresis matters because frequent parent changes can waste control traffic and hide instability until queues, retries, or missed commands expose it.
Repair is the other half of the boundary. A node that finds a better parent, loses a parent, or hears a new DODAG version changes both forwarding behavior and review evidence. Capture the control-plane trigger, the chosen replacement, the packets sent during the change window, and whether downward state was refreshed when commands depend on it.
Keep the failure window explicit. If telemetry succeeds during repair but commands fail afterward, the evidence points to a different route-state question than a total loss of upward forwarding.
DIO Is Discovery Evidence
It advertises graph context and helps a node compare candidates. It is not application-delivery proof.
Rank Guards Direction
Upward forwarding should progress toward lower Rank and compatible graph information.
DAO Supports Return Paths
Downward commands or replies need mode-specific route-state evidence, not just an upward telemetry test.
Repair Must Be Tested
Relay loss, root loss, weak-link degradation, reboot during join, and command delivery after repair are separate checks.
Under-the-Hood Knowledge Check
6.2 Summary
IoT routing has to be selected from the deployment constraints: power, memory, link quality, relay role, traffic direction, gateway dependency, and maintenance visibility. Static routes, RPL, and infrastructure routing all have valid places, but they prove different claims.
RPL fits constrained IPv6 meshes where nodes forward for one another and route repair matters. The review record should name the root, relay candidates, Objective Function, parent evidence, traffic directions, repair tests, and operations signals. A successful upward telemetry packet is useful evidence, but it does not automatically prove downward commands, return paths, or stability after parent repair.
6.3 Key Takeaway
Trust an IoT routing design only when the selected approach, parent rule, traffic direction, repair behavior, and route-health evidence match the constrained network it must operate in.
6.4 See Also
Routing Basics
Review next-hop forwarding, default routes, and loop limits before evaluating a constrained mesh.
End-to-End Connectivity
Connect route choice to gateway forwarding, return paths, and traceroute evidence.
RPL Core Concepts
Study DODAGs, Rank, DIO, DAO, and routing modes in more detail.
RPL DODAG Construction
Trace how parent selection and graph formation become reviewable route state.