RFC 6606

Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing

📅 published May 2012, from ietf

RFC 6606 ✨ Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing

Okay bestie, let's get into it 🎀. This one comes from the Internet Engineering Task Force (IETF) and was published in May 2012 🗓️. It's marked Category: Informational 🧠, so it's for information, not a standards-track spec. The ISSN is 2070-1721 🔢.

The authors are E. Kim (ETRI), D. Kaspar (Simula Research Laboratory), C. Gomez (Universitat Politecnica de Catalunya/Fundacio i2CAT), and C. Bormann (Universitaet Bremen TZI) 🫶. The header doesn't list anything it obsoletes or updates 🤷‍♀️.

Abstract

Okay so, 6LoWPANs are IPv6 over Low-Power Wireless Personal Area Networks 🦋. They're built out of devices that are compatible with IEEE 802.15.4 📡. But here's the tea: neither IEEE 802.15.4 nor the 6LoWPAN format spec says how mesh topologies could be obtained and maintained 😭. So we should think about how 6LoWPAN formation and multi-hop routing could be supported 💜.

This document gives the problem statement and design space for 6LoWPAN routing 🌸. It lays out the routing requirements for 6LoWPANs, taking into account the low-power and other special traits of the devices and links 🔋. It is not here to recommend specific solutions 🙅‍♀️. Instead it offers general, layer-agnostic guidelines for designing 6LoWPAN routing, so people can keep analysing and designing protocols from there ✨. It's meant as input for groups working on routing protocols relevant to 6LoWPANs, like the IETF ROLL WG 🧚.

Status of This Memo

This document is not an Internet Standards Track specification 🚫. It's published for informational purposes 📚.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 💖. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 💅.

For info on the current status, any errata, and how to give feedback, look at http://www.rfc-editor.org/info/rfc6606 🔗.

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document 📜. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🔥.

Table of Contents

1. Problem Statement ...............................................2
2. Terminology .....................................................5
3. Design Space ....................................................5
   3.1. Reference Network Model ....................................6
4. Scenario Considerations and Parameters for 6LoWPAN Routing ......8
5. 6LoWPAN Routing Requirements ...................................13
   5.1. Support of 6LoWPAN Device Properties ......................13
   5.2. Support of 6LoWPAN Link Properties ........................15
   5.3. Support of 6LoWPAN Characteristics ........................18
   5.4. Support of Security .......................................22
   5.5. Support of Mesh-Under Forwarding ..........................25
   5.6. Support of Management .....................................26
6. Security Considerations ........................................27
7. Acknowledgments ................................................27
8. References .....................................................28
   8.1. Normative References ......................................28
   8.2. Informative References ....................................29

1. Problem Statement 🌈

6LoWPANs are formed by devices that are compatible with the IEEE 802.15.4 standard [IEEE802.15.4] 📡. Most LoWPAN devices are known for low bandwidth, short range, tiny memory, limited processing, and the other vibes you get from cheap hardware 🪫. The node characteristics for LoWPANs are assumed to be the ones described in the 6LoWPAN problem statement [RFC4919], and in the IPv6 over IEEE 802.15.4 document [RFC4944], which explains how to carry IPv6 packets over IEEE 802.15.4 and similar networks 🦋.

Now, IEEE 802.15.4 splits devices into two types: full-function devices (FFDs) and reduced-function devices (RFDs) 🧩. But that split is based on Medium Access Control (MAC) layer features that aren't always in use, so this document doesn't make the distinction 🙅‍♀️. Still, some 6LoWPAN nodes might only act as hosts, while others might take part in routing 🫶. That host/router split can line up with processing, storage, and available power, kind of like the RFD and FFD idea 💅.

IEEE 802.15.4 networks support star and mesh topologies 🕸️. But neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification ([RFC4944]) defines how mesh topologies could be obtained and maintained 😤. So 6LoWPAN formation and multi-hop routing can be supported either below the IP layer (the adaptation layer or Logical Link Control (LLC)) or at the IP layer 🧠. (Quick note: in the IETF, "routing" usually, but not always [RFC5556], means only the formation of paths and the forwarding at the IP layer 🤓. This document uses the terms "route-over" and "mesh-under" to tell apart the layer where these services happen. See Sections 2 and 3.) A bunch of IP routing protocols have been developed in various IETF working groups 💜. But these existing protocols may not meet the requirements for multi-hop routing in 6LoWPANs, for these reasons:

  • 6LoWPAN nodes have special types and roles 🎭. Some draw power from primary batteries, some are power-affluent, some are mains-powered and high-performance gateways, some are data aggregators, and so on. 6LoWPAN routing protocols should support multiple device types and roles ✨.
  • LoWPANs have stricter requirements than higher-performance or non-battery-operated networks 🪫. 6LoWPAN nodes have small memory and low processing power, and they run on very limited power from primary non-rechargeable batteries (a few KB of RAM, a few dozen KB of ROM/flash memory, and a few MHz of CPU is typical) 💀. A node's lifetime is usually defined by its battery's lifetime 🔋.
  • Handling sleeping nodes is super critical in LoWPANs, way more than in traditional ad hoc networks 😴. LoWPAN nodes might sleep most of the time. Picking the right times to transmit matters a lot for efficient packet forwarding 🦋.
  • Routing in 6LoWPANs might be a simpler problem than routing in higher-performance networks 🧁. LoWPANs might be either transit networks or stub networks. If we assume LoWPANs are never transit networks (as implied by [RFC4944]), routing protocols may be drastically simplified 🌷. This document focuses on the requirements for stub networks. Transit networks may have additional requirements 💖.
  • Routing in LoWPANs might also be a harder problem than routing in higher-performance networks 😭. Routing in LoWPANs requires power optimization, stable operation in lossy environments, and so on. These requirements are not easily satisfiable all at once [ROLL-PROTOCOLS] 💀.

These properties create new challenges for designing routing within LoWPANs 🌪️.

The 6LoWPAN problem statement [RFC4919] briefly mentions four requirements for routing protocols 📝:

  • (a) low overhead on data packets
  • (b) low routing overhead
  • (c) minimal memory and computation requirements
  • (d) support for sleeping nodes (consideration of battery savings)

These four high-level requirements describe the basic requirements for 6LoWPAN routing 🎀. Based on the fundamental features of 6LoWPANs, this document presents more detailed routing requirements, which can lead to further analysis and protocol design 🔍.

Considering the problems above, detailed 6LoWPAN routing requirements must be defined 📌. Application-specific features affect the design of 6LoWPAN routing requirements and corresponding solutions 🧩. But various applications can be profiled by similar technical characteristics, even though their detailed requirements might differ. For example, a few dozen nodes in a home lighting system need appropriate scalability for that system's applications, while millions of nodes for a highway infrastructure system also need appropriate scalability 🚗💡.

This routing requirements document states the routing requirements of 6LoWPAN applications in general, with examples for different cases of routing 🌈. It does not imply that a single routing solution will be favorable for all 6LoWPAN applications, and there is no requirement for different routing protocols to run simultaneously 🙌.

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶.

