21  Lab: Designing an RPL Network

Keywords

RPL network design lab, RPL DODAG lab, RPL mode selection, RPL Rank parent selection, RPL evidence record

21.1 Start With the Traffic Story

An RPL design lab should begin with the traffic story, not the drawing. Name the devices, the root, the expected telemetry, any downward commands, and the conditions under which the network must still pass packets.

Only then should the DODAG sketch become evidence. Parent candidates, Rank movement, routing mode, packet tests, and retest triggers all need to support the same story so the lab record can be checked by someone who was not present during the design.

21.2 In 60 Seconds

This lab turns RPL concepts into a design-review exercise. You will classify node roles, draft a DODAG, calculate candidate Rank values, choose a preferred parent, decide whether Storing or Non-Storing mode fits the traffic pattern, and record the evidence needed before accepting the design. The goal is not to prove field performance from a paper topology. The goal is to produce a clean design record that separates assumptions, control-plane evidence, route-state evidence, and packet tests.

21.3 Learning Objectives

By the end of this lab, you will be able to:

• Build a small RPL design record from scenario constraints.
• Classify root, router, and leaf roles without making every device forward traffic.
• Draft a DODAG and identify where Rank should increase.
• Compare candidate parents using advertised Rank plus local link or policy cost.
• Choose Storing or Non-Storing mode from traffic-direction evidence.
• Explain which claims still need packet, DAO, or route-state validation.

Quick Check: Design Lab Record

21.4 Minimum Viable Understanding

1. The DODAG root anchors the RPL instance.
2. Mains-powered or otherwise capable nodes are better router candidates than constrained leaf nodes.
3. Rank should increase away from the root and upward forwarding should move toward lower Rank.
4. A design drawing does not prove DAO reachability or packet delivery.
5. Storing mode and Non-Storing mode change where downward route knowledge is kept.
6. A lab answer is stronger when it records assumptions and evidence instead of only drawing a tree.

Overview: The Design Is An Evidence Claim

An RPL network design is not accepted because the DODAG drawing looks plausible. It is accepted only when node roles, parent candidates, Rank movement, routing mode, route-state location, and packet tests support the same traffic story. This lab treats the drawing as a hypothesis and the design record as the proof boundary. The review starts with a plain question: what traffic must move, in which direction, and which evidence would show that the selected RPL structure can carry it?

Figure 21.1: RPL traffic design review record linking the traffic inventory, role evidence, route-state placement, packet proof, review decision, and retest trigger.

The first boundary is role assignment. A mains-powered floor node can be a router candidate, but it is not a proven parent until DIO evidence, local link evidence, Objective Function behavior, and stability checks support that role. A battery sensor can forward traffic only when the scenario justifies the extra energy and route-state burden. If the scenario only says “sensor,” the safer starting assumption is leaf behavior until the design record proves a forwarding need.

The second boundary is traffic direction. Upward telemetry, downward commands, and peer traffic create different proof needs. A clean DODAG can support an upward parent hypothesis, but it does not automatically prove that the root can command an actuator or that two constrained nodes can exchange packets. That is why the record separates the route-state claim from the packet claim. The design should say where downward route knowledge lives, how DAO or source-route evidence will be checked, and which packet tests would confirm the selected mode.

• Node roles: state why each device is root, router, or leaf.
• Parent evidence: connect advertised Rank, local increase, tie-break rule, and observed link behavior.
• Validation: name the DIO, DAO, route-state, and packet evidence that would prove the design.

A strong answer is therefore modest. It can say, “this topology is the intended design, and these are the observations needed before accepting it.” It should not say that delivery rate, latency, battery life, or repair behavior is proven unless the lab actually measured those claims. The discipline is the same one used in production review: each design choice has an assumption, an expected observation, and a retest trigger if the assumption changes.

Practitioner: Write The Design Record

Build the record in five columns: scenario assumption, design choice, expected control-plane evidence, expected route-state evidence, and packet test. That prevents a topology diagram from silently becoming a delivery claim. A DODAG can show upward orientation, but downward commands still need mode-specific DAO or route-state proof. Keep each row small enough that a reviewer can see the path from assumption to test without guessing which observation supports which claim.

