47  Production RPL Framework and Review

In 60 Seconds

Production RPL framework covering DODAG construction, RANK calculation, parent selection, and trade-offs between Storing and Non-Storing modes for networks from 10 to 10,000+ nodes. Includes objective function selection (hop count, ETX, energy), Trickle timer tuning, and troubleshooting routing loops, convergence delays, and memory exhaustion.

47.1 Learning Objectives

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

  • Analyze RPL architecture: Deconstruct DODAG construction, RANK calculation, and parent selection mechanisms
  • Evaluate routing modes: Justify trade-offs between Storing and Non-Storing modes for different network sizes
  • Select objective functions: Choose appropriate metrics (hop count, ETX, energy) for IoT routing decisions
  • Design scalable networks: Architect RPL configurations for networks from 10 to 10,000+ nodes
  • Diagnose RPL issues: Troubleshoot common problems like routing loops, convergence delays, and memory exhaustion

The Sensor Squad Explains RPL Routing!

Imagine your neighborhood has hundreds of houses, but no street signs! How would mail get delivered?

RPL is like having smart mail carriers who figure out the best paths all by themselves:

DODAG Dan is the main post office (called the “root”). Every mail carrier knows which direction leads toward Dan - that’s the “upward” direction.

When Sammy the Sensor wants to send a message: 1. Sammy gives it to the nearest mail carrier (parent) 2. That carrier passes it “upward” to their parent 3. Eventually, it reaches DODAG Dan at the main office!

The RANK System: Each carrier has a number showing how many “hops” away they are from Dan: - Dan has RANK 0 (he IS the main office) - Carriers next to Dan have RANK 1 - Carriers 2 hops away have RANK 2 - And so on!

Why is this smart?

  • No carrier needs to remember the WHOLE neighborhood map
  • They just need to know: “Who’s my parent? Who’s closer to Dan?”
  • If one carrier gets sick, messages find another path automatically!

Fun Fact: RPL can handle 10,000+ devices sending messages - that’s like a mail system for a whole city using just neighbors talking to neighbors!

RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) solves a fundamental problem: How do thousands of tiny battery-powered sensors send data to a central gateway?

Why can’t we use regular internet routing?

  • Traditional protocols (OSPF, BGP) need lots of memory - sensors have only 32KB
  • They assume reliable links - wireless sensors lose 10-40% of packets
  • They’re designed for bidirectional traffic - sensors mostly send one-way

RPL’s clever solution:

  1. Build a tree (DODAG) with the gateway at the root
  2. Each node knows one thing: “Who’s my parent?” (the next hop toward root)
  3. Messages flow upward like water flowing downhill - always toward the root

Real-world analogy: In a corporate hierarchy, you don’t need to know the whole org chart. You just need to know your manager. If you want to reach the CEO, you tell your manager, who tells their manager, and so on.

Key benefit: A sensor with 32KB RAM can route messages in a 10,000-node network because it only stores 1-2 parent addresses, not 10,000 routes!

47.2 Production RPL Framework

This section provides a comprehensive production-ready Python framework for RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks), including DODAG construction, RANK calculation, Trickle timer, and both Storing and Non-Storing modes.

47.2.1 Framework Architecture

RPL Framework Architecture showing the relationship between DODAG Manager, Trickle Timer, Objective Functions, and Control Message handlers (DIO, DAO, DIS) with bidirectional data flows

This production framework provides comprehensive RPL protocol capabilities:

  • DODAG Construction: Distance-vector routing with RANK-based hierarchy, automatic parent selection
  • Trickle Timer: RFC 6206 implementation for adaptive DIO transmission (Imin to Imax intervals)
  • Routing Modes: Storing mode with distributed routing tables, non-storing mode support
  • Objective Functions: OF0 (hop count), MRHOF (ETX), Energy, Latency-based routing
  • Loop Prevention: RANK mechanism prevents routing loops, acyclic graph guaranteed
  • Control Messages: DIO (DODAG Information), DAO (Destination Advertisement), DIS, DAO-ACK
  • Traffic Patterns: Upward (many-to-one), downward (one-to-many), point-to-point routing
  • Network Repair: DODAG version increment for global topology changes
  • Parent Selection: Preferred parent with backup parent set for reliability

The framework demonstrates production-ready patterns for IPv6-based IoT networks with comprehensive statistics tracking, realistic link metrics, and complete DODAG lifecycle management.

