3  Routing Fundamentals Overview

In 60 Seconds

Routing is the process of selecting paths for data packets to travel across networks, with routers consulting routing tables to determine the best next hop for each packet. IoT networks add unique challenges – low-power devices, lossy wireless links, and mesh topologies – requiring specialized protocols like RPL that optimize for energy efficiency and constrained memory.

3.1 Learning Objectives

By completing this routing fundamentals series, you will be able to:

• Explain Routing: Describe how routing implements packet switching across interconnected networks
• Analyze Router Function: Explain how routers make forwarding decisions using routing tables
• Configure Routing Tables: Build routing table entries with appropriate next hops and metrics
• Distinguish Route Types: Differentiate between connected, static, and dynamic routes
• Apply TTL Concept: Calculate how Time-To-Live prevents routing loops and aids diagnostics
• Design IoT Routing: Implement routing for constrained IoT networks using RPL and other protocols

Minimum Viable Understanding

• Routing is the process of selecting paths for data packets to travel from source to destination across one or more networks; routers examine destination addresses and consult routing tables to determine the next hop.
• Routing tables are the core data structure: each entry maps a destination network to a next-hop address, an outgoing interface, and a cost metric. Tables are built by static configuration or dynamic routing protocols (RIP, OSPF, BGP, RPL).
• IoT routing introduces unique constraints: low-power devices, lossy wireless links, and mesh topologies require specialized protocols like RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) that optimize for energy, reliability, and constrained memory.

3.2 Introduction

Routing is fundamental to how data travels across networks, from IoT sensors through mesh networks to cloud servers. Every time a sensor reading leaves a device and arrives at a cloud dashboard, it has traversed a chain of routing decisions – each router along the path independently choosing the best next hop.

This comprehensive guide has been organized into focused chapters to help you master routing concepts progressively, from basic definitions through to IoT-specific protocols.

Sensor Squad: The Great Message Relay

Sammy the Temperature Sensor needs to send a reading to the cloud, but the cloud is far, far away! Imagine Sammy is in one corner of a huge school building, and the principal’s office (the cloud) is on the opposite side.

Sammy can’t walk there – sensors stay in place! So Sammy hands the message to Lila the Router, who is like a hallway monitor. Lila looks at her special notebook (her routing table) and says: “Messages going to the principal? I should pass them to Max in the next corridor!”

Max the Router gets the message and checks his notebook: “Principal’s office? That goes through Bella near the gym!” Bella gets it and can deliver it directly to the principal.

Here’s the cool part: None of the hallway monitors know the whole route. They only know the next step. That’s how routing works – each router just knows who to hand the message to next, like a relay race!

What if a hallway is blocked by a spilled bucket of paint? The monitors update their notebooks and find a different path. That’s why routing is so smart – it can work around problems!

For Beginners: What is Routing?

Think of routing like a postal system for data packets.

When you mail a letter, you don’t plan the exact route it takes. You put an address on it and drop it in a mailbox. At each sorting office along the way, workers look at the address and decide where to send it next. Your letter may pass through several offices before reaching its destination.

Routing in computer networks works the same way:

1. A data packet has a destination address (like an IP address)
2. Each router it encounters looks at this address
3. The router checks its routing table – a list that says “for destination X, send to next-hop Y”
4. The packet moves one hop closer to its destination

Three things to remember:

• Routers are the decision-makers at each junction
• Routing tables are the maps routers use to make decisions
• Routing protocols are the way routers share information to keep their maps up to date

You don’t need to understand all the math and algorithms yet. Start with the concept that routing is about making hop-by-hop forwarding decisions, and the rest will build naturally.

3.3 Prerequisites

Before starting this series, you should be familiar with:

• Networking Basics: Understanding fundamental networking concepts including IP addressing and packet switching
• Layered Network Models: Knowledge of the OSI and TCP/IP models helps you understand where routing operates (Network Layer)

Key Concepts

• Routing: The process of determining the path that network packets should follow from source to destination, typically using a routing protocol to build and maintain routing tables.
• Forwarding: The act of receiving a packet on one interface and transmitting it out another interface toward the destination, based on the routing table.
• Dynamic Routing Protocol: A protocol that automatically exchanges topology information between routers to build and maintain routing tables without manual configuration (e.g., OSPF, RIP, RPL).
• Link-State Routing: A routing approach where each router builds a complete map of the network topology and computes shortest paths using Dijkstra’s algorithm (e.g., OSPF, IS-IS).
• Distance-Vector Routing: A routing approach where each router knows only the direction and distance to destinations, sharing routing table entries with neighbors (e.g., RIP, RPL).

