6 6LoWPAN RPL Routing
6LoWPAN RPL routing, RPL DODAG evidence, 6LoWPAN route-over review, RPL parent rank evidence, 6LoWPAN downward routing
RPL is the route-over routing protocol most often reviewed with 6LoWPAN IPv6 networks. A useful RPL review does not stop at naming a DODAG, a parent, or a rank value. It asks whether the route evidence actually supports the traffic direction and operational claim being approved.
This chapter reviews RPL as an evidence record for constrained IPv6 routing. It focuses on DODAG root custody, parent and rank records, upward telemetry, downward command paths, route repair, border-router responsibilities, packet captures, lab boundaries, and bounded release decisions.
6.1 Start With One Packet Path
Start with one packet path through 6LoWPAN RPL Routing. Name the sender, the next hop, the parent or router decision, and the evidence that proves the packet arrived for the reason the design expected.
Then widen the review. 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.
6.2 In 60 Seconds
- RPL creates a destination-oriented directed acyclic graph, usually rooted at the border router.
- 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.
- Upward telemetry and downward commands need separate evidence because they use different route state.
- Route repair evidence should include the trigger, before-and-after parent state, DODAG version or local repair notes, and the application result.
- A clean RPL decision states what direction, route class, node set, and evidence window were actually reviewed.
6.3 Learning Objectives
By the end of this chapter, 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.
- Write a bounded RPL review decision with retest triggers and open evidence items.
6.4 Quick Check: 6LoWPAN Routing
6.5 Prerequisites
This chapter assumes you have reviewed:
- 6LoWPAN Architecture Review Evidence, for stack-boundary and border-router custody.
- 6LoWPAN Header Compression Evidence, for packet reconstruction evidence.
- 6LoWPAN Fragmentation and Reassembly Evidence, for packet-size and reassembly boundaries.
- 6LoWPAN Lab Evidence Review, for capture plans and lab limits.
- 6LoWPAN Evidence Review Assessment, for evidence-bound assessment decisions.
6.6 RPL Review Claim
Use a claim that can be tested against route evidence:
RPL review claim: A 6LoWPAN route-over design is ready for the reviewed workload only when DODAG root records, parent and rank state, direction-specific route evidence, border-router custody, packet captures, application outcomes, and retest notes support the same traffic claim.
The claim is intentionally scoped. Evidence that proves upward telemetry reaches the root does not automatically prove downward commands, point-to-point control, repair behavior, or sleep-window delivery. Each traffic claim needs its own route evidence.
6.7 RPL Evidence Path
Use Figure 6.1 to move from route formation to review decision.
The path prevents a common review failure: approving the routing design because a topology diagram looks tree-shaped. The review should tie the DODAG picture to records from the nodes, the border router, the packet capture, and the application result.
6.8 DODAG, Rank, and Root Model
RPL, defined in RFC 6550, organizes a low-power IPv6 mesh as a destination-oriented directed acyclic graph. 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.
Rank is not a score that can be copied across implementations. It is an implementation record derived from the objective function, link metrics, and parent set active during the review window. 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.
6.9 Evidence Families
RPL review needs several evidence families. A missing family usually means the decision should stay open.
DODAG root Record the root identity, RPL instance, DODAG ID, prefix, grounded state, objective function, and whether the border router owns the approved root role.
Parent and rank Record preferred parent, candidate parents, rank, metric source, hysteresis or stability rule, and before-and-after values when the route changes.
Direction Separate upward telemetry, downward commands, point-to-point traffic, diagnostics, multicast-like discovery, and repair traffic before drawing conclusions.
DAO and route state Record whether downward reachability exists, where route state is stored, and whether the root or intermediate routers can forward to the reviewed node.
Packet and outcome Pair routing control messages with data packets, acknowledgments, drops, queue behavior, and application-level success or failure in the same evidence window.
Retest boundary Record which route change, firmware change, prefix change, border-router restart, radio environment change, or traffic profile requires a new review.
6.10 Route-Over Boundary
In route-over forwarding, each forwarding node is an IPv6 router for the constrained network. That boundary matters for review. 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.
Mesh-under evidence is different because forwarding happens below the IPv6 layer. This chapter is focused on RPL route-over evidence. If a deployment mixes route-over and link-layer forwarding, the review should name the boundary where responsibility changes and avoid claiming that one evidence set proves both layers.
6.11 RPL And LOADng Boundary
RPL is the default route-over routing topic in this chapter because it is the common IPv6 routing protocol for low-power and lossy networks. Some constrained designs, however, are reviewed against a reactive family such as LOADng, the Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation. 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.
Do not mix the two records. 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. An RPL DODAG can prove a maintained route-over topology, but it does not prove an on-demand route request and reply policy. The review should name which routing family is active before accepting mesh routing inside the PAN or between the PAN and the wider IPv6 domain.
6.12 DODAG and Root Evidence
The DODAG root is often the border router, but the review should still prove that role. Root evidence should include:
- The RPL instance and DODAG ID used by the reviewed nodes.
- The root identity and whether it is grounded for the traffic being approved.
- The prefix and context information tied to the constrained network.
- The objective function or metric policy used for parent selection.
- The timing of root restarts, version changes, or global repair events.
- The border-router ingress and egress records for the same route claim.
The important question is not whether a root exists. It is whether the reviewed nodes are attached to the expected root, using the expected route policy, during the same packet window that produced the application result.
6.13 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.
Stronger record: During the 14:20 to 14:35 telemetry run, node 24 advertised rank 819, selected parent 08, kept the same DODAG ID as the border-router root, forwarded upward telemetry through parent 08 in the packet capture, and received application acknowledgments for the tested message class.
Rank values should be treated as evidence from an implementation and configuration, not as a universal formula detached from the objective function. If a chapter or lab uses example numbers, the review should still ask what those numbers prove in the actual run.
6.14 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.
DIO DODAG Information Objects advertise the DODAG, rank, instance, and objective-function context that candidate parents expose to joining or maintaining nodes.
DAO Destination Advertisement Objects announce reachable destinations upward, creating the route-state evidence needed for root-to-node or downward claims.
DIS DODAG Information Solicitations request fresh DIO information when a node joins, recovers, or needs routing updates faster than the normal Trickle cadence.
Rank and objective function The objective function turns candidate-parent evidence such as ETX, policy, or implementation metrics into the rank comparison that selects a preferred parent.
A joining node listens for DIO records, computes its candidate rank through each viable parent, and selects the parent that gives the approved route toward the root under the configured objective function. If the review claims parent stability, it should name the candidate set and metric window. If it claims repair, it should show why the new parent was selected and whether the application traffic recovered.
6.15 Check: Parent Selection Evidence
6.16 Upward Traffic Evidence
Many 6LoWPAN workloads are dominated by upward telemetry from leaf nodes to the border router. Upward evidence should include:
- Node membership in the expected DODAG.
- Preferred parent and rank during the packet window.
- Data packets moving toward the root through the expected next hops.
- Border-router ingress records for the same packets.
- Application receipt, deduplication, and timing records.
- Any packet class excluded from the claim.
Upward success is often the easiest RPL claim to prove. It is also easy to overstate. A clean upward telemetry run does not prove that commands can flow back down, that point-to-point node traffic is efficient, or that repair has been tested.
6.17 Downward Traffic Evidence
Downward traffic needs separate review because it depends on route reachability from the root toward nodes. The evidence differs by mode and implementation, but the review question stays the same: can the root or intermediate routers forward the command to the reviewed node during the tested window?
Use Figure 6.3 to check whether the evidence matches the traffic direction.
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.
6.18 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.
For storing mode, look for router table capacity, sub-tree entries, stale entries after repair, and queue/drop records at intermediate routers. For non-storing mode, look for root topology state, source-route header behavior, path length, fragmentation pressure, and the border-router record that ties the source route to the command being reviewed.
6.19 Check: Downward Route-State Mode
6.20 Repair and Version Evidence
Route repair evidence should explain both the trigger and the result. A parent switch after a restart can be healthy, but it is not automatically proof of resilience. Review the before state, the change event, the after state, and the application outcome.
Before Record DODAG ID, root, parent, rank, route state, and traffic result before the event.
Trigger Record whether the event was a parent loss, root restart, link degradation, prefix change, software update, or intentional repair.
After Record new parent, rank, route state, route direction, packet result, and whether any nodes stayed orphaned or stale.
Decision State which traffic classes recovered, which did not, and what must be retested when the same trigger happens again.
If the DODAG version changed, preserve that record with the reason if known. If only local repair occurred, record which node repaired and which traffic class was affected. Avoid using a single recovered ping or one successful message as proof that all route directions recovered.
6.21 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.
Border-router evidence should answer:
- Which prefix and context information were active for the constrained network?
- Which DODAG root state and route mode were active during the test?
- Which packets arrived from the constrained side and which packets left toward the wider IP network?
- Which downward commands entered the constrained side and where were they queued, dropped, or delivered?
- Which logs, captures, and application records share the same timestamps?
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.
6.22 Capture and Lab Evidence
Packet captures are most useful when the capture plan is tied to a route question. A good RPL capture plan names the node set, traffic direction, route control messages, data packets, and application marker that will prove or disprove the claim.
Control plane Capture or log DIO, DIS, DAO, DODAG ID, rank, parent, route-state, and repair indicators.
Data plane Capture representative telemetry, command, diagnostic, or point-to-point packets with direction and next-hop evidence.
Application plane Record message IDs, acknowledgments, retries, drops, timestamps, and user-visible result for the same run.
Lab boundary State what was simulated, what was real hardware, which links were controlled, and which production conditions remain untested.
6.23 Worked Review: Clean Upward Telemetry
Scenario: ten leaf nodes publish temperature readings through a 6LoWPAN route-over network. The review packet window shows the expected DODAG ID, each node has a preferred parent, and the border router receives each message ID once. The application confirms receipt for the same message IDs.
Decision: accept the upward telemetry claim for the tested node set and packet class. Keep downward command delivery, route repair, and larger payload behavior open unless separate evidence covers them.
Retest trigger: repeat the review after firmware changes to RPL policy, prefix changes, border-router replacement, node relocation, or a measured increase in parent churn.
6.24 Worked Review: Downward Command Gap
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. The node logs do not show application acknowledgments.
Decision: reject the downward readiness claim. Upward telemetry evidence may still be valid, but the command path is not proven. The next review needs route-state evidence, border-router constrained-side queue records, command delivery captures, and node acknowledgment records.
6.25 Worked Review: Parent Repair After Restart
Scenario: a parent router restarts during a lab run. Five child nodes select new parents, then two return to the original parent after it rejoins. Telemetry resumes for all five nodes, but one node reports delayed command acknowledgment.
Decision: accept repair for the tested upward telemetry path after the restart. Keep downward command recovery open for the delayed node until the route-state, queue, and acknowledgment evidence explain the delay.
6.26 Common Mistakes
Using topology as proof A DODAG diagram explains intended structure. It does not prove packet delivery, route state, or repair behavior by itself.
Mixing directions Upward telemetry success does not prove downward command delivery or point-to-point routing.
Overtrusting rank Rank helps explain parent choice, but the review still needs packet and application outcomes.
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.
Forgetting lab limits A clean simulation or bench capture should name what production radio, density, mobility, and duty-cycle conditions remain untested.
6.27 RPL Review Checklist
Before approving a 6LoWPAN RPL claim, confirm:
- The reviewed traffic direction and packet class are named.
- The DODAG root, instance, prefix, and route policy match the expected design.
- Preferred parent and rank evidence covers the reviewed nodes during the packet window.
- DAO or route-state evidence supports any downward claim.
- Packet captures and application records use the same message IDs or timestamps.
- Border-router ingress, egress, queue, and drop records are included when relevant.
- Repair evidence includes before, trigger, after, and decision records.
- The final decision says what is accepted, what remains open, and what must be retested.
6.28 Knowledge Check 1
6.29 Knowledge Check 2
6.30 Match the Evidence
6.31 Order the Review
6.32 Summary
RPL review is a direction-specific routing evidence task. The reviewer checks DODAG root custody, parent and rank records, route state, packet captures, border-router behavior, application outcomes, repair records, and lab boundaries before approving a claim.
The safest decision is bounded. Accept upward telemetry only when upward evidence proves it. Accept downward commands only when downward route state and delivery evidence prove them. Accept repair only when the before, trigger, after, and outcome records support the recovered traffic class.
6.33 Key Takeaway
6LoWPAN RPL Routing Evidence should validate RPL routing with parent choice, rank stability, control overhead, repair behavior, security, and deployment evidence.
6.34 Concept Relationships
- 6LoWPAN Architecture Review Evidence explains the stack and border-router boundary that RPL depends on.
- 6LoWPAN Lab Evidence Review shows how to capture route evidence without overstating a lab run.
- 6LoWPAN Review Analysis Evidence provides the broader decision framework for accepting, rejecting, or retesting 6LoWPAN claims.
- 6LoWPAN Pitfall Debugging Evidence applies the same evidence logic to routing and packet failures.
- Thread Network Architecture shows how Thread builds a managed mesh using related constrained IPv6 ideas.
6.35 What’s Next
Next, review 6LoWPAN Deployment Evidence Framework to connect route evidence with deployment decisions, then use 6LoWPAN Evidence Review Assessment to check whether the complete 6LoWPAN review can stay evidence-bound.