47.3 Key Concepts

47.3.1 DODAG Construction Process

Step-by-step DODAG construction showing 4 phases: Root initialization broadcasting DIO, Tier 1 nodes joining and calculating RANK, Tier 2 nodes selecting parents, and final DODAG with all routes established

47.3.2 Core Terminology

Term Definition Importance
DODAG Destination Oriented Directed Acyclic Graph - tree topology with single root All upward paths lead to root
RANK Hierarchical position in DODAG Prevents routing loops, enables parent selection
Distance-Vector Each node knows next hop (parent), not entire topology Minimal memory requirements
Objective Function Algorithm for selecting best parent Pluggable metrics: hop count, energy, ETX
Preferred Parent Primary next-hop toward root Backup parents for fault tolerance

47.3.3 Control Messages

Message Direction Purpose
DIO (DODAG Information Object) Downward Advertise DODAG topology, trigger parent selection
DAO (Destination Advertisement Object) Upward Advertise reachability for downward routes (Storing mode)
DIS (DODAG Information Solicitation) Any Request DODAG info (orphan node joining)
DAO-ACK Downward Confirm DAO receipt

47.3.4 Routing Modes Comparison

Side-by-side comparison of Storing Mode where each router maintains routing tables versus Non-Storing Mode where only root maintains routes and uses source routing headers

Aspect Storing Mode Non-Storing Mode
Memory per node Higher (routing tables) Lower (parent only)
Downward routing Distributed decisions Source routing from root
P2P routing Optimal paths Via root
Best for Small networks (<300 nodes) Large networks (1000+ nodes)
Example Home automation Smart city streetlights

Quantifying Memory Requirements: Storing vs Non-Storing Mode

Consider an 800-node smart city streetlight network with 6-hop maximum depth.

Storing mode memory (each intermediate router stores sub-tree): \(\text{Nodes per subtree (avg)} = \frac{800}{6} \approx 133\) nodes \(\text{Entry size} = 16\text{ bytes (IPv6)} + 2\text{ bytes (next-hop)} + 2\text{ bytes (lifetime)} = 20\text{ bytes}\) \(\text{Routing table size} = 133 \times 20 = 2660\text{ bytes} \approx 2.6\text{ KB per router}\)

For a mid-level router (3 hops from root) with 4 children, each child having 30 descendants: \(\text{Total descendants} = 4 \times 30 + 4 = 124\) routes \(\text{Memory} = 124 \times 20 = 2480\text{ bytes}\)

Non-Storing mode memory: \(\text{Parent set} = 1\text{ preferred} + 3\text{ backups} = 4\) entries \(\text{Memory} = 4 \times 20 = 80\text{ bytes per router}\)

Root gateway stores full network: \(\text{Root memory} = 800 \times 20 = 16,000\text{ bytes} = 16\text{ KB}\)

For 64 KB RAM constrained sensors: Non-Storing saves 2.5 KB per router (97% reduction), enabling deployment on highly constrained devices. Root gateway (typically x86/ARM with 1+ GB RAM) easily handles 16 KB routing table.

47.3.5 Interactive: Memory Usage Calculator

Compare Storing vs Non-Storing mode memory requirements for your network size.

47.3.6 Additional Key Concepts

  • IPv6-Based: Native IPv6 protocol running over 6LoWPAN on IEEE 802.15.4 networks
  • Loop Prevention: DAG property and RANK mechanism guarantee acyclic routing, preventing loops
  • Many-to-One Traffic: Optimized for sensor networks where all data flows toward root gateway
  • Multiple Instances: Different RPL instances on same network support different applications/metrics
  • Lossy Link Support: Designed for 10-40% packet loss typical in wireless sensor networks
  • Scalability: Non-Storing mode scales to thousands of nodes; Storing mode optimizes for smaller networks
  • Trickle Timer: Adaptive control message timing - fast during changes, slow during stability

47.5 Objective Functions Deep Dive

RPL’s flexibility comes from its pluggable Objective Functions (OFs). The OF determines how nodes select parents and calculate RANK.

47.5.1 Objective Function Comparison

Comparison of three RPL Objective Functions: OF0 using hop count, MRHOF using ETX link quality metric, and custom Energy-based OF, showing different parent selection criteria