3.4 Chapter Organization

Recommended Reading Order

Follow these chapters in sequence for the best learning experience, or jump to specific topics as needed.

Chapter	Topic	Focus
Routing Basics	What is Routing?	Definitions, router operation, forwarding decisions
TTL and Loop Prevention	Time-To-Live	Preventing routing loops, IPv4/IPv6 headers, traceroute
Routing Tables	Tables and Types	Route structure, connected/static/dynamic routes, protocols
Packet Switching	Dynamic Routing	Failover, metrics, real-world packet journeys
IoT Routing	IoT-Specific Routing	RPL, common mistakes, failure scenarios
End-to-End Connectivity	Putting It Together	Requirements, worked examples, protocol selection

3.5 The Challenge: Finding Paths in Complex Networks

Networks can have millions of possible paths. Each router only sees its immediate neighbors, and there is no central authority that knows the complete network topology. Networks evolve continuously as links fail and devices join or leave.

The Solution: Routing protocols that collaboratively build and maintain routing tables across the network. These protocols exchange information between neighbors, compute optimal paths, and adapt to changes – all without requiring global network knowledge at any single point.

In IoT networks, this challenge is amplified by resource constraints, lossy wireless links, and the need for energy-efficient operation.

3.6 Key Routing Concepts at a Glance

The following diagram summarizes the core concepts you will encounter throughout this chapter series:

3.7 Worked Example: Tracing a Sensor Reading Across a Network

Let us walk through a concrete scenario to see how routing concepts come together in practice.

Scenario: A temperature sensor in a smart factory sends a reading (25.3 °C) to a cloud monitoring dashboard. The sensor is connected to a local mesh network, which connects through a gateway to the corporate LAN, which then routes to the internet.

Network Layout:

Device	IP Address	Role
Temperature Sensor	fd00::10	Source (6LoWPAN mesh)
Mesh Router 1	fd00::2	Intermediate (mesh network)
Border Router / Gateway	fd00::1 / 192.168.1.1	Mesh-to-LAN bridge
Corporate Router	192.168.1.254	LAN-to-Internet
Cloud Server	203.0.113.50	Destination

Step-by-Step Packet Journey:

1. Sensor (fd00::10) creates a packet with destination 203.0.113.50. Its routing table has a default route pointing to Mesh Router 1 (fd00::2). Hop Limit is set to 64.
2. Mesh Router 1 (fd00::2) receives the packet, decrements Hop Limit to 63, looks up the destination in its routing table, and forwards to the Border Router (fd00::1).
3. Border Router decompresses the 6LoWPAN headers to full IPv6, then performs NAT64 translation to IPv4 before forwarding to the Corporate Router at 192.168.1.254. Hop Limit / TTL is now 62.
4. Corporate Router has a default route pointing to its ISP. It forwards the packet onto the internet. TTL is decremented to 61.
5. The packet traverses several ISP routers (each decrementing TTL), following BGP-determined paths.
6. Cloud Server (203.0.113.50) receives the packet, extracts the sensor reading (25.3 °C), and displays it on the dashboard.

Key Observations:

• Each router made an independent forwarding decision using only its local routing table
• The Hop Limit / TTL decreased at every hop, preventing infinite loops
• The Border Router handled protocol translation between the IoT mesh and traditional IP networks
• No single device knew the complete end-to-end path

Putting Numbers to It: Packet Forwarding Latency Breakdown

Let’s calculate the total end-to-end latency for this sensor reading packet and identify bottlenecks.

Latency Components per Hop: \[ T_{\text{hop}} = t_{\text{transmission}} + t_{\text{propagation}} + t_{\text{processing}} + t_{\text{queuing}} \]

Transmission delay (packet on wire): \[ t_{\text{transmission}} = \frac{L_{\text{packet}}}{R_{\text{link}}} \] Where \(L_{\text{packet}} = 100\) bytes (sensor reading with headers), $R_{} = $ link rate.

6LoWPAN mesh link (802.15.4, 250 kbps): \[ t_{\text{trans-mesh}} = \frac{100 \times 8}{250,000} = 3.2 \text{ ms} \]