Readers are expected to be familiar with all the terms and concepts discussed in "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944] 🤓.

This specification makes use of the terminology defined in [6LoWPAN-ND] 💜.

3. Design Space ✨

okay so bestie, there are SO many possible routing algorithms for 6LoWPANs 🦋 but the real question is WHERE the routing happens. You can do it up in the IP layer (that's the route-over approach) or down below IP, as defined by the 6LoWPAN format document [RFC4944] (that's the mesh-under approach). Figure 1 shows the whole vibe 💅

Route-over leans on IP routing, so it can work over lots of different kinds of interconnected links 🌈 Quick aside: the ROLL WG is working on route-over stuff for Low-power and Lossy Networks (LLNs) in general, not just for 6LoWPANs specifically 🌸 This document is all about the 6LoWPAN-specific requirements, and it can be used alongside the more application-oriented requirements the ROLL WG is defining 🫶

Mesh-under does its multi-hop communication below the IP link ✨ The biggest thing to know is that the IEEE 802.15.4 characteristics directly shape the 6LoWPAN routing mechanisms. That includes using 64-bit (or 16-bit short) link-layer addresses instead of IP addresses 😭 So a 6LoWPAN looks like a single IP link from the outside 👑

Most of the statements in this document apply to both route-over and mesh-under, so don't worry, we've got you covered 💖

Figure 1 shows where 6LoWPAN routing sits in the full network stack 🧚

  +---------------------------+  +-----------------------------+
  |      Application Layer    |  |      Application Layer      |
  +---------------------------+  +-----------------------------+
  | Transport Layer (TCP/UDP) |  |  Transport Layer (TCP/UDP)  |
  +---------------------------+  +-----------------------------+
  |     Network Layer (IPv6)  |  |  Network       +---------+  |
  +---------------------------+  |  Layer         | Routing |  |
  |  6LoWPAN                  |  |  (IPv6)        +---------+  |
  |  Adaptation               |  +-----------------------------+
  |  Layer       +----------+ |  |  6LoWPAN Adaptation Layer   |
  +--------------| Routing* |-+  +-----------------------------+
  | 802.15.4 MAC +----------+ |  |        802.15.4 MAC         |
  +---------------------------+  +-----------------------------+
  |         802.15.4 PHY      |  |        802.15.4 PHY         |
  +---------------------------+  +-----------------------------+
   * Here, "Routing" is not equivalent to IP routing,
     but includes the functionalities of path computation and
     forwarding under the IP layer.
     The term "Routing" is used in the figure in order to
     illustrate which layer handles path computation and
     packet forwarding in mesh-under as compared to route-over.

  Figure 1: Mesh-Under Routing (Left) and Route-Over Routing (Right)

Now the packet size thing, which is a big deal 😤 To avoid fragmentation and the overhead of reassembly, routing packets should fit into a single IEEE 802.15.4 physical frame. And application data shouldn't get expanded so much that it stops fitting either 🍓

3.1. Reference Network Model