47.5.2 Standard Objective Functions

Objective Function RFC Metric Best For Limitations
OF0 RFC 6552 Hop count Simple networks, minimal computation Ignores link quality
MRHOF RFC 6719 ETX (Expected Transmission Count) Lossy networks, reliability-critical Higher computation
Energy-aware Custom Remaining battery Battery-constrained networks Requires energy monitoring
Latency-based Custom End-to-end delay Time-critical applications Complex measurement

47.5.3 Hysteresis in Parent Selection

MRHOF includes hysteresis to prevent frequent parent switching (churn):

Timeline showing how hysteresis prevents parent churn by requiring significant improvement before switching parents, avoiding oscillation between marginally different options

Why hysteresis matters:

  • Frequent parent switching causes routing table updates across the network
  • Each switch triggers DAO messages propagating upward
  • Excessive churn wastes battery and bandwidth
  • Hysteresis ensures switches only happen for significant improvements

47.6 Chapter Summary

RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is the IETF standard routing protocol designed specifically for IPv6-based IoT networks with resource-constrained devices, lossy wireless links, and convergent traffic patterns.

Unlike traditional routing protocols (OSPF, RIP) designed for wired networks with powerful routers, RPL addresses IoT’s unique challenges: - Limited resources: Sensors have <32 KB RAM, limited CPU, battery power - Lossy links: Wireless links lose 10-40% of packets; unreliable compared to wired networks - Traffic patterns: Most data flows toward a root gateway (convergent/many-to-one pattern), not uniformly across network - Multiple metrics: Performance depends on energy, latency, reliability - not just hop count

DODAG (Destination Oriented Directed Acyclic Graph) is RPL’s core concept. Instead of a full routing table, each node stores only its preferred parent(s). The DODAG forms a tree with a single root (typically the gateway). All upward paths eventually lead to root through parent pointers, creating a loop-free graph by design.

RANK is the hierarchical position in the DODAG. Root has RANK 0. Each node calculates its RANK based on parent’s RANK plus a metric. RANK enforces hierarchy - nodes never forward packets to higher-ranked nodes, preventing loops. This is simpler than count-to-infinity prevention used in traditional distance-vector protocols.

Parent selection is flexible. RPL computes the Objective Function (OF) - an algorithm combining multiple metrics (hop count, energy, ETX) to select the best parent. The protocol includes: - Objective Function Zero (OF0): Simple hop count minimization - Minimum Rank with Hysteresis Objective Function (MRHOF): Considers link quality (ETX) with hysteresis to prevent rapid parent switches

Nodes maintain a preferred parent (primary) and backup parent set for resilience. When preferred parent fails, nodes can quickly switch to backup, enabling self-healing mesh networks.

Control messages are ICMPv6-based: - DIO (DODAG Information Object): Root advertises DODAG; nodes forward DIO when joining DODAG. Contains RANK, Objective Function, DODAG ID - DIS (DODAG Information Solicitation): Orphaned node requests DODAG information to join network - DAO (Destination Advertisement Object): Node advertises reachability to upstream nodes (for downward routing in Storing mode) - DAO-ACK: Acknowledgment of DAO receipt

Two operational modes:

  1. Storing mode: Each node caches routing table with paths to other nodes; enables optimal point-to-point paths but requires more memory
  2. Non-Storing mode: Each node stores only parent pointer; downward routes use source routing (root specifies full path); saves memory

Upward routing (sensors → root) is identical in both modes: each node sends to parent. Downward routing (root → sensors) differs: Storing mode uses cached routes, Non-Storing uses source routing from root. Point-to-point routing (sensor ↔︎ sensor) uses upward path to common ancestor then downward path in Storing mode, or via root in Non-Storing mode.

Traffic patterns RPL optimizes for: - Many-to-one: Sensors report to gateway (most common); both modes identical - One-to-many: Gateway commands actuators; Storing better (optimal paths), Non-Storing uses source routing - Point-to-point: Device-to-device communication; Storing can optimize, Non-Storing routes via root

DODAG construction follows a multi-step process: 1. Root node sends DIO with RANK=0, establishes DODAG ID 2. Nodes receive DIO, calculate their own RANK, select preferred parent 3. Nodes send own DIO to propagate DODAG downward 4. Upward routes form automatically (parent pointers) 5. In Storing mode, nodes send DAO to advertise reachability upward 6. Downward routes created from DAO information