Ethernet LAN (100 Mbps): \[ t_{\text{trans-lan}} = \frac{100 \times 8}{100 \times 10^6} = 0.008 \text{ ms} \]

Processing delay (routing table lookup, TTL decrement):

• IoT mesh router: \(t_{\text{proc-iot}} = 5\) ms (constrained CPU, software routing)
• Enterprise router: \(t_{\text{proc-ent}} = 0.1\) ms (hardware forwarding)

Propagation delay (electromagnetic wave travel): \[ t_{\text{propagation}} = \frac{d}{c} \] Where \(d\) = distance, \(c = 2 \times 10^8\) m/s (fiber). For LAN/Internet links (10 km avg): \(t_{\text{prop}} \approx 0.05\) ms (negligible).

Total End-to-End Latency: | Hop | Type | Trans (ms) | Proc (ms) | Queue (ms) | Total (ms) | |—–|——|———–|———-|———–|————-| | Sensor → Mesh Router | 6LoWPAN | 3.2 | 5 | 2 | 10.2 | | Mesh Router → Border Router | 6LoWPAN | 3.2 | 5 | 2 | 10.2 | | Border Router | Translation | - | 10 | 5 | 15 | | Corp Router → Internet | Ethernet | 0.008 | 0.1 | 1 | 1.1 | | ISP routers (5 hops) | Fiber | 0.005 | 0.1 | 0.5 | 3 (total) |

\[ T_{\text{total}} = 10.2 + 10.2 + 15 + 1.1 + 3 = 39.5 \text{ ms} \]

Bottleneck Analysis: The two 6LoWPAN mesh hops contribute 20.4 ms (52% of total latency) despite being the first two hops. This is typical for IoT networks – the constrained wireless edge dominates end-to-end latency.

Try It: Packet Transmission Delay Calculator

Adjust the packet size and link rate to see how transmission delay changes across different network technologies. Notice how constrained IoT links (like 802.15.4 at 250 kbps) produce dramatically higher delays than wired links.

viewof packetSize = Inputs.range([20, 1500], {value: 100, step: 10, label: "Packet size (bytes)"})
viewof linkType = Inputs.select(
  ["802.15.4 (250 kbps)", "BLE (1 Mbps)", "LoRa (50 kbps)", "Wi-Fi (54 Mbps)", "Ethernet 100M", "Ethernet 1G", "Fiber 10G"],
  {value: "802.15.4 (250 kbps)", label: "Link technology"}
)

linkRates = ({
  "802.15.4 (250 kbps)": 250000,
  "BLE (1 Mbps)": 1000000,
  "LoRa (50 kbps)": 50000,
  "Wi-Fi (54 Mbps)": 54000000,
  "Ethernet 100M": 100000000,
  "Ethernet 1G": 1000000000,
  "Fiber 10G": 10000000000
})

txDelay = (packetSize * 8) / linkRates[linkType]
txDelayMs = txDelay * 1000
txDelayUs = txDelay * 1000000

html`<div style="background: linear-gradient(135deg, #2C3E50 0%, #16A085 100%); color: white; padding: 20px; border-radius: 8px; font-family: Arial, sans-serif; margin-top: 10px;">
  <div style="font-size: 14px; opacity: 0.9; margin-bottom: 8px;">
    <strong>Formula:</strong> t = L / R = ${packetSize} bytes x 8 bits / ${(linkRates[linkType] / 1000).toLocaleString()} kbps
  </div>
  <div style="font-size: 28px; font-weight: bold; margin: 12px 0;">
    ${txDelayMs >= 1 ? txDelayMs.toFixed(3) + " ms" : txDelayUs.toFixed(2) + " \u00B5s"}
  </div>
  <div style="display: flex; gap: 20px; margin-top: 12px; font-size: 13px;">
    <div style="background: rgba(255,255,255,0.15); padding: 8px 12px; border-radius: 4px;">
      <strong>Packet bits:</strong> ${(packetSize * 8).toLocaleString()}
    </div>
    <div style="background: rgba(255,255,255,0.15); padding: 8px 12px; border-radius: 4px;">
      <strong>Link rate:</strong> ${linkRates[linkType] >= 1e9 ? (linkRates[linkType] / 1e9) + " Gbps" : linkRates[linkType] >= 1e6 ? (linkRates[linkType] / 1e6) + " Mbps" : (linkRates[linkType] / 1000) + " kbps"}
    </div>
    <div style="background: rgba(255,255,255,0.15); padding: 8px 12px; border-radius: 4px;">
      <strong>IoT impact:</strong> ${txDelayMs > 1 ? "High (constrained link)" : txDelayMs > 0.01 ? "Moderate" : "Negligible"}
    </div>
  </div>
  <div style="margin-top: 12px; font-size: 12px; opacity: 0.8;">
    ${txDelayMs > 1 ? "This delay is significant for IoT devices -- consider fragmentation or compression." : "This delay is small enough for most IoT applications."}
  </div>
</div>`