Start the table before drawing the final DODAG. List the root, router candidates, leaf candidates, expected traffic directions, and any lab-provided constraints. Then draw the DODAG as the current hypothesis, not as the conclusion. For each router candidate, write the parent choices it can hear, the advertised Rank values you are using, the local increase or policy cost, and the rule for choosing among candidates. If a value is not supplied by the lab, label it as an assumption instead of filling in a realistic-looking number.

When a parent calculation ties, do not hide the tie. Record the two candidate Rank values, the local increases, the equal result, and the tie-break evidence you would need. Stability, parent-switch hysteresis, recent link observations, power constraints, and implementation policy are all legitimate fields when they are visible in the lab record. The important move is to avoid turning a tie into an unexplained preference. A tie is useful evidence because it tells the next test exactly what must be observed before the design can be defended.

Write the mode decision the same way. If telemetry dominates, Non-Storing mode may be a reasonable first candidate, but the record still needs root-held route knowledge and downward command tests. If local downward or peer paths matter, Storing mode may be easier to defend, but the router state and memory burden must be visible. Do not let the mode label carry the argument. The record should say which devices need state, which control messages should appear, and which packets will prove the claimed direction.

• Upward telemetry: prove parent choice and packet movement toward lower Rank.
• Downward commands: prove DAO or source-route state plus a packet test to the actuator group.
• Retest triggers: rerun the record after parent change, root change, link-quality shift, or mode change.

Finish by marking gaps explicitly. A row can be accepted, pending, or rejected, but it should not be vague. “Pending DAO evidence for actuator group” is better than “needs more testing” because it names the missing proof. That habit makes the lab answer useful after the exercise ends: another person can rerun the same checks, update the record, and see whether the design claim changed.

Under The Hood: Mode Choice Moves State

Storing and Non-Storing mode do not merely change a label in the design. They change where downward route knowledge lives and which proof is meaningful. In Storing mode, intermediate routers need descendant route state. In Non-Storing mode, the root must learn downward paths and carry source-route information for command traffic. The visible topology may look similar in both cases, but the evidence record is different because the route state is owned by different devices.

DIO evidence mainly supports discovery, compatibility, Rank, and parent selection. A node hears a DIO, evaluates the Objective Function, computes its candidate Rank, and chooses a parent under the implementation policy. That can explain why traffic should move upward toward the root. It still does not prove downward reachability, because a downward command needs the route information that points from the root side back to the destination. For that claim, the design must name the DAO or source-route evidence it expects.

In Storing mode, the reviewer should ask which routers hold descendant state and how a packet is forwarded hop by hop toward the target. If a constrained router is expected to store routes for many leaves, the record should call out that state burden instead of hiding it behind the DODAG. In Non-Storing mode, the reviewer should ask how the root learned the path and whether the source route used for the command matches the intended destination. The packet test is still required because route-state evidence and delivery evidence are related but not identical.

The same separation applies to repair and change. A parent change can leave the old design drawing looking mostly correct while invalidating the evidence behind a specific path. A root change can alter the DODAG ID, Rank expectations, and where route knowledge must be checked. A traffic-pattern change can make a previously acceptable mode choice weak. The under-the-hood lesson is that RPL state is directional and conditional: the design is current only for the stated root, mode, parent choices, and traffic pattern.

• DIO supports discovery, compatibility, Rank, and parent-choice evidence.
• DAO supports downward reachability claims.
• Packet tests prove that the selected path actually forwards in the tested condition.

When the lab asks for a validation record, it is really asking for this state model in checklist form. A good answer maps each claim to the RPL state that would support it, then names the packet test that would catch a wrong assumption. That is why the mode decision belongs near the traffic inventory, not at the end as a preference. Once traffic direction changes, the required state and proof change with it.

21.5 Prerequisites

• RPL Introduction and Motivation: why RPL fits LLNs.
• RPL Core Concepts: DODAG, Rank, DIO, DIS, DAO, and routing modes.
• RPL DODAG Construction: how parent choice and construction evidence are reviewed.
• RPL Routing Modes: Storing and Non-Storing route-state behavior.

