Routing & RPL · Study deck

Routing in Low-Power IoT Networks

Routing is the job of choosing a path for data through a network.

Packet Pete is your guide for this deck.

routingiot-routinglow-power-lossy-networks

Packet Pete, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

decide between a static/default route, RPL, or infrastructure routing from IoT network constraints
write an RPL-fit record instead of defaulting to RPL without justification
treat DIO as discovery evidence and DAO as return-path support, and require repair to be tested
Explain: Routing is the job of choosing a path for data through a network.

Major section

Start With the Weakest Link · Overview: IoT Routing Starts With Constraints

Routing is the job of choosing a path for data through a network.

In an IoT network, the weakest part may be a battery device that sleeps or a radio link that fades.
A relay device, called a parent, may change.
The radio may carry only short bursts of data.

Major section

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.

Testing only telemetry while command or reply traffic silently fails.
Accepting a route that only works while one preferred neighbor is healthy.

A protocol-fit record separates RPL-friendly mesh constraints from cases where a simpler gateway route or capable infrastructure routing is enough.

Major section

Practitioner: Write the RPL Fit Record (continued)

Failure it prevents.

Parent changes, DODAG version changes, DAO churn, retries, queue depth, and packet proof.
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.

Major section

Under the Hood: Parent Choice and Repair Are the Boundary

RPL parent selection is local but not arbitrary.

Upward forwarding should move toward lower Rank, while downward reachability depends on the selected routing mode and DAO behavior when that traffic is required.
Repair is the other half of the boundary.
Two named variants show why protocol labels need their mechanism recorded.

Upward telemetry and downward commands are different claims. A formed DODAG is not proof that both directions work.

Major section

Under the Hood: Parent Choice and Repair Are the Boundary (continued)

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.

A node that finds a better parent, loses a parent, or hears a new DODAG version changes both forwarding behavior and review evidence.
The asset depicts how upward telemetry and downward commands are different claims.
The Repair Must Be Tested card separates recovery from initial formation.

Major section

Under the Hood: Parent Choice and Repair Are the Boundary (continued)

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.

Cognitive RPL (CORPL) keeps the DODAG concept but routes through a forwarding set rather than relying only on parent forwarding state; DIO messages update neighbours as that set forms.
A formed DODAG is not proof that both directions work, which identifies the concrete observation that the surrounding prose is about to use.
Their combined meaning is that upward telemetry and downward commands are different claims.

Major section

Under the Hood: Parent Choice and Repair Are the Boundary (continued)

A formed DODAG is not proof that both directions work, which advances Under the Hood: Parent Choice and Repair Are the Boundary.

DIO Is Discovery Evidence It advertises graph context and helps a node compare candidates.
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.
After a parent or root repair, retest the state location named by the selected column and then send the downward command.

Major section

Proving End-to-End Paths

The warning arrives, but the reply that should silence the alarm never reaches the sensor.

One successful message did not prove a working path.
A gateway is the device that joins one network to another.
Telemetry means the readings and status a device reports.
Firmware is the code stored on the device.

End-to-end connectivity is proven by checking the named flow's source address, hop-by-hop forwarding, border policy, upstream route, return path, and loop-limit evidence.

Major section

Proving End-to-End Paths (continued)

A green network icon is not enough evidence.

This simple path test does not prove every future condition.
Loads, rules, and radio links can change.
The deeper sections show how addresses, forward routes, return paths, and loop limits turn the first test into a reviewable connectivity record.
That device-centered view keeps the design honest.

Major section

Proving End-to-End Paths (continued)

Connectivity is not proven by saying the network is up.

It separates local radio reachability from routed IP reachability, and it shows whether the deployment has enough evidence for telemetry, commands, diagnostics, and recovery paths.
End-to-end IoT connectivity is a whole-path claim.
Static routes are useful when the topology is small and stable.

Major section

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.

Deck summary

Key takeaways