Common Pitfalls in Routing

Avoid these frequently encountered mistakes when working with routing:

1. Confusing Routing with Forwarding: Routing is the process of building and maintaining routing tables (control plane). Forwarding is the act of moving a packet from an input interface to an output interface based on those tables (data plane). They are related but distinct operations.

2. Assuming Global Knowledge: No single router knows the entire network topology. Each router makes decisions based on its local routing table. Designing systems that assume centralized path knowledge will fail in distributed networks.

3. Ignoring TTL / Hop Limit: Forgetting to set appropriate TTL values leads to packets circulating endlessly in routing loops, consuming bandwidth and battery power on constrained IoT devices. Always verify TTL behavior during testing.

4. Using Static Routes in Dynamic IoT Networks: Static routes are simple and predictable, but IoT mesh networks have nodes that frequently join, leave, or move. Using only static routes means the network cannot adapt to topology changes.

5. Overlooking Asymmetric Paths: The path from A to B may differ from the path from B to A. This is common in IoT networks where link quality varies by direction. Always test bidirectional connectivity, not just one-way reachability.

6. Treating All Links as Equal Cost: In IoT networks, link quality varies dramatically. A routing metric that only counts hop count may choose a 3-hop path with terrible links over a 4-hop path with excellent links. Use composite metrics (ETX, energy, latency) for IoT routing.

3.8 Knowledge Check

Test your understanding of routing fundamentals before diving into the detailed chapters.

## Quick Navigation

Start Here: Routing Basics – Begin with fundamental concepts

For IoT Focus: IoT Routing – Jump directly to IoT-specific content

Hands-On Practice: Routing Labs and Quiz – Test your knowledge with practical exercises

Match: Routing Fundamentals Overview

Order: Sensor Reading Journey to Cloud

🏷️ Label the Diagram

Code Challenge

3.9 Summary

Routing is the backbone of all networked communication, determining how packets travel from source to destination across potentially complex, multi-hop networks. In this overview chapter, we established the following key points:

Concept	Key Takeaway
Routing vs Forwarding	Routing builds tables (control plane); forwarding uses them to move packets (data plane)
Routing Tables	Map destination networks to next-hop addresses, interfaces, and cost metrics
TTL / Hop Limit	Prevents infinite loops by limiting packet lifetime; decremented at each hop
Routing Protocols	Enable routers to share information and compute paths collaboratively (RIP, OSPF, BGP, RPL)
IoT Constraints	Low power, lossy links, limited memory, and dynamic topologies require specialized protocols like RPL
Composite Metrics	IoT routing should use metrics beyond hop count (ETX, energy, latency) for reliable operation

The six chapters in this series progressively build your understanding from basic definitions through to IoT-specific implementations. Each chapter includes worked examples, knowledge checks, and practical exercises to reinforce learning.

Decision Framework: Choosing a Routing Protocol for Your IoT Network

Use this framework to select the optimal routing protocol based on your IoT network characteristics:

Network Characteristic	RIP	OSPF	RPL	Static Routes
Scale: < 50 nodes	✓ Acceptable	⊗ Overkill	✓✓ Optimal	✓ If topology stable
Scale: 50-500 nodes	⊗ Too slow	✓✓ Optimal	✓ Good	⊗ Unmanageable
Scale: > 500 nodes	⊗ Max 15 hops	✓✓ Excellent	⊗ DODAG depth limits	⊗ Impossible
Battery-powered devices	⊗ High overhead	⊗ CPU intensive	✓✓ Designed for	✓ Zero overhead
Lossy wireless links (>10% loss)	⊗ Slow convergence	⊗ LSA flooding issues	✓✓ ETX-aware	⊗ Can’t adapt
Constrained memory (< 128 KB RAM)	✓ Low memory	⊗ Stores full topology	✓✓ DODAG only	✓✓ Minimal
Dynamic topology (frequent changes)	⊗ 30-90s convergence	✓ Sub-second	✓ 5-30s typical	⊗ Manual updates
Wired Ethernet backbone	⊗ Outdated	✓✓ Industry standard	N/A	✓ Simple setups
Mesh sensor network	⊗ Not suitable	⊗ Not suitable	✓✓ Designed for	⊗ Can’t handle mesh
Many-to-one traffic (sensors → gateway)	⊗ Inefficient	⊗ General-purpose	✓✓ DODAG optimized	⊗ Each node needs route