21.6 Lab Scenario

Use this simplified building scenario. Treat every value as a lab assumption, not as a field guarantee.

• One border router acts as the DODAG root.
• Three floors each contain two mains-powered router candidates.
• Each floor also contains battery-powered sensing devices that should normally act as leaves.
• Floor 2 contains an actuator group that receives occasional commands from the root.
• Most traffic is telemetry from nodes toward the root.
• Peer traffic is rare and must be justified if the design depends on it.

Your deliverable is a one-page RPL design record with five parts:

1. Node roles and assumptions.
2. Draft DODAG and Rank direction.
3. Parent-choice evidence.
4. Traffic-direction and mode decision.
5. Validation checklist for the next lab or packet trace.

Figure 21.2: RPL network design lab workflow from the traffic story through node roles, DODAG draft, Rank review, mode choice, and validation evidence.

21.7 Task 1: Classify Node Roles

Start by assigning roles. Do not let every device become a router by default.

Root:

• Border router.
• Connects the constrained RPL domain to the wider IPv6 path.
• Owns the minimum Rank for this DODAG.

Router candidates:

• Mains-powered floor devices.
• Should have stable power and enough resources for RPL forwarding duties.
• Need link evidence before they are accepted as parents.

Leaf candidates:

• Battery-powered sensing devices.
• Should avoid forwarding traffic for other devices unless the scenario explicitly requires it.
• Still need upward route evidence to send telemetry.

Record the reason for each role. A good role decision mentions power profile, expected traffic direction, and whether the device needs to forward traffic for others.

21.8 Task 2: Draft The DODAG

Draft a DODAG that keeps the root visible and makes Rank direction obvious.

Figure 21.3: RPL DODAG rank assignment and lowest-rank parent selection

Run it: Before you settle the draft, watch the DODAG take shape in the Trickle timer workbench below. Start the root advertising DIOs and watch how the Trickle timer spreads them outward, slows down as the network stays consistent, and resets to fast advertising when you inject a change. Use it to reason about which DIOs each joining router actually hears and how quickly a new parent option would propagate, then add those observations to your DODAG draft notes.

Use the figure as a draft, then add evidence notes:

• Which router candidates can hear the root or an upstream router?
• Which DIO messages would each joining router need to hear?
• Which parent candidates are plausible for each floor?
• Which links are uncertain and need measurement?
• Which leaves should be attached to a floor router rather than forwarding for others?

Do not treat physical height or floor number as the Rank calculation. Rank comes from the selected parent and Objective Function. The floor layout only gives you an initial hypothesis.

21.9 Task 3: Calculate Candidate Rank

Use a small calculation to explain one parent decision.

Run it: Do the rank calculation by hand, then check your reasoning in the objective-function workbench below. Feed it the two candidate parents, switch between an OF0-style hop metric and an MRHOF-style link metric, and watch how the preferred parent and resulting rank change with the objective function you pick. When the snapshot ties, use the workbench to see which tie-break evidence – link stability or parent hysteresis – actually moves the decision, and record that reasoning below.

Assume Router F2-A hears two compatible DIO messages:

• Candidate Parent F3-A advertises Rank 256; local link or policy increase is 256.
• Candidate Parent F3-B advertises Rank 384; local link or policy increase is 128.

The simplified candidate calculation is:

via F3-A: 256 + 256 = 512
via F3-B: 384 + 128 = 512

The result is a tie in this snapshot. A complete answer should not choose randomly. Record the tie-break evidence you would use, such as stability, parent switch hysteresis, link observations, implementation policy, or a lab-provided preference rule.

Now repeat the same pattern for one leaf device:

1. List at least two candidate parents.
2. Write the advertised Rank for each parent.
3. Write the local link or policy increase.
4. Calculate candidate Rank.
5. State the preferred parent and the evidence that would confirm it.

21.10 Task 4: Choose The Routing Mode

Mode choice must follow traffic evidence.

Choose Storing mode when the design needs intermediate routers to hold descendant route state for downward or peer traffic and those routers can support that state.

Choose Non-Storing mode when constrained routers should keep less downward route state and the root can carry more route knowledge for downward traffic.

