712 RPL Specification and Core Concepts
712.1 RPL Specification
- Standard: RFC 6550 (IETF, March 2012)
- Type: Distance-vector routing protocol
- Network Layer: IPv6 (works with 6LoWPAN)
- Topology: DODAG (Destination Oriented Directed Acyclic Graph)
- Metrics: Flexible (hops, ETX, latency, energy, etc.)
- Use Case: Low-power, lossy networks with many-to-one traffic patterns
712.2 Why Not Use Existing Routing Protocols?
Traditional routing protocols like OSPF, RIP, and AODV were designed for different network characteristics. They don’t work well for IoT because:
712.2.1 Processing, Memory, and Power Constraints
{fig-alt=“Comparison showing traditional router requirements (GHz CPU, GB RAM, watts power, complex tables) versus IoT sensor constraints (32 MHz CPU, 32 KB RAM, milliwatts battery, parent pointer only) highlighting incompatibility”}
Traditional Protocols Require: - Complex routing tables: OSPF maintains link-state database of entire network - Frequent updates: RIP sends entire routing table every 30 seconds - Heavy processing: Link-state algorithms (Dijkstra’s shortest path) - Power-hungry: Constant listening and periodic broadcasts
IoT Constraints: - Microcontroller: 8-32 MHz, single core - RAM: 10-128 KB (vs GB in traditional routers) - Flash: 32-512 KB (limited code and data storage) - Power: Milliwatts (battery-powered, years of operation)
712.2.2 Single Metric Not Always Appropriate
Traditional protocols use single metric: - RIP: Hop count only - OSPF: Cost (usually based on bandwidth)
IoT requires multiple, context-dependent metrics: - Latency: Real-time monitoring (industrial sensors) - Reliability: Critical data (medical devices) - Energy: Battery-powered devices (maximize lifetime) - Bandwidth: Mixed traffic (sensors + actuators)
RPL Solution: Supports objective functions with multiple metrics
712.2.3 Multiple Routing Instances
IoT Scenario: Single physical network, multiple applications
{fig-alt=“Multiple RPL instances on same physical network: Instance 1 optimizes for latency (temperature monitoring) with fast parent selection, Instance 2 optimizes for energy (firmware updates) with low-power parent selection”}
Example: - Instance 1: Temperature monitoring (minimize latency) - Instance 2: Firmware updates (minimize energy, can be slower) - Same devices, different routing decisions based on application
712.2.4 Point-to-Multipoint Traffic Patterns
Traditional networks: Assume peer-to-peer traffic
IoT networks: Predominantly many-to-one traffic - Many sensors → One gateway (cloud) - Data aggregation at root
RPL Optimization: Optimized for convergent traffic towards root
712.2.5 Lossy Links
Traditional networks: Assume reliable links (wired, enterprise Wi-Fi)
Low-Power and Lossy Networks (LLN): - High packet loss: 10-40% (vs < 1% wired) - Variable link quality: Interference, fading, obstacles - Asymmetric links: A can hear B, but B can’t hear A - Time-varying: Link quality changes over time
RPL Features for Lossy Networks: - Trickle timer: Adaptive control message frequency - ETX metric: Expected Transmission Count (accounts for retransmissions) - Loop avoidance: RANK prevents routing loops
712.3 RPL Core Concepts
712.3.1 Directed Acyclic Graph (DAG)
DAG = Directed Acyclic Graph
{fig-alt=“Directed Acyclic Graph (DAG) example showing nodes A through E connected with directed arrows flowing downward, demonstrating no cycles - cannot return to same node following edges”}
Key Properties: - Directed: Edges have direction (arrows) - Acyclic: No cycles (cannot return to same node following edges) - Graph: Nodes connected by edges
Why DAG? - Loop-free routing: By definition, no cycles = no routing loops - Hierarchical structure: Natural parent-child relationships - Efficient aggregation: Data flows towards root(s)
712.3.2 DODAG (Destination Oriented DAG)
RPL uses DODAG: DAG with single root (destination)
{fig-alt=“Destination Oriented Directed Acyclic Graph (DODAG) with single ROOT node at top (Rank 0), intermediate nodes at Rank 256 and 512, leaf nodes at Rank 768, all paths flowing toward root”}
DODAG Properties: - Single root: One destination (typically border router/gateway) - Upward routes: All paths lead to root - RANK: Position in DODAG hierarchy (root = 0, increases going down)
712.3.3 RANK: Loop Prevention Mechanism
RANK is a scalar representing a node’s position relative to the root.
{fig-alt=“RANK loop prevention mechanism showing ROOT at Rank 0, Node A at 100, B at 250, C at 370, with valid forward links and forbidden backward link from C to A that would create a loop”}
RANK Rules: 1. Root has RANK 0 (or minimum RANK) 2. RANK increases as you move away from root 3. Upward routing: Packets forwarded to nodes with lower RANK 4. Loop prevention: Node cannot choose parent with higher RANK
RANK Calculation:
RANK(node) = RANK(parent) + RankIncrease
RankIncrease calculated based on:
- Link cost (ETX, RSSI, etc.)
- Number of hops
- Energy consumed
- Objective function
Example:
ROOT: RANK = 0
Node A (parent: ROOT): RANK = 0 + 100 = 100
Node B (parent: Node A): RANK = 100 + 150 = 250
Node C (parent: Node B): RANK = 250 + 120 = 370
Loop Prevention: - Node C cannot choose Node A as parent (RANK 100 < 370 is OK) - Node A cannot choose Node C as parent (RANK 370 > 100 - would create loop)
RANK ≠ Hop Count (although hop count can be a factor)
RANK is calculated using objective function which may consider: - Hop count - Expected Transmission Count (ETX) - Latency - Energy consumption - Link quality (RSSI, LQI)
Example: - Good link, 1 hop: RANK increase = 100 - Poor link, 1 hop: RANK increase = 300 - Good link, 2 hops: RANK increase = 200
Node may prefer 2 hops via good links (total RANK increase: 200) over 1 hop via poor link (RANK increase: 300).
712.4 What’s Next
Continue to the next section to learn how DODAGs are actually constructed:
- RPL DODAG Construction: Step-by-step DODAG formation process
- RPL Routing Modes: Storing vs Non-Storing trade-offs
- RPL Summary and Tools: Common pitfalls and interactive demos
- RPL Overview: Return to fundamentals and introduction