Network repair occurs when topology changes (links fail, nodes join/leave). RPL detects changes via loss of DIO from parent. Upon failure, node can quickly switch to backup parent. Global repairs happen via DODAG version increment from root.

Performance characteristics:

  • Memory: Non-Storing mode uses ~40% less network-wide memory
  • Latency: Storing mode better for point-to-point (optimal paths); identical for many-to-one
  • Scalability: Non-Storing scales better (limited by root CPU, not node memory); can handle thousands of nodes
  • Convergence: Faster than traditional distance-vector protocols; parent selection avoids count-to-infinity delays

Why RPL dominates IoT:

  • Standardized by IETF (RFC 6550, 2012)
  • Native IPv6, works with 6LoWPAN compression
  • Handles lossy, low-power networks inherently
  • Flexible metrics through pluggable Objective Functions
  • Proven in real-world deployments (Thread, many Zigbee implementations)
  • Works at Layer 3, protocol-agnostic at Link Layer (works over 802.15.4, Wi-Fi, etc.)

Use cases:

  • Smart home sensor networks (temperature, humidity, motion)
  • Industrial IoT monitoring (machines, energy, safety)
  • Smart city deployments (street lights, parking sensors, environmental monitoring)
  • Building automation (HVAC, lighting, access control)
  • Agriculture IoT (soil moisture, weather stations)
  • Any IPv6-based constrained network requiring self-healing mesh

47.7 Original Source Figures (Alternative Views)

The following figures from the CP IoT System Design Guide provide alternative visual representations of RPL operation concepts covered in this chapter.

RPL Storing Mode diagram showing how each router maintains routing table entries for downstream destinations, enabling optimal routing without involving root in every packet

RPL Storing Mode operation

RPL Non-Storing Mode diagram showing how root maintains all routing information and uses source routing headers to direct packets to leaf nodes, reducing memory requirements on constrained nodes

RPL Non-Storing Mode operation

Source: CP IoT System Design Guide, Chapter 4 - Routing

Visualization of multi-hop routing in RPL showing how packets traverse multiple intermediate nodes from source sensor to root gateway, with each hop making forwarding decisions based on parent selection

Multi-hop path in RPL network

Source: CP IoT System Design Guide, Chapter 4 - Routing

Four-step sequence showing RPL network formation: Step 1 root initialization, Step 2 DIO propagation to neighbors, Step 3 rank calculation and parent selection, Step 4 complete DODAG with established routes

RPL network formation steps 1-4

Source: CP IoT System Design Guide, Chapter 4 - Routing

47.8 Worked Example: Choosing Storing vs Non-Storing Mode for a Smart Parking Network

Scenario: A city deploys 2,000 magnetometer sensors embedded in parking spaces across a downtown area (2 km x 2 km). Each sensor detects vehicle presence and reports a 6-byte status (occupied/vacant + duration + battery level) every 30 seconds when status changes, or every 10 minutes when idle. Sensors form a 6LoWPAN mesh with 50 solar-powered relay nodes and 4 gateways. The system must support peer-to-peer queries (a driver’s app asks nearby sensors for vacancy) and upward data collection. Choose between Storing and Non-Storing RPL modes.

Step 1: Memory Requirements Analysis

Mode Per-Node Memory What’s Stored Calculation
Non-Storing 50 bytes (own parent only) Default route to parent Fixed regardless of network size
Storing 50 + (N x 20) bytes Routing table for subtree N = number of descendants

For this network with 2,000 sensors, 50 relays, and average subtree size of ~40 nodes per relay:

Relay memory in Storing mode:
  Routing entries: 40 descendants x 20 bytes/entry = 800 bytes
  Total: 50 + 800 = 850 bytes per relay

Sensor memory in Storing mode:
  Routing entries: 0-3 descendants x 20 bytes = 0-60 bytes
  Total: 50-110 bytes per sensor

Gateway memory in Non-Storing mode:
  Source routing table: 2,050 entries x 40 bytes = 82,000 bytes (~80 KB)
  This is fine -- gateways have 512 KB RAM

The parking sensors have 10 KB RAM (typical for magnetometer MCUs). Both modes fit comfortably in sensor memory. The question is whether relays can afford 850 bytes for routing tables.

Step 2: Peer-to-Peer Traffic Analysis