Figure 21.4: RPL routing mode evidence map showing traffic direction, route-state location, DAO evidence, and packet proof for Storing and Non-Storing decisions.

For this scenario, a defensible answer is:

• Primary telemetry: upward traffic toward the root.
• Occasional commands: root-to-actuator downward traffic.
• Peer traffic: rare and not the main design driver.
• Suggested mode: Non-Storing can be acceptable if the root has route knowledge and command traffic tolerates root-managed downward routing.
• Alternative: Storing can be justified if local command paths or peer paths become important and router memory is verified.

The key is not the selected mode alone. The key is the evidence you attach to the selected mode.

21.11 Task 5: Build The Validation Record

A lab design should end with the checks that would prove or disprove it.

Run it: One of the items below is a retest trigger for parent, root, or link-quality change – so watch that change actually happen in the local-repair animation below. Drop a preferred parent or a link and see how the affected node poisons its old rank, hunts for a new parent, and rejoins the DODAG, and how long traffic is disrupted while it does. Use what you see to write concrete retest triggers and the packet evidence that would prove repair, rather than a vague “handles failure” note.

Record these items:

• DODAG root identity, RPL instance, and DODAG ID.
• Objective Function used for Rank and parent selection.
• DIO evidence expected for each router joining step.
• Preferred parent for each router candidate.
• DAO evidence needed for downward command paths.
• Storing or Non-Storing mode and the route-state evidence expected for that mode.
• Packet tests for at least one upward telemetry path.
• Packet tests for at least one downward command path.
• Retest trigger for parent change, root change, or link-quality change.

21.12 Worked Design Record

For a concise lab answer, write something like this:

Root and roles:

• Border router is the DODAG root.
• F3-A, F3-B, F2-A, F2-B, F1-A, and F1-B are router candidates.
• Battery sensors are leaves unless the validation test shows a required forwarding role.

Rank and parents:

• F3 routers evaluate direct DIO evidence from the root.
• F2 routers evaluate F3 parents using advertised Rank plus local link or policy increase.
• F1 routers evaluate F2 parents using the same calculation.
• Leaf devices choose a floor router only after parent and link evidence are recorded.

Mode:

• Non-Storing is the first candidate because telemetry dominates and the root can manage downward route knowledge.
• Storing remains a fallback if local peer or command paths become a stronger requirement.

Validation:

• Capture DIO evidence for joining.
• Capture DAO or route-state evidence for downward commands.
• Run one upward and one downward packet test.
• Recheck parent choices after a simulated link degradation.

21.13 Common Mistakes

• Treating floor number as Rank without Objective Function evidence.
• Making all devices routers because they appear in the drawing.
• Choosing Storing or Non-Storing mode from node count alone.
• Claiming command delivery from an upward DODAG path.
• Forgetting DAO or route-state evidence for downward traffic.
• Using a tool screenshot as proof without recording the RPL state behind it.
• Adding exact lifetime, delivery-rate, or latency claims that the lab did not measure.
• Submitting only a diagram and no evidence record.

21.14 Knowledge Check

21.15 Matching Quiz

21.16 Ordering Quiz

21.17 Summary

This lab practices RPL design as an evidence workflow. A good answer classifies node roles, drafts the DODAG, calculates parent choices, selects a routing mode from traffic requirements, and states the validation checks needed before accepting the design. It avoids treating a topology diagram as proof of route reachability or packet delivery.

21.18 Key Takeaway

RPL network-design labs should record topology, objective function, parent choices, traffic needs, and repair expectations before judging the design.

21.19 Concept Relationships

• RPL Labs and Quiz places this lab in the broader practice sequence.
• RPL DODAG Construction explains how the draft DODAG becomes control-plane state.
• RPL DODAG Message Flow gives the DIO, DIS, DAO, and DAO-ACK evidence this lab asks you to record.
• RPL Routing Modes expands the Storing and Non-Storing mode decision.
• RPL Production and Review uses the same evidence boundary in production acceptance.

21.20 What’s Next

Continue with RPL Quiz Questions to test the lab concepts, or return to RPL Labs and Quiz to choose another practice path.