okay picture the network setup 🎀 For multi-hop communication in 6LoWPANs using the route-over mechanism, all the routers (that's the 6LoWPAN Border Routers (6LBRs) and the 6LoWPAN Routers (6LRs)) do IP routing within the stub network, as shown in Figure 2 ✨ In this case, link-local scope covers the set of nodes within symmetric radio range of a node 🦋

       h   h
      /    |                     6LBR: 6LoWPAN Border Router
  6LBR -- 6LR --- 6LR --- h       6LR: 6LoWPAN Router
          / \                       h: Host
         h  6LR --- h
             |
            / \
         6LR - 6LR -- h

               Figure 2: An Example of a Route-Over LoWPAN

When a LoWPAN goes with the mesh-under configuration, the 6LBR is the ONLY IPv6 router in the LoWPAN 👑 As shown in Figure 3, that means the IPv6 link-local scope includes all nodes in the LoWPAN 🌈 For this to work, a mesh-under mechanism MUST be provided to support multi-hop transmission 💅

       h   h
      /    |                    6LBR: 6LoWPAN Border Router
  6LBR --- m --- m --- h           m: mesh-under forwarder
          / \                      h: Host
         h   m --- h
             |
            / \
           m - m -- h

               Figure 3: An Example of a Mesh-Under LoWPAN

Note that in both mesh-under and route-over networks, there's no expectation of topologically based address assignment in the 6LoWPAN 🙈 Instead, addresses are usually assigned based on the EUI-64 addresses burned in at manufacturing time, or based on a process that's more or less random (from a topological point of view) which assigns 16-bit MAC addresses to individual nodes 💀 So within a 6LoWPAN there's no real chance for aggregating or summarizing IPv6 addresses, beyond sharing one or more common prefixes 😭

Not every device that's within radio range of each other has to be part of the same LoWPAN 🧚 When multiple LoWPANs are formed with globally unique IPv6 addresses, and device (a) of LoWPAN [A] wants to talk to device (b) of LoWPAN [B], the normal IPv6 mechanisms get used 🫶 For route-over, the IPv6 address of (b) is set as the destination of the packets, and the devices do IP routing to the 6LBR for those outgoing packets 🦋 For mesh-under, there's one IP hop from device (a) to the 6LBR of [A], no matter how many radio hops apart they are 🌸 This does assume a mesh-under routing protocol exists so the 6LBR can be reached 🔥 Also, a default route to the 6LBR could be inserted into the 6LoWPAN routing system for both route-over and mesh-under, which is honestly so useful 💜

4. Scenario Considerations and Parameters for 6LoWPAN Routing ✨

okay so IP-based LoWPAN tech is still in its early stage of development 🌱, but the range of conceivable usage scenarios is literally tremendous 😭. Sensor networks have so many possible applications that it's obvious mesh topologies will be prevalent in LoWPAN environments 🕸️, and robust routing is going to be a necessity for expedient communication. That's a whole vibe, honestly.

Researchers have put forth a large variety of multi-hop routing algorithms [Bulusu] 🧠. Most related work focuses on optimizing routing for specific application scenarios, which can be realized using several modes of communication, including the following [Watteyne]:

  • Flooding (in very small networks)
  • Hierarchical routing
  • Geographic routing
  • Self-organizing coordinate routing

Depending on the topology of a LoWPAN and the application(s) running over it, different types of routing may be used 🌈. However, this document abstracts away from application-specific communication and describes general routing requirements that are valid for overall routing in LoWPANs 💅.

The following parameters can be used to describe specific scenarios in which the candidate routing protocols could be evaluated 📋.

a. Network Properties:

  • Number of Devices, Density, and Network Diameter: These parameters usually affect the routing state directly (e.g., the number of entries in a routing table or neighbor list) 🗂️. Especially in large and dense networks, policies must be applied for discarding "low-quality" and stale routing entries in order to prevent memory overflow 🙈. (Okay, "must" is not in caps here, so I'm keeping it chill, but the point stands: you gotta clean house or the memory overflows, bestie.)
  • Connectivity: Due to external factors or programmed disconnections, a LoWPAN can be in several states of connectivity, anything in the range from "always connected" to "rarely connected" 📡. This poses great challenges to the dynamic discovery of routes across a LoWPAN 😤.
  • Dynamicity (including mobility): Location changes can be induced by unpredictable external factors or by controlled motion, which may in turn cause route changes 🦋. Also, nodes may dynamically be introduced into a LoWPAN and removed from it later 🚪. The routing state and the volume of control messages may heavily depend on the number of moving nodes in a LoWPAN and their speed, as well as how quickly and how frequently the environmental characteristics influencing radio propagation change 🌪️.
  • Deployment: In a LoWPAN, nodes can be scattered randomly or deployed in an organized manner 🎀. The deployment can happen all at once, or as an iterative process, which may also affect the routing state 🔁.
  • Spatial Distribution of Nodes and Gateways: Network connectivity depends on the spatial distribution of the nodes and on other factors, such as device number, density, and transmission range 📍. For instance, nodes can be placed on a grid, or randomly located in an area (as can be modeled by a two-dimensional Poisson distribution), etc. Assuming a random spatial distribution, an average of 7 neighbors per node are required for approximately 95% network connectivity (10 neighbors per node are needed for 99% connectivity) [Kuhn]. 🤯 Wild, right? In addition, if the LoWPAN is connected to other networks through infrastructure nodes called gateways, the number and spatial distribution of these gateways affect network congestion and available data rate, among other things 🚧.
  • Traffic Patterns, Topology, and Applications: The design of a LoWPAN and the requirements for its application have a big impact on the network topology and on the most efficient routing type to use 🧩. For different traffic patterns (point-to-point, multipoint-to-point, point-to-multipoint) and network architectures, various routing mechanisms have been developed, such as data-centric, event-driven, address-centric, and geographic routing 🗺️.
  • Classes of Service: For mixing applications of different criticality on one LoWPAN, support of multiple classes of service may be required in resource-constrained LoWPANs, and it may require a new routing protocol functionality 🎭.
  • Security: LoWPANs may carry sensitive information and require a high level of security support, where the availability, integrity, and confidentiality of data are of prime relevance 🔐. Secured messages cause overhead and affect the power consumption of LoWPAN routing protocols 🔋. Be so for real about this one, bestie.

b. Node Parameters:

  • Processing Speed and Memory Size: These basic parameters define the maximum size of the routing state and the maximum complexity of its processing 🧮. LoWPAN nodes may have different performance characteristics, queuing strategies, and queue buffer sizes 📦.
  • Power Consumption and Power Source: The number of battery-powered and mains-powered nodes, and their positions in the topology they create in a LoWPAN, affect routing protocols in their selection of paths that optimize network lifetime 🔌.
  • Transmission Range: This parameter affects routing 📶. For example, a high transmission range may cause a dense network, which in turn results in more direct neighbors of a node, higher connectivity, and a larger routing state 📈.
  • Traffic Pattern: This parameter affects routing, since highly loaded nodes (either because they are the source of packets to be transmitted or because of forwarding) may contribute to higher delivery delays and may consume more energy than lightly loaded nodes 🥵. This applies to both data packets and routing control messages 📨.

c. Link Parameters:

This section discusses link parameters that apply to IEEE 802.15.4 legacy mode (i.e., not making use of improved modulation schemes) 📻.

  • Throughput: The maximum user data throughput of a bulk data transmission between a single sender and a single receiver through an unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as follows [Latre]:
    • 16-bit MAC addresses, unreliable mode: 151.6 kbit/s
    • 16-bit MAC addresses, reliable mode: 139.0 kbit/s
    • 64-bit MAC addresses, unreliable mode: 135.6 kbit/s
    • 64-bit MAC addresses, reliable mode: 124.4 kbit/s
    • Throughput for the 915 MHz band is as follows:
      • 16-bit MAC addresses, unreliable mode: 31.1 kbit/s
      • 16-bit MAC addresses, reliable mode: 28.6 kbit/s
      • 64-bit MAC addresses, unreliable mode: 27.8 kbit/s
      • 64-bit MAC addresses, reliable mode: 25.6 kbit/s
    • Throughput for the 868 MHz band is as follows:
      • 16-bit MAC addresses, unreliable mode: 15.5 kbit/s
      • 16-bit MAC addresses, reliable mode: 14.3 kbit/s
      • 64-bit MAC addresses, unreliable mode: 13.9 kbit/s
      • 64-bit MAC addresses, reliable mode: 12.8 kbit/s
  • Latency: Latency ranges, depending on payload size, of a frame transmission between a single sender and a single receiver through an unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions are as shown below [Latre] ⏱️. For unreliable mode, the actual latency is provided. For reliable mode, the round-trip time, including transmission of a Layer-2 acknowledgment, is provided 🔁.
    • 16-bit MAC addresses, unreliable mode: [1.92 ms, 6.02 ms]
    • 16-bit MAC addresses, reliable mode: [2.46 ms, 6.56 ms]
    • 64-bit MAC addresses, unreliable mode: [2.75 ms, 6.02 ms]
    • 64-bit MAC addresses, reliable mode: [3.30 ms, 6.56 ms]
    • Latency ranges for the 915 MHz band are as follows:
      • 16-bit MAC addresses, unreliable mode: [5.85 ms, 29.35 ms]
      • 16-bit MAC addresses, reliable mode: [8.35 ms, 31.85 ms]
      • 64-bit MAC addresses, unreliable mode: [8.95 ms, 29.35 ms]
      • 64-bit MAC addresses, reliable mode: [11.45 ms, 31.82 ms]
    • Latency ranges for the 868 MHz band are as follows:
      • 16-bit MAC addresses, unreliable mode: [11.7 ms, 58.7 ms]
      • 16-bit MAC addresses, reliable mode: [16.7 ms, 63.7 ms]
      • 64-bit MAC addresses, unreliable mode: [17.9 ms, 58.7 ms]
      • 64-bit MAC addresses, reliable mode: [22.9 ms, 63.7 ms]

Note that some of the parameters presented in this section may be used as link or node evaluation metrics 📊. However, multi-criteria routing may be too expensive for 6LoWPAN nodes 💸. Rather, various single-criteria metrics are available and can be selected to suit the environment or application 🎯.

5. 6LoWPAN Routing Requirements

This section defines a list of requirements for 6LoWPAN routing 📝. An important design property specific to low-power networks is that LoWPANs have to support multiple device types and roles, such as:

  • host nodes drawing their power from primary batteries or using energy harvesting (sometimes called "power-constrained nodes") 🔋
  • mains-powered host nodes (an example of what we call "power-affluent nodes") ⚡
  • power-affluent (but not necessarily mains-powered) high-performance gateway(s) 🏰
  • nodes with various functionality (data aggregators, relays, local manager/coordinators, etc.) 🧚

Due to these different device types and roles, LoWPANs need to consider the following two primary attributes 👑:

  • Power conservation: some devices are mains-powered, but many are battery-operated and need to last several months to a few years with a single AA battery 🪫. Many devices are mains-powered most of the time but still need to function on batteries for possibly extended periods (e.g., on a construction site before building power is switched on for the first time) 🏗️.
  • Low performance: tiny devices, small memory sizes, low-performance processors, low bandwidth, high loss rates, etc. 🐣

These fundamental attributes of LoWPANs affect the design of routing solutions 💜. Whether existing routing specifications are simplified and modified, or new solutions are introduced in order to fit the low-power requirements of LoWPANs, they need to meet the requirements described below 🫶.

5.1. Support of 6LoWPAN Device Properties ✨

okay so bestie, this whole section is about the stuff 6LoWPAN routing protocols should do for devices that run on batteries 🔋💖 the requirements here are only as important as the node type and its role, so it's not one-size-fits-all, obviously 💅

[R01] 6LoWPAN routing protocols SHOULD allow implementation with small code size and require low routing state to fit the typical 6LoWPAN node capacity. Generally speaking, the code size is bounded by available flash memory size, and the routing table is bounded by RAM size, possibly limiting it to less than 32 entries.

okay this one is giving "keep it tiny" energy 🎀 the RAM on these nodes usually sits somewhere between 4 KB and 10 KB (2 KB minimum), and program flash is typically 48 KB to 128 KB 🧚

Some real hardware examples the authors mention: MICAz has 128 KB program flash, 4 KB EEPROM, and 512 KB external flash ROM; TIP700CM has 48 KB program flash, 10 KB RAM, and 1 MB external flash ROM. 🌸

Because of those hardware limits, code SHOULD fit within a small memory size, no more than 48 KB to 128 KB of flash memory, including at least a few tens of KB of application code size. ✨ As a general observation, a routing protocol of low complexity may help achieve the goal of reducing power consumption, improves robustness, requires lower routing state, is easier to analyze, and may be less prone to security attacks. 🦋

In addition, operation with limited amounts of routing state (such as routing tables and neighbor lists) SHOULD be maintained, since some typical memory sizes preclude storing state of a large number of nodes. For instance, industrial monitoring applications may need to support a maximum of 20 hops [RFC5673]. Small networks can be designed to support a smaller number of hops. While the need for this is highly dependent on the network architecture, there should be at least one mode of operation that can function with 32 forwarding entries or less. 🍓

[R02] 6LoWPAN routing protocols SHOULD cause minimal power consumption by efficiently using control packets (e.g., minimizing expensive IP multicast, which causes link broadcast to the entire LoWPAN) and by efficiently routing data packets.

bestie this is literally about not wasting battery 😭 one way to stretch battery life is keeping control message overhead minimal. Radio communication is by far the biggest power hog compared to things like computation or taking sensor samples [Doherty]. Transmit and receive power scale linearly with the length of the data units and how often they get sent or received [Shih].

The authors compare two RF controllers for low-power nodes in [Hill]. The TR1000 radio consumes 21 mW when transmitting at 0.75 mW, and 15 mW during reception (with a receiver sensitivity of -85 dBm). The CC1000 consumes 31.6 mW when transmitting at 0.75 mW, and 20 mW during reception (with a receiver sensitivity of -105 dBm). Power endurance under the concept of an idealized power source is explained in [Hill]. Based on the energy of an idealized AA battery, the CC1000 can transmit for approximately 4 days straight or receive for 9 consecutive days. Note that availability for reception consumes power as well. 🔥

As multicast may cause flooding in the LoWPAN, a 6LoWPAN routing protocol SHOULD minimize the control cost by multicasting routing packets. 💜

Control cost of routing protocols in low-power and lossy networks is discussed in more detail in [ROLL-PROTOCOLS]. 🫶

5.2. Support of 6LoWPAN Link Properties ✨

6LoWPAN links have the characteristics of low data rate and possibly high loss rates. The routing requirements described in this section are derived from the link properties. 🌈

[R03] 6LoWPAN routing protocol control messages SHOULD NOT exceed a single IEEE 802.15.4 frame size, in order to avoid packet fragmentation and the overhead for reassembly.

ngl this one is so important 💀 to save energy, routing overhead should be minimized so frames don't get fragmented. So 6LoWPAN routing should not cause packets to exceed the IEEE 802.15.4 frame size. That cuts transmission energy, avoids wasting bandwidth, and means no reassembly needed 🙈

The [IEEE802.15.4] standard specifies an MTU of 127 bytes, yielding about 80 octets of actual MAC payload with security enabled, some of which is taken for the (typically compressed) IP header [RFC6282]. Avoiding fragmentation at the adaptation layer may imply the use of semantic fragmentation and/or algorithms that can work on small increments of routing information. ✨

[R04] The design of routing protocols for LoWPANs must consider the fact that packets are to be delivered with sufficient probability according to application requirements.

Requirements for a successful end-to-end packet delivery ratio (where delivery may be bounded within certain latency levels) vary, depending on the application. In industrial applications, some non-critical monitoring applications may tolerate a successful delivery ratio of less than 90% with hours of latency; in some other cases, a delivery ratio of 99.9% is required [RFC5673]. In building automation applications, application-layer errors must be below 0.01% [RFC5867]. 🎀

Successful end-to-end delivery of packets in an IEEE 802.15.4 mesh depends on the quality of the path selected by the routing protocol and on the ability of the routing protocol to cope with short-term and long-term quality variation. The metric of the routing protocol strongly influences performance of the routing protocol in terms of delivery ratio. 💅

The quality of a given path depends on the individual qualities of the links (including the devices) that compose that path. IEEE 802.15.4 settings affect the quality perceived at upper layers. In particular, in IEEE 802.15.4 reliable mode, if an acknowledgment frame is not received after a given period, the originator retries frame transmission up to a maximum number of times. If an acknowledgment frame is still not received by the sender after performing the maximum number of transmission attempts, the MAC layer assumes that the transmission has failed and notifies the next higher layer of the failure. Note that excessive retransmissions may be detrimental; see RFC 3819 [RFC3819]. 🦋

[R05] The design of routing protocols for LoWPANs must consider the latency requirements of applications and IEEE 802.15.4 link latency characteristics.

Latency requirements may differ -- e.g., from a few hundred milliseconds to minutes -- depending on the type of application. Real-time building automation applications usually need response times below 500 ms between egress and ingress, while forced-entry security alerts must be routed to one or more fixed or mobile user devices within 5 seconds [RFC5867]. Non-critical closed-loop applications for industrial automation have latency requirements that can be as low as 100 ms, but many control loops are tolerant of latencies above 1 s [RFC5673]. In contrast, urban monitoring applications allow latencies smaller than the typical intervals used for reporting sensed information -- for instance, on the order of seconds to minutes [RFC5548]. ⏱️

The range of latencies of a frame transmission between a single sender and a single receiver through an ideal unslotted IEEE 802.15.4 2.4 GHz channel is between 2.46 ms and 6.02 ms with 64-bit MAC addresses in unreliable mode, and between 2.20 ms and 6.56 ms with 64-bit MAC addresses in reliable mode. The range of latencies of the 868 MHz band is from 11.7 ms to 63.7 ms, depending on the address type and mode used (reliable or unreliable). Note that the latencies may be larger than that, depending on channel load, the MAC-layer settings, and the choice of reliable or unreliable mode. Note that MAC approaches other than legacy 802.15.4 may be used (e.g., TDMA). Duty cycling may further affect latency (see [R08]). Depending on the routing path chosen and the network diameter, multiple hops may contribute to the end-to-end latency that an application may experience. 🌸

Note that a tradeoff exists between [R05] and [R04]. 🧚

[R06] 6LoWPAN routing protocols SHOULD be robust to dynamic loss caused by link failure or device unavailability either in the short term (approx. 30 ms) -- due to Received Signal Strength Indication (RSSI) variation, interference variation, noise, and asynchrony -- or in the long term, due to a depleted power source, hardware breakdown, operating system misbehavior, etc.

an important trait of 6LoWPAN devices is that they're unreliable 😭 that can come from limited system capabilities and from being closely coupled to the physical world with all its unpredictable variations. In harsh environments, LoWPANs easily suffer from link failure. Collisions or link failures easily increase send and receive queues and can lead to queue overflow and packet losses. 💀

For home applications, where users expect feedback after carrying out certain actions (such as handling a remote control while moving around), routing protocols must converge within 2 seconds if the destination node of the packet has moved and must converge within 0.5 seconds if only the sender has moved [RFC5826]. The tolerance of the recovery time can vary, depending on the application; however, the routing protocol must provide the detection of short-term unavailability and long-term disappearance. The routing protocol has to exploit network resources (e.g., path redundancy) to offer good network behavior despite node failure. ✨

Different routing protocols may exhibit different scaling characteristics with respect to the recovery/convergence time and the computational resources to achieve recovery after a convergence; see also [R01] and [R10]. 🫶

[R07] 6LoWPAN routing protocols SHOULD be designed to correctly operate in the presence of link asymmetry.

Link asymmetry occurs when the probability of successful transmission between two nodes is significantly higher in one direction than in the other. This phenomenon has been reported in a large number of experimental studies, and it is expected that 6LoWPANs will exhibit link asymmetry. 🦋

5.3. Support of 6LoWPAN Characteristics 🦋

okay so 6LoWPANs are seriously versatile 💅 they can be deployed in all kinds of sizes and topologies, they can follow different mobility patterns, and they can get hit with all sorts of interference. no matter what, LoWPANs must maintain low energy consumption 🔋 that's the vibe we are NOT compromising on. the requirements in this subsection come straight from those network attributes ✨

[R08] okay bestie, the design of 6LoWPAN routing protocols SHOULD take into account that some nodes may be unresponsive during certain time intervals, because they periodically hibernate 😴

so a lot of nodes in LoWPAN environments periodically hibernate (aka they switch off their transceiver activity) to save energy 🔋 which means routing protocols must ensure robust packet delivery even when nodes keep shutting off their radio transmission interface 📡 feedback from the lower IEEE 802.15.4 layer may be considered to make routing protocols more power aware, which is honestly iconic 🧚

CC1000-based nodes must operate at a duty cycle of approximately 2% to survive for one year from an idealized AA battery power source [Hill] 💀 for home automation, it is suggested that devices maximize the sleep phase with a duty cycle lower than 1% [RFC5826]. meanwhile, in building automation applications, batteries must be operational for at least 5 years when the sensing devices are transmitting data (e.g., 64 bytes) once per minute [RFC5867] ⏳

packet rates can range from one per second to one per day, or even beyond 📆 routing protocols may take advantage of knowing the packet transmission rate and use that info when calculating routing paths 🗺️ in lots of IEEE 802.15.4 deployments (and other wireless low-power technologies), forwarders are mains-powered, so they don't need to sleep 🔌 but it cannot be assumed that ALL forwarders are mains-powered 🙈 a routing protocol that addresses this case SHOULD provide a mode in which power consumption is a metric. and using nodes in power-saving modes for forwarding may increase delay and reduce the probability of packet delivery, so that should also be available as an input into the path computation 💜

[R09] the metric used by 6LoWPAN routing protocols SHOULD provide some flexibility with respect to the inputs from the lower layers and other measures to optimize path selection, balancing energy and link qualities ⚖️

in homes, buildings, or infrastructure, some nodes will be installed with mains power 🔌 those power-installed nodes MUST be considered as relay points with a prominent role in packet delivery 👑 6LoWPAN routing protocols MUST know the power constraints of the nodes 🧠

simple hop-count-only mechanisms may be inefficient in 6LoWPANs 🙅‍♀️ there's Link Quality Indication (LQI) and/or RSSI from IEEE 802.15.4 that may be taken into account for better metrics 📶 the metric to be used (and its goal) may depend on applications and requirements 🎯

the numbers in Figure 4 represent the Link Delivery Ratio (LDR) of each pair of nodes 🍓 there are studies showing a piecewise linear dependence between the LQI and the LDR [Chen] 🤓

                              0.6
                           A-------C
                            \     /
                         0.9 \   / 0.9
                              \ /
                               B

                  Figure 4: An Example Network

in this simple example, there are two options for routing from node A to node C, and they each come with their own vibe 💅

  • Path AC:
    • (1/0.6) = 1.67 avg. transmissions needed for each packet (confirmed link-layer delivery with retransmissions and negligible ACK loss have been assumed)
    • one-hop path
    • good energy consumption and end-to-end latency of data packets, poor delivery ratio (0.6)
    • poor probability of route reconfigurations
  • Path ABC:
    • (1/0.9)+(1/0.9) = 2.22 avg. transmissions needed for each packet (under the same assumptions as above)
    • two-hop path
    • poor energy consumption and end-to-end latency of data packets, good delivery ratio (0.81)

so if the network's energy consumption must be minimized, path AC is the best one (it would be chosen based on a hop-count metric) 🔋✨ but if the delivery ratio in that case isn't sufficient, the best path is ABC (an LQI-based metric would pick it) 🫶 combinations of both metrics can be used too 🌈

the metric also affects the probability of route reconfiguration 🔄 route reconfiguration, which may be triggered by packet losses, may require transmitting routing protocol messages 📨 it's possible to use a metric aimed at selecting the path with a low route reconfiguration rate by using the LQI as an input to the metric. that kind of path has good properties, including stability and low control message overhead 🧘‍♀️

note that a tradeoff exists between [R09] and [R01] 👀

[R10] 6LoWPAN routing protocols SHOULD be designed to achieve both scalability (from a few nodes to maybe millions of nodes) and minimal use of system resources 📈

a LoWPAN might have just a couple of nodes (like in a body-area network), but it can also contain way more devices (e.g., monitoring a city's infrastructure or a highway) 🏙️ for home automation, it's envisioned that the routing protocol must support 250 devices in the network [RFC5826], while routing protocols for metropolitan-scale sensor networks must be capable of clustering a large number of sensing nodes into regions with roughly 10^2 to 10^4 sensing nodes each [RFC5548] 🤯 so routing mechanisms need to be designed to be scalable across networks of all sizes 🦋

BUT here's the catch: due to a lack of memory and computational power, 6LoWPAN routing might limit forwarding entries to a small number, such as a maximum of 32 routing table entries 🥺 particularly in large networks, the routing mechanism MUST be designed in such a way that the number of routers is smaller than the number of hosts 👑

[R11] the procedure of route repair and related control messages SHOULD NOT harm overall energy consumption from the routing protocols 🙅‍♀️🔋

local repair improves throughput and end-to-end latency, especially in large networks 🚀 since routes get repaired quickly, fewer data packets are dropped, and fewer routing protocol packet transmissions are needed, because routes can be repaired without source-initiated route discovery [Lee] ✨ one important consideration here may be avoiding premature energy depletion, even if that impairs other requirements 🪫

[R12] 6LoWPAN routing protocols SHOULD allow for dynamically adaptive topologies and mobile nodes 🏃‍♀️ when supporting dynamic topologies and mobile nodes, route maintenance should keep in mind the goal of a minimal routing state and minimal routing protocol message overhead 🧹

topological node mobility can be the result of physical movement and/or a changing radio environment, so mobility might need handling even in a network with physically static nodes 🌀 6LoWPANs don't use a separate protocol to keep connectivity to moving nodes; they expect the routing protocol to handle it 💅 and some nodes may move from one 6LoWPAN to another and are expected to become functional members of the latter within a limited amount of time ⏱️

building monitoring apps, for example, have requirements for recovery and settling time for mobility somewhere between 5 and 20 seconds (Section 5.3.1 of [RFC5867]) 🏢 for more interactive applications like home automation, where users give input and expect instant feedback, mobility requirements are stricter, and for moves within a network, a convergence time below 0.5 seconds is commonly required (Section 3.2 of [RFC5826]) ⚡ in industrial environments, where mobile equipment (e.g., cranes) moves around, the routing protocol needs to support vehicular speeds of up to 35 km/h [RFC5673] 🏗️ currently, 6LoWPANs aren't normally used for such fast mobility, but dynamic association and disassociation MUST be supported in 6LoWPANs 🫶

there are several challenges a 6LoWPAN routing protocol should address in order to create robust routing in dynamic environments 🧩

  • Mobile Nodes Changing Their Location inside a LoWPAN: if the nodes' movement pattern is unknown, mobility can't easily be detected or distinguished by the routing protocols 🕵️‍♀️ mobile nodes can be treated as nodes that disappear and reappear in another place. tracking movement patterns adds complexity, so it can be avoided by handling moving nodes with reactive route updates 💫
  • Movement of a LoWPAN with Respect to Other (Inter)Connected LoWPANs: within each stub network, (one or more) relatively powerful gateway nodes (6LBRs) need to be configured to handle moving LoWPANs 🌉
  • Nodes Permanently Joining or Leaving the LoWPAN: to ease routing table updates, reduce the size of these updates, and minimize error control messages, nodes leaving the network may announce their disassociation to the closest edge router or to a specific node (if any) that takes charge of local association and disassociation 📣

[R13] a 6LoWPAN routing protocol SHOULD support various traffic patterns (point-to-point, point-to-multipoint, and multipoint-to-point) while avoiding excessive multicast traffic in a LoWPAN 🎀

6LoWPANs often have point-to-multipoint or multipoint-to-point traffic patterns 💖 lots of emerging apps include point-to-point communication too. 6LoWPAN routing protocols should be designed with forwarding packets from and to multiple sources and destinations in mind 🌸 current documents from the ROLL WG explain that the workload or traffic pattern of LoWPAN use cases tends to be highly structured, unlike the any-to-any data transfers that dominate typical client and server workloads 🧠 and in many cases, exploiting that structure can simplify difficult problems that come from resource constraints or variation in connectivity 🔥

5.4. Support of Security ✨

Okay bestie, this one is all about keeping routing messages locked down 🔒. The routing requirement in this subsection lets routing messages travel securely 💖. Just like in traditional networks, routing in 6LoWPANs is another window an attacker could use to mess things up and seriously tank the network's performance 😭. Attacks on non-secure routing mostly aim to contaminate WPANs with false routing info, which causes routing inconsistencies 💀. A sneaky malicious node can also snoop packets and then launch replay attacks on 6LoWPAN nodes 🙈. This can cause real harm, especially when the attacker is a high-power device like a laptop. It can also easily drain the batteries of 6LoWPAN devices by sending broadcast messages, redirecting routes, etc. 🔋

[R14] 6LoWPAN routing protocols MUST support confidentiality, authentication, and integrity services as required for secure delivery of control messages.

A general set of requirements that may apply to these services can be found in [KARP-THREATS]. 🧠

Security is super important for designing robust routing protocols, but it should not cause significant transmission overhead. The security aspect is kind of a tradeoff in a 6LoWPAN, since security is always a costly function 💸. A 6LoWPAN poses unique challenges that traditional security techniques can't be applied to directly. For example, public key cryptography primitives are typically avoided (as being too expensive), and so are relatively heavyweight conventional encryption methods 🙅‍♀️.

So it becomes questionable whether 6LoWPAN devices can support IPsec as it is. While [RFC6434] makes support of the IPsec architecture a SHOULD for all IPv6 nodes, considering the power constraints and limited processing capabilities of IEEE 802.15.4-capable devices, IPsec is computationally expensive 🥵. Internet Key Exchange (IKEv2) messaging as described in RFC 5996 [RFC5996] won't work well in 6LoWPANs, since we want to minimize the amount of signaling in these networks 📉. IPsec supports the Authentication Header (AH) for authenticating the IP header and the Encapsulating Security Payload (ESP) for authenticating and encrypting the payload. The main issues with using IPsec are two-fold: (1) processing power and (2) key management 🔑. Since these tiny 6LoWPAN devices don't process huge amounts of data or communicate with many different nodes, it isn't well understood whether a complete implementation of a Security Association Database (SAD), a policy database, and a dynamic key-management protocol are appropriate for these small battery-powered devices or not 🤷‍♀️.

Bandwidth is a very scarce resource in 6LoWPAN environments. IPsec additionally requires another header (AH or ESP) in every packet, which makes its use problematic here 📦. IPsec also requires two communicating peers to share a secret key that is typically established dynamically with IKEv2. So it has additional packet overhead from the exchange of IKEv2 packets 😩.

Given the existing constraints in 6LoWPAN environments, IPsec may not be suitable for use in such environments, especially since a 6LoWPAN node may not be capable of operating all IPsec algorithms on its own. So a 6LoWPAN may need to define its own keying management method(s) that require minimum overhead in packet size and in the number of signaling messages exchanged ✨. IPsec will provide authentication and confidentiality between end-nodes and across multiple LoWPAN links, and may be useful only when two nodes want to apply security to all exchanged messages. However, in most cases, the security may be requested at the application layer as needed, while other messages can flow in the network without security overhead 🌸.

Security threats within LoWPANs may be different from existing threat models in ad hoc network environments. If IEEE 802.15.4 security is not used, Neighbor Discovery (ND) in IEEE 802.15.4 links is susceptible to threats. These include Neighbor Solicitation/Neighbor Advertisement (NS/NA) spoofing, a malicious router, a default router that is "killed", a good router that goes bad, a spoofed redirect, replay attacks, and remote ND DoS [RFC3756] 🚨. However, if IEEE 802.15.4 security is used, no other protection is needed for ND, as long as none of the nodes become compromised, because the Corporate Intranet Model of RFC 3756 can be assumed [6LoWPAN-ND] 🛡️.

Bootstrapping may also impose additional threats. For example, a malicious node can obtain initial configuration information in order to appear as a legitimate node and then carry out various types of attacks 👀. Such a node can also keep legitimate nodes busy by broadcasting authentication/join requests. One option for mitigating such threats is the use of mutual authentication schemes based on pre-shared keys [Ikram] 🤝.

The IEEE 802.15.4 MAC provides an AES-based security mechanism. Routing protocols may define how this mechanism (in conjunction with IPsec whenever available) can be used to obtain the intended security, either for the routing protocol alone or in conjunction with the security used for the data. The byte overhead of the mechanism, which depends on the security services selected, must be considered. In the worst case in terms of overhead, the mechanism consumes 21 bytes of MAC payload 📏.

IEEE 802.15.4 MAC security is typically supported by crypto hardware, even in the very simple chips used in a 6LoWPAN 🔐. Even if the IEEE 802.15.4 MAC security mechanisms aren't used, this crypto hardware is usually available for application code running on these chips. So a security protocol outside IEEE 802.15.4 MAC security SHOULD therefore provide a mode of operation that is covered by this crypto hardware 💅.

IEEE 802.15.4 does not specify protection for acknowledgment frames. Since the sequence numbers of data frames are sent in the clear, an adversary can forge an acknowledgment for each data frame. Exploiting this weakness can be combined with targeted jamming to prevent delivery of selected packets. So IEEE 802.15.4 acknowledgments can't be relied upon. In applications that require high security, the routing protocol must not exploit feedback from acknowledgments (e.g., to keep track of neighbor connectivity, see [R16]) 🙈💀

5.5. Support of Mesh-Under Forwarding 🕸️

One LoWPAN may be built as one IPv6 link. In this case, mesh-under forwarding mechanisms must be supported. While this document provides general, layer-agnostic guidelines about the design of 6LoWPAN routing, the requirements in this section are specifically related to Layer 2. These requirements are directed to bodies that might consider working on mesh-under routing, such as the IEEE. The requirements in this subsection allow optimization and correct operation of routing solutions, taking into account the specific features of the mesh-under configuration 🧩.

[R15] Mesh-under requires the development of a routing protocol operating below IP. This protocol MUST support 16-bit short and 64-bit extended MAC addresses.

[R16] In order to perform discovery and maintenance of neighbors (i.e., neighborhood discovery as opposed to ND-style neighbor discovery), LoWPAN nodes SHOULD avoid sending separate "Hello" messages. Instead, link-layer mechanisms (such as acknowledgments) MAY be utilized to keep track of active neighbors 👋.

Reception of an acknowledgment after a frame transmission may make explicit Hello messages unnecessary, for example. In a more general view, any frame received by a node may be used as an input to evaluate the connectivity between the sender and receiver of that frame 📡.

[R17] If the routing protocol functionality includes enabling IP multicast, then it MAY employ structure in the network for efficient distribution in order to minimize link-layer broadcast 📣.

5.6. Support of Management 🎀

When a new protocol is designed, the operational environment and manageability of the protocol should be considered from the start [RFC5706]. This subsection provides a requirement for the manageability of 6LoWPAN routing protocols 🗂️.

[R18] A 6LoWPAN routing protocol SHOULD be designed according to the guidelines for operations and management stated in [RFC5706].

The management operations a 6LoWPAN routing protocol implementation can support depend on the memory and processing capabilities of the 6LoWPAN devices used, which are typically constrained. Still, 6LoWPANs may benefit a lot from supporting management operations like configuration and performance monitoring 📊.

The design of 6LoWPAN routing protocols should take into account that, according to "Architectural Principles of the Internet" [RFC1958], "options and parameters should be configured or negotiated dynamically rather than manually". This is especially important for 6LoWPANs, which can be composed of a large number of devices (and these devices may not have an appropriate user interface either) 🙃. So parameter autoconfiguration is a desirable property for a 6LoWPAN routing protocol, although some subset of routing protocol parameters may allow other forms of configuration as well ⚙️.

To verify the correct operation of the 6LoWPAN routing protocol and the network itself, a 6LoWPAN routing protocol should allow monitoring of the status and/or value of its parameters and data structures, such as routing table entries 🔍. To enable fault management, further monitoring of the 6LoWPAN routing protocol operation is needed. For this, faults can be reported via error log messages. These messages may contain information such as the number of times a packet could not be sent to a valid next hop, the duration of each period without connectivity, memory overflow and its causes, etc. 🚩

[RFC5706] -- in particular its Section 3 -- provides a comprehensive guide to properly designing the management solution for a 6LoWPAN routing protocol 💖

6. Security Considerations ✨

okay bestie, security is literally the part where we get serious 🔒💅 Section 5.4 has the full security details, so go read that too. The security considerations from RFC 4919 [RFC4919], RFC 4944 [RFC4944], and RFC 4593 [RFC4593] also apply here, no cap 🫶

The vibe is that wireless links make a 6LoWPAN just as exposed as any other wireless network 📡😭 In outdoor 6LoWPANs, the nodes are physically out there, so an adversary can capture, clone, or tamper with them 💀 In ad hoc 6LoWPANs where the topology AND the node memberships keep changing, a static security setup is NOT enough 🙈 Spoofed, altered, or replayed routing info can show up, and multihopping can delay how fast attacks get detected and handled 🌀

This spec expects the link layer to already be well protected, either with physical or IP security for the backbone link, or with MAC-sublayer cryptography 🔐 Still, link-layer encryption and authentication might NOT be enough to give confidentiality, authentication, integrity, and freshness to both data and routing protocol packets 😬 Time synchronization, self-organization, and secure localization for multi-hop routing are also super important to support 🧚

For secure routing protocol operation, it MAY be necessary to think about authenticated broadcast (and multicast) and bidirectional link verification 🦋 On the flip side, the routing protocol can help with secure end-to-end data delivery ✨ For example, multi-path routing could be considered to boost security and prevent selective forwarding 🌈 The catch is that 6LoWPANs already have tight resource constraints, so the 6LBR and LoWPAN nodes might need different security solutions 🥺

7. Acknowledgments 🎀

The authors of this document seriously appreciate the authors of "IPv6 over Low Power WPAN Security Analysis" [6LoWPAN-SEC] 💜 Their security analysis work was not ongoing when this was written, but their valuable information and text are used in Section 5.4 of this document, per advice received during IESG review procedures. Thanks to their work, Section 5.4 is so much better 👑 The authors also thank S. Chakrabarti, who gave valuable comments on mesh-under requirements, and A. Petrescu for significant review 🫶

Carles Gomez has been supported in part by FEDER and by the Spanish Government through projects TIC2006-04504 and TEC2009-11453 🌸

8. References 📚

8.1. Normative References

[IEEE802.15.4]
           IEEE Computer Society, "IEEE Standard for Local and
           Metropolitan Area Networks -- Part 15.4: Low-Rate
           Wireless Personal Area Networks (LR-WPANs)", IEEE
           Std. 802.15.4-2011, September 2011.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
           Neighbor Discovery (ND) Trust Models and Threats",
           RFC 3756, May 2004.

[RFC3819]  Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
           Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
           Wood, "Advice for Internet Subnetwork Designers", BCP 89,
           RFC 3819, July 2004.

[RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
           Routing Protocols", RFC 4593, October 2006.

[RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
           over Low-Power Wireless Personal Area Networks (6LoWPANs):
           Overview, Assumptions, Problem Statement, and Goals",
           RFC 4919, August 2007.

[RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
           "Transmission of IPv6 Packets over IEEE 802.15.4
           Networks", RFC 4944, September 2007.

[RFC5548]  Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and
           D. Barthel, Ed., "Routing Requirements for Urban Low-Power
           and Lossy Networks", RFC 5548, May 2009.

[RFC5673]  Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
           Phinney, "Industrial Routing Requirements in Low-Power and
           Lossy Networks", RFC 5673, October 2009.

8.2. Informative References

[6LoWPAN-ND]
           Shelby, Z., Ed., Chakrabarti, S., and E. Nordmark,
           "Neighbor Discovery Optimization for Low Power and Lossy
           Networks (6LoWPAN)", Work in Progress, October 2011.

[6LoWPAN-SEC]
           Park, S., Kim, K., Haddad, W., Ed., Chakrabarti, S., and
           J. Laganier, "IPv6 over Low Power WPAN Security Analysis",
           Work in Progress, March 2011.

[Bulusu]   Bulusu, N., Ed., and S. Jha, Ed., "Wireless Sensor
           Networks: A Systems Perspective", Artech House,
           ISBN 9781580538671, July 2005.

[Chen]     Chen, B., Muniswamy-Reddy, K., and M. Welsh, "Ad-Hoc
           Multicast Routing on Resource-Limited Sensor Nodes", Proc.
           2nd International Workshop on Multi-hop Ad Hoc Networks,
           May 2006.

[Doherty]  Doherty, L., Warneke, B., Boser, B., and K. Pister,
           "Energy and Performance Considerations for Smart Dust",
           International Journal of Parallel and Distributed Systems
           and Networks, Vol. 4, No. 3, 2001.

[Hill]     Hill, J., "System Architecture for Wireless Sensor
           Networks", Ph.D. Thesis, UC Berkeley, 2003.

[Ikram]    Ikram, M., Chowdhury, A., Zafar, B., Cha, H., Kim, K.,
           Yoo, S., and D. Kim, "A Simple Lightweight Authentic
           Bootstrapping Protocol for IPv6-based Low Rate Wireless
           Personal Area Networks (6LoWPANs)", Proc. International
           Conference on Wireless Communications and
           Mobile Computing, June 2009.

[KARP-THREATS]
           Lebovitz, G. and M. Bhatia, "Keying and Authentication for
           Routing Protocols (KARP) Overview, Threats, and
           Requirements", Work in Progress, May 2012.

[Kuhn]     Kuhn, F., Wattenhofer, R., and A. Zollinger, "Worst-Case
           Optimal and Average-Case Efficient Ad-Hoc Geometric
           Routing", MobiHoc '03: Proceedings of the 4th ACM
           International Symposium on Mobile Ad Hoc Networking and
           Computing, June 2003.

[Latre]    Latre, B., De Mil, P., Moerman, I., Dhoedt, B., and P.
           Demeester, "Throughput and Delay Analysis of Unslotted
           IEEE 802.15.4", Journal of Networks, Vol. 1, No. 1,
           May 2006.

[Lee]      Lee, S., Belding-Royer, E., and C. Perkins, "Scalability
           Study of the Ad Hoc On-Demand Distance-Vector Routing
           Protocol", International Journal of Network Management,
           Vol. 13, pp. 97-114, March 2003.

[RFC1958]  Carpenter, B., Ed., "Architectural Principles of the
           Internet", RFC 1958, June 1996.

[RFC5556]  Touch, J. and R. Perlman, "Transparent Interconnection of
           Lots of Links (TRILL): Problem and Applicability
           Statement", RFC 5556, May 2009.

[RFC5706]  Harrington, D., "Guidelines for Considering Operations and
           Management of New Protocols and Protocol Extensions",
           RFC 5706, November 2009.

[RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
           Routing Requirements in Low-Power and Lossy Networks",
           RFC 5826, April 2010.

[RFC5867]  Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen,
           "Building Automation Routing Requirements in Low-Power and
           Lossy Networks", RFC 5867, June 2010.

[RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
           "Internet Key Exchange Protocol Version 2 (IKEv2)",
           RFC 5996, September 2010.

[RFC6282]  Hui, J., Ed., and P. Thubert, "Compression Format for IPv6
           Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
           September 2011.

[RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
           Requirements", RFC 6434, December 2011.

[ROLL-PROTOCOLS]
           Levis, P., Tavakoli, A., and S. Dawson-Haggerty, "Overview
           of Existing Routing Protocols for Low Power and Lossy
           Networks", Work in Progress, April 2009.

[Shih]     Shih, E., Cho, S., Ickes, N., Min, R., Sinha, A., Wang,
           A., and A. Chandrakasan, "Physical Layer Driven Protocols
           and Algorithm Design for Energy-Efficient Wireless Sensor
           Networks", MobiCom '01: Proceedings of the 7th ACM Annual
           International Conference on Mobile Computing and
           Networking, July 2001.

[Watteyne] Watteyne, T., Molinaro, A., Richichi, M., and M. Dohler,
           "From MANET To IETF ROLL Standardization: A Paradigm Shift
           in WSN Routing Protocols", IEEE Communications Surveys and
           Tutorials, Vol. 13, Issue 4, pp. 688-707, 2011,
           <http://ieeexplore.ieee.org/xpl/
           articleDetails.jsp?arnumber=5581105>.

Authors' Addresses 💌

Eunsook Eunah Kim
ETRI
161 Gajeong-dong
Yuseong-gu
Daejeon  305-700
Korea

Phone: +82-42-860-6124
EMail: eunah.ietf@gmail.com
Dominik Kaspar
Simula Research Laboratory
Martin Linges v 17
Fornebu  1364
Norway

Phone: +47-6782-8223
EMail: dokaspar.ietf@gmail.com
Carles Gomez
Universitat Politecnica de Catalunya/Fundacio i2CAT
Escola d'Enginyeria de Telecomunicacio i Aeroespacial
   de Castelldefels
C/Esteve Terradas, 7
Castelldefels  08860
Spain

Phone: +34-93-413-7206
EMail: carlesgo@entel.upc.edu
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen  D-28359
Germany

Phone: +49-421-218-63921
EMail: cabo@tzi.org
📦 where this page comes from