When a driver’s app queries “which spaces are vacant on Block 7?”, the query reaches the gateway, which must route it to Block 7’s sensors:

Mode P2P Path Hop Count Latency
Non-Storing Query goes UP to gateway, gateway adds source route header, query goes DOWN to target Up-hops + down-hops = ~8 hops total 8 x 10 ms = 80 ms
Storing Query goes UP to nearest common ancestor, then DOWN to target Up to common ancestor + down = ~4 hops 4 x 10 ms = 40 ms

Step 3: Source Routing Header Overhead

In Non-Storing mode, every downward packet from the gateway carries a source routing header listing each hop:

Source route to sensor 8 hops deep:
  Routing header: 4 bytes (fixed) + 8 x 16 bytes (IPv6 addresses) = 132 bytes
  6LoWPAN compression: 4 + 8 x 2 bytes (compressed) = 20 bytes
  Payload: 6 bytes (vacancy query)
  Total: 26 bytes

In Storing mode:
  No source routing header needed
  Payload: 6 bytes
  Per-hop IPv6 header: 8 bytes (compressed)
  Total: 14 bytes

For 2,000 sensors sending status updates upward, this overhead doesn’t apply (upward traffic uses default routes in both modes). But for the driver query use case (downward traffic), Non-Storing adds 12 extra bytes per query.

Step 4: Decision

Factor Non-Storing Storing Winner
Sensor memory 50 bytes 50-110 bytes Non-Storing (marginally)
Relay memory 50 bytes 850 bytes Non-Storing
P2P latency 80 ms (via gateway) 40 ms (direct ancestor) Storing
Downward overhead 20 bytes/packet (source route) 0 bytes Storing
Scalability Gateway handles all routes Distributed across relays Non-Storing
Gateway failure impact All P2P traffic fails P2P within subtree still works Storing

Recommendation: Storing mode for this deployment. The parking system’s peer-to-peer vacancy queries are latency-sensitive (drivers expect sub-second response) and frequent (potentially hundreds per hour in busy areas). Storing mode halves P2P latency and eliminates source routing overhead. The relay nodes are solar-powered with 32 KB RAM, so 850 bytes for routing tables is negligible. Non-Storing would be better for a pure data-collection network without P2P requirements.

Key Insight: The Storing vs Non-Storing decision depends on traffic patterns, not just network size. Pure many-to-one collection (sensors to gateway) favors Non-Storing because sensors need minimal memory and the gateway has ample resources. Any significant peer-to-peer or point-to-multipoint traffic (queries, commands, firmware updates) favors Storing because it avoids routing all traffic through the gateway bottleneck.

47.9 What’s Next

If you want to… Read this
Study the production deployment framework RPL Production Framework
Review specific deployment scenarios RPL Production Scenarios
Deep dive into RPL routing modes RPL Routing Modes
See the complete RPL summary RPL Production Summary

Now that you understand RPL’s design for IoT-specific routing, explore these related topics to deepen your knowledge:

Continue Learning

47.10 How It Works

  1. Network Design: Map physical topology, count nodes, measure hop depth
  2. Mode Selection: Use decision framework (RAM budget + traffic pattern analysis)
  3. Objective Function Choice: OF0 for reliable links, MRHOF for lossy environments
  4. Configuration: Set RPL_CONF_MOP, objective function, Trickle parameters in firmware
  5. Pilot Testing: Deploy 10-20 nodes, measure convergence time and control overhead
  6. Production Rollout: Deploy full network, monitor PDR and parent switch frequency
  7. Ongoing Tuning: Adjust Trickle Imax based on observed network stability
// project-conf.h
#define RPL_CONF_MOP RPL_MOP_NON_STORING  // Large network, many-to-one traffic
#define RPL_CONF_OF rpl_mrhof              // Lossy indoor environment
#define RPL_CONF_DIO_INTERVAL_MIN 10       // 10ms Imin
#define RPL_CONF_DIO_INTERVAL_DOUBLINGS 16 // ~10 min Imax

// Verify memory budget
Static routing table size: 0 bytes (Non-Storing mode)
Parent selection state: ~200 bytes
DIO buffer: ~80 bytes
Total RPL overhead: <500 bytes (acceptable for 32KB RAM)