Legend: ✓✓ Excellent fit | ✓ Acceptable | ⊗ Poor fit | N/A Not applicable

Example Decision Path:

Scenario 1: Smart Home (15 devices, battery-powered, Wi-Fi mesh)

• Scale: < 50 nodes ✓ RPL or Static
• Battery-powered ✓✓ RPL
• Wireless mesh ✓✓ RPL
• Recommendation: RPL with ETX metric for link quality awareness

Scenario 2: Industrial Automation (200 PLCs, wired Ethernet, real-time control)

• Scale: 50-500 nodes ✓✓ OSPF
• Wired backbone ✓✓ OSPF
• Real-time needs ✓ OSPF (fast convergence)
• Recommendation: OSPF with BFD for sub-second failover detection

Scenario 3: Agricultural Sensors (500 devices, solar-powered, LoRaWAN)

• Scale: > 500 nodes ⊗ RPL DODAG depth limits
• Battery/solar-powered ✓✓ RPL or Static
• LoRaWAN star topology → No mesh routing needed
• Recommendation: Static routes (LoRaWAN handles MAC-layer routing to gateway)

Scenario 4: Office Building (8 floors, 50 sensors/floor, stable deployment)

• Scale: 400 nodes → Could use OSPF or RPL
• Topology stable (wired backbone to floor gateways)
• Budget-conscious deployment
• Recommendation: Static routes from sensors to floor gateway + OSPF on wired backbone between gateways

Key Decision Factors:

1. Device constraints (battery, memory) → RPL if constrained, OSPF if abundant resources
2. Network stability → Static if rarely changes, dynamic if frequent topology updates
3. Traffic pattern → RPL optimal for many-to-one, OSPF for any-to-any
4. Convergence time requirements → OSPF fastest (<1s with BFD, seconds without), RPL moderate (5-30s), RIP slow (30-90s)

Try It: IoT Routing Protocol Selector

Select your network characteristics to get a routing protocol recommendation. This interactive tool applies the decision framework above to your specific scenario.

viewof nodeCount = Inputs.select(
  ["< 50 nodes", "50-500 nodes", "> 500 nodes"],
  {value: "< 50 nodes", label: "Network scale"}
)
viewof powerSource = Inputs.select(
  ["Battery-powered", "Mains-powered", "Solar/energy harvesting"],
  {value: "Battery-powered", label: "Power source"}
)
viewof linkQuality = Inputs.select(
  ["Reliable wired", "Moderate wireless (<5% loss)", "Lossy wireless (>10% loss)"],
  {value: "Lossy wireless (>10% loss)", label: "Link quality"}
)
viewof topologyChange = Inputs.select(
  ["Rarely changes", "Occasional changes", "Frequent changes"],
  {value: "Frequent changes", label: "Topology dynamics"}
)
viewof trafficPattern = Inputs.select(
  ["Many-to-one (sensors to gateway)", "Any-to-any", "One-to-many (commands to devices)"],
  {value: "Many-to-one (sensors to gateway)", label: "Traffic pattern"}
)

protocolScore = {
  let scores = {RPL: 0, OSPF: 0, RIP: 0, Static: 0};
  // Scale
  if (nodeCount === "< 50 nodes") { scores.RPL += 3; scores.Static += 2; scores.RIP += 1; }
  else if (nodeCount === "50-500 nodes") { scores.OSPF += 3; scores.RPL += 2; }
  else { scores.OSPF += 3; }
  // Power
  if (powerSource === "Battery-powered" || powerSource === "Solar/energy harvesting") { scores.RPL += 3; scores.Static += 2; }
  else { scores.OSPF += 2; scores.RPL += 1; }
  // Link quality
  if (linkQuality === "Reliable wired") { scores.OSPF += 3; scores.Static += 1; }
  else if (linkQuality === "Moderate wireless (<5% loss)") { scores.RPL += 2; scores.OSPF += 1; }
  else { scores.RPL += 3; }
  // Topology
  if (topologyChange === "Rarely changes") { scores.Static += 3; scores.OSPF += 1; }
  else if (topologyChange === "Occasional changes") { scores.OSPF += 2; scores.RPL += 2; }
  else { scores.RPL += 2; scores.OSPF += 2; }
  // Traffic
  if (trafficPattern === "Many-to-one (sensors to gateway)") { scores.RPL += 3; }
  else if (trafficPattern === "Any-to-any") { scores.OSPF += 2; }
  else { scores.RPL += 1; scores.OSPF += 1; }
  return scores;
}

