Zigbee, Thread & Matter · Study deck
6LoWPAN RPL Routing
RPL is the route-over routing protocol most often reviewed with 6LoWPAN IPv6 networks.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Review RPL route-over behavior using DODAG, parent, rank, DAO, packet, and border-router records.
- Distinguish evidence for upward, downward, point-to-point, discovery, diagnostic, and repair traffic.
- Explain how parent and rank records support routing claims without turning example values into universal design rules.
- Identify missing border-router, prefix, queue, or packet evidence before approving a 6LoWPAN routing result.
Major section
Start With One Packet Path
A route drawn on a screen may look stable while one weak relay is already losing messages.
- The release test must show how the path changes and what reaches the receiver.
- Internet Protocol means the addressing rules used to move network packets.
- IPv6 means version 6 of those rules.
Major section
Start With One Packet Path (continued)
A gateway means the bridge to a wider network.
- 6LoWPAN means a way to carry IPv6 over small low-power radios.
- Routing Protocol for Low-Power and Lossy Networks (RPL) means rules for choosing paths in such a network.
- Telemetry means readings and status sent by a remote device.
Major section
Start With One Packet Path (continued)
A directed acyclic graph means a set of one-way links with no loop back to the start.
- This runway does not prove that the best path stays best.
- Mesh protocols fail at boundaries: sleepy children, route repair, parent changes, multicast, retries, and gateway custody.
- The chapter is easier to read when every detail is tied back to that first path.
Major section
In 60 Seconds
Route-over means each forwarding node acts at the IPv6 layer, so route evidence must match IPv6 next-hop behavior.
- DIO, DIS, and DAO records explain how nodes discover the DODAG, request updates, and advertise reachability.
- Parent and rank evidence should be reviewed with packet outcomes, not as isolated numbers.
- Route repair evidence should include the trigger, before-and-after parent state, DODAG version or local repair notes, and the application result.
Major section
DODAG, Rank, and Root Model
In most 6LoWPAN route-over reviews, that graph is rooted at the border router because the border router is also the custody point for prefix, ingress, egress, queue, and route-state records.
- The practical evidence question is whether rank decreased toward the approved root for the packets being claimed, and whether any alternate parent choices were explained by the same metric policy.
Major section
Route-Over Boundary
In route-over forwarding, each forwarding node is an IPv6 router for the constrained network.
- A compressed frame on one hop is not proof of the full route.
- The reviewer needs to know how the packet was reconstructed, which IPv6 next hop was selected, and whether the next link forwarded the same traffic class.
- This chapter is focused on RPL route-over evidence.
Major section
RPL And LOADng Boundary
That difference changes the evidence.
- RPL evidence is usually about DODAG root custody, rank, objective function, DAO state, and repair timing.
- LOADng evidence is about route requests, forwarding of those requests, route replies from the destination, route errors after breakage, sequence numbers, and whether optimized flooding reduced overhead without hiding a failed path.
- A LOADng-style route discovery trace can prove that one destination was discovered when traffic was needed, but it does not prove RPL parent stability.
Major section
Parent and Rank Evidence
Parent and rank records help explain path choice and loop avoidance, but they are not sufficient alone.
- A strong review records preferred parent, candidate parents, rank, metric source, and whether the data path followed the parent choice.
- Weak record:: Node 24 selected parent 08, so routing is healthy.
- If a chapter or lab uses example numbers, the review should still ask what those numbers prove in the actual run.
Major section
Control Messages and Parent Choice
RPL control messages explain how route state forms before a data packet can prove the claim.
- The review should preserve the message role, direction, and observed result rather than listing acronyms in isolation.
- DIS: DODAG Information Solicitations request fresh DIO information when a node joins, recovers, or needs routing updates faster than the normal Trickle cadence.
- If the review claims parent stability, it should name the candidate set and metric window.
Major section
Downward Traffic Evidence
For downward claims, look for DAO or equivalent route-state evidence, root route entries or source-route state, queue and drop records, command delivery at the node, and application acknowledgment.
- If the node sleeps, the claim also needs evidence for the delivery window or buffering behavior.
Major section
Storing and Non-Storing Route State
Downward RPL evidence changes depending on where route state is stored.
- In storing mode, intermediate routers keep routing entries for nodes in their sub-tree, so a packet can turn downward at a common ancestor.
- In non-storing mode, the root holds the topology and source-routes packets down the recorded path.
- Both modes can support downward delivery, but they leave different evidence trails.
Major section
Border-Router and Prefix Custody
The border router is both an IPv6 edge and an RPL root in many 6LoWPAN deployments.
- Reviewers should treat it as a custody point, not just a gateway icon.
- A server-side success message is not enough if the border-router constrained-side record is missing.
- The review should show that the route claim was true on both sides of the border.
Major section
Worked Review: Downward Command Gap
Upward telemetry evidence may still be valid, but the command path is not proven.
- Scenario: the border router sends actuator commands to three leaf nodes.
- The server log shows commands accepted, but the constrained-side capture shows route state for only one node.
- Two commands are queued and later dropped.
Major section
Common Mistakes
Using topology as proof: A DODAG diagram explains intended structure.
- Mixing directions: Upward telemetry success does not prove downward command delivery or point-to-point routing.
- Ignoring the border router: The root, prefix, route state, queues, drops, and egress records are part of the routing claim.
- Approving after one repair: One recovered path does not prove every traffic class, node group, or sleep-window behavior recovered.
Deck summary
Key takeaways
A route drawn on a screen may look stable while one weak relay is already losing messages.
- A gateway means the bridge to a wider network.
- A directed acyclic graph means a set of one-way links with no loop back to the start.
- Route-over means each forwarding node acts at the IPv6 layer, so route evidence must match IPv6 next-hop behavior.
- In most 6LoWPAN route-over reviews, that graph is rooted at the border router because the border router is also the custody point for prefix, ingress, egress, queue, and route-state records.
Retrieval practice
Recall check 1 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q1In 6LoWPAN route-over routing with RPL, what does RPL construct and where is it usually rooted?
Show answer
Answer: A RPL builds a destination-oriented directed acyclic graph (DODAG) usually rooted at the border router.
Retrieval practice
Recall check 2 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q2How does an RPL node choose its route toward the root in a reviewable parent-selection record?
Show answer
Answer: A A reviewable RPL parent choice connects DIO evidence, objective-function inputs, candidate rank, selected parent, and packet outcome.
Retrieval practice
Recall check 3 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q3In RPL non-storing mode, what evidence best supports a downward command claim?
Show answer
Answer: A Non-storing RPL proves downward delivery with root-held topology, source-route behavior, packet evidence, and application outcome.
Retrieval practice
Recall check 4 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q4A team has strong RPL evidence for upward telemetry from leaf nodes to the border router. They want to approve downward actuator commands using the same evidence. What should the reviewer do?
Show answer
Answer: B Upward telemetry and downward commands are different evidence claims.
Retrieval practice
Recall check 5 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q5After a parent router restarts, a child node changes parent and telemetry resumes. Which evidence is most useful before approving route repair?
Show answer
Answer: B Repair review should preserve the before state, trigger, after state, packet result, application outcome, and retest boundary.
Print reference
Answers
Answer key.
- A · RPL builds a destination-oriented directed acyclic graph (DODAG) usually rooted at the border router.
- A · A reviewable RPL parent choice connects DIO evidence, objective-function inputs, candidate rank, selected parent, and packet outcome.
- A · Non-storing RPL proves downward delivery with root-held topology, source-route behavior, packet evidence, and application outcome.
- B · Upward telemetry and downward commands are different evidence claims.
- B · Repair review should preserve the before state, trigger, after state, packet result, application outcome, and retest boundary.