47.11 Concept Check

  1. Storing mode + OF0 (fast P2P, simple metric)
  2. Storing mode + MRHOF (distributed routing, reliable)
  3. Non-Storing mode + OF0 (low memory, simple metric)
  4. Non-Storing mode + MRHOF (low memory, reliable)
Click to see answer

47.12 Concept Relationships

This comprehensive production guide synthesizes all RPL concepts:

  • RPL Fundamentals provides the DODAG, RANK, and control message theory implemented here
  • RPL Operation details the Trickle timer and parent selection algorithms configured in production
  • RPL Labs offers hands-on practice with the design decisions applied in real deployments
  • Network Topologies explains how RPL’s tree-based DODAG relates to star and mesh alternatives
  • Thread Operation demonstrates Google/Apple’s production RPL optimization patterns

47.13 See Also

Common Pitfalls

In Non-Storing Mode, all downlink traffic passes through the root, which must compute and insert source routing headers. For large networks with frequent downlink traffic, this creates a significant root bottleneck. Calculate expected root processing load before committing to Non-Storing Mode.

Production networks must handle temporary network partitions (RF interference, physical blockage). Test that your RPL configuration correctly implements floating DODAG behavior and recovers gracefully when connectivity is restored.

In Storing Mode, each router maintains routes to all its descendants. For a node with 30 descendants, this requires 30 routing table entries × ~10 bytes = 300 bytes minimum — significant on 4 KB RAM devices. Calculate per-node routing table memory requirements.

47.14 Summary

RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is the standard routing protocol for IoT:

Key Takeaways

  • DODAG: Destination Oriented Directed Acyclic Graph (tree toward root)

  • RANK: Hierarchical position (prevents loops, enables upward routing)

  • Distance-Vector: Each node knows next hop (parent), not entire network

  • IPv6-based: Works with 6LoWPAN for constrained devices

  • Resource constraints: IoT devices lack CPU, RAM, power for OSPF/RIP

  • Multiple metrics: RPL supports flexible objective functions (latency, energy, ETX)

  • Multiple instances: Different routing for different applications on same network

  • Lossy links: RPL designed for 10-40% packet loss

  • Traffic patterns: Optimized for many-to-one (sensors → gateway)

  • DIO: DODAG Information Object (advertise DODAG)

  • DIS: DODAG Information Solicitation (request DODAG info)

  • DAO: Destination Advertisement Object (advertise reachability)

  • DAO-ACK: DAO Acknowledgment (confirm receipt)

  • Storing: Distributed routing tables (optimal paths, higher memory)

  • Non-Storing: Centralized routing at root (source routing, lower memory)

  • Many-to-One (upward): Sensors → Root (most common, both modes identical)

  • One-to-Many (downward): Root → Actuators (Storing optimal, Non-Storing via source routing)

  • Point-to-Point: Sensor ↔︎ Sensor (Storing can optimize, Non-Storing via root)

  1. Root sends DIO (RANK 0, DODAG ID)
  2. Nodes receive DIO, calculate RANK, select parent
  3. Nodes send DIO (propagate DODAG)
  4. Upward routes automatic (parent pointers)
  5. Downward routes via DAO (Storing mode)

  • DAG property: Acyclic by definition

  • RANK mechanism: Enforces hierarchy, prevents routing to higher RANK

  • No count-to-infinity: RANK bounds prevent infinite loops

  • Storing: Devices with >32 KB RAM, low latency needed, P2P common

  • Non-Storing: Battery devices <16 KB RAM, many-to-one primary, large networks

  • Memory: Non-Storing ~40% less network-wide

  • Latency: Storing better for P2P, identical for many-to-one

  • Scalability: Non-Storing scales to more nodes (limited by root, not node memory)

  • Smart home sensor networks (temperature, motion)

  • Industrial IoT monitoring

  • Smart city deployments (street lights, parking)

  • Building automation

  • Any IPv6-based constrained network (6LoWPAN, Thread)

  • RFC 6550: RPL specification (IETF, 2012)

  • RFC 6552: Objective Function Zero (OF0, hop count)

  • RFC 6719: Minimum Rank with Hysteresis Objective Function (MRHOF)

RPL is the de facto standard for routing in IPv6-based IoT networks, providing efficient, scalable routing optimized for resource-constrained devices in lossy networks with convergent traffic patterns.

Previous: RPL Overview Next: RPL Production and Review