bestProtocol = {
  let best = "RPL";
  let max = 0;
  for (let p of Object.keys(protocolScore)) {
    if (protocolScore[p] > max) { max = protocolScore[p]; best = p; }
  }
  return best;
}

protocolColors = ({RPL: "#16A085", OSPF: "#3498DB", RIP: "#E67E22", Static: "#7F8C8D"})

protocolDescriptions = ({
  RPL: "RPL is optimized for constrained IoT networks with many-to-one traffic patterns, lossy links, and battery-powered devices.",
  OSPF: "OSPF provides fast convergence and scalability for wired or well-resourced networks with any-to-any traffic.",
  RIP: "RIP is simple but limited -- consider RPL for IoT or OSPF for enterprise.",
  Static: "Static routes are ideal for small, stable networks with predictable topology."
})

maxScore = Math.max(...Object.values(protocolScore))

html`<div style="background: #f8f9fa; border: 2px solid ${protocolColors[bestProtocol]}; border-radius: 8px; padding: 20px; font-family: Arial, sans-serif; margin-top: 10px;">
  <div style="font-size: 16px; font-weight: bold; color: ${protocolColors[bestProtocol]}; margin-bottom: 12px;">
    Recommended: ${bestProtocol}
  </div>
  <div style="font-size: 13px; color: #2C3E50; margin-bottom: 16px;">
    ${protocolDescriptions[bestProtocol]}
  </div>
  <div style="display: flex; gap: 8px; flex-wrap: wrap;">
    ${Object.entries(protocolScore).map(([name, score]) =>
      `<div style="flex: 1; min-width: 100px; text-align: center; padding: 10px; border-radius: 6px; background: ${name === bestProtocol ? protocolColors[name] : '#e9ecef'}; color: ${name === bestProtocol ? 'white' : '#2C3E50'};">
        <div style="font-weight: bold; font-size: 14px;">${name}</div>
        <div style="font-size: 22px; font-weight: bold; margin: 4px 0;">${score}</div>
        <div style="font-size: 11px; opacity: 0.8;">score / ${maxScore}</div>
      </div>`
    ).join("")}
  </div>
</div>`

Concept Relationships

Prerequisites:

• Networking Basics → IP addressing, packet structure, network layers
• Layered Models → Understanding OSI/TCP-IP Layer 3 (Network Layer)

Builds Toward:

• Transport Protocols → TCP/UDP build on routing for end-to-end delivery
• RPL Protocol → IoT-specific routing implementation
• Network Security → Secure routing and route authentication

Relates To:

• Network Topologies → Star, mesh, tree impact routing design
• WSN Architecture → Wireless sensor network routing strategies
• 6LoWPAN → IPv6 routing in constrained networks

See Also

Chapter Series:

• Routing Basics - Start here for fundamentals
• TTL and Loop Prevention - Preventing infinite loops
• Routing Tables - Route types and lookup

Related Modules:

• RPL Fundamentals - Low-power IoT routing
• Network Topologies - Topology impact on routing
• 6LoWPAN - Routing over constrained links

Standards:

• RFC 791: IPv4 Protocol
• RFC 8200: IPv6 Protocol (obsoletes RFC 2460)
• RFC 6550: RPL Protocol Specification

Previous: Routing Fundamentals

Next: Routing Basics

3.10 What’s Next

If you want to…	Read this
Start with routing basics	Routing Basics
Learn about packet switching	Packet Switching
Study IoT-specific routing challenges	Routing for IoT
Deep dive into RPL for IoT	RPL Overview

Begin with Routing Basics to understand what routing is and how routers make forwarding decisions. That chapter covers the fundamental distinction between routing and forwarding, introduces the concept of the routing table, and sets the foundation for everything that follows.