Routing is the job of choosing a path for data through a network.

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.
Failure it prevents.
RPL parent selection is local but not arbitrary.
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.

Retrieval practice

Recall check 1 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q1A battery-powered IPv6 sensor mesh has lossy links, sleeping nodes, and most traffic flowing toward one border router. Which routing review question comes first?

AWhich enterprise routing protocol has the longest feature list.

BWhich route fits link quality, relay roles, traffic direction, and repair.

CWhether every node can be treated like a mains-powered campus router.

DWhether the application dashboard can hide routing instability from operators.

Show answer

Answer: B IoT routing should be selected from deployment constraints: link quality, relay roles, traffic direction, route repair, and observable evidence.

Retrieval practice

Recall check 2 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q2A constrained mesh sends most readings upward to one gateway. Several leaf nodes can hear two relays, but one relay has a much weaker wireless link even though it is one hop closer to the root. Which design record is strongest?

AUse only static routes because a fixed route prevents parent changes.

BUse hop count only because fewer hops always means better route quality.

CUse RPL with MRHOF, keep parent evidence, and test repair on relay failure.

DSkip downward-route review because the mesh usually sends telemetry upward.

Show answer

Answer: C The practitioner record should connect routing approach, Objective Function, parent evidence, repair behavior, and traffic direction.

Retrieval practice

Recall check 3 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q3A node keeps switching between two parents with similar metrics, and telemetry still reaches the root most of the time. What is the strongest routing review response?

AIgnore the churn because any successful telemetry packet proves the mesh is stable.

BChoose the parent with the highest Rank because it has moved farthest from the root.

CDisable all route-health logging so the application dashboard looks cleaner.

DTreat churn as route-health evidence; recheck hysteresis, DAO, and repair delivery.

Show answer

Answer: D Under the hood, parent churn, Rank direction, DAO effects, repair tests, and packet evidence decide whether a routing claim is credible.

Retrieval practice

Recall check 4 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q4A sensor can ping its gateway, but cloud replies never return. What does the evidence prove?

AFull end-to-end connectivity, because the gateway answered.

BOnly first-hop reachability; the forward and return path is still unproven.

CThat TTL or Hop Limit is irrelevant to the diagnosis.

DThat the sensor route table can be ignored once a gateway is visible.

Show answer

Answer: B End-to-end connectivity requires source addressing, hop-by-hop forwarding, policy, and return-path evidence.

Retrieval practice

Recall check 5 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q5A sensor can ping its local gateway. Traceroute to an application endpoint shows the first hop as the gateway and then stops. Which finding best matches the evidence?

AThe sensor has no usable IP address.

BThe endpoint route must be missing on the sensor.

CA routing loop has been proven.

DGateway or upstream handling is the next suspect.

Show answer

Answer: D Use the last responsive hop as the first place to inspect.

Retrieval practice

Recall check 6 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q6Traceroute from a sensor toward the gateway alternates between two router addresses until the probes expire. What is the most defensible conclusion?

AThe application protocol is misconfigured, because traceroute never checks routing.

BRPL removes the need for source addresses and return paths inside low-power meshes.

CA routing loop is likely; repair next-hop state on the repeated routers.

DThe correct response is to increase TTL so the packet can circulate longer.

Show answer

Answer: C Repeated hops are loop evidence.

Print reference

Answers 1 of 2

Answer key.

B · IoT routing should be selected from deployment constraints: link quality, relay roles, traffic direction, route repair, and observable evidence.
C · The practitioner record should connect routing approach, Objective Function, parent evidence, repair behavior, and traffic direction.
D · Under the hood, parent churn, Rank direction, DAO effects, repair tests, and packet evidence decide whether a routing claim is credible.
B · End-to-end connectivity requires source addressing, hop-by-hop forwarding, policy, and return-path evidence.

Print reference

Answers 2 of 2

Answer key.

D · Use the last responsive hop as the first place to inspect.
C · Repeated hops are loop evidence.