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

The general objectives listed in this section should be met by 6LoWPAN routing protocols. The importance of each requirement is dependent on what node type the protocol is running on and what the role of the node is. The following requirements consider the presence of battery-powered nodes in LoWPANs.

[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.

The RAM size of LoWPAN nodes often ranges between 4 KB and 10 KB (2 KB minimum), and program flash memory normally consists of 48 KB to 128 KB. (For example, in the current market, 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.)

Due to these hardware restrictions, 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.

One way of optimizing battery lifetime is by achieving a minimal control message overhead. Compared to such functions as computational operations or taking sensor samples, radio communication is by far the dominant factor of power consumption [Doherty]. Power consumption of transmission and/or reception depends linearly on the length of data units and on the frequency of transmission and reception of the data units [Shih].

The energy consumption of two example radio frequency (RF) controllers for low-power nodes is shown 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 actual tasks depends on the frequency of communication and other low duty cycle operations, as well as the energy capacity the battery provides.

In some cases, the overhead introduced by the routing protocol is large. [Doherty] reports that in the LEACH protocol used for hierarchical routing, data and protocol packets proposed in [Heinzelman] consume 97% of the transmission energy at a rate of 100 bits per second. In cases where the control packet overhead requirement is not as demanding, control packets still play a significant role. For Low-Rate Low-Power Wireless Personal Area Network (LR-WPAN) sensor data, ZigBee (IEEE 802.15.4) uses AODV routing in sensor data transmission, the routing protocol packets consume about 15% of the transmission energy, while the transmission energy consumption of data packets is about 85% [Doherty]. Therefore, routing protocols SHOULD consider using efficient routing mechanisms and simple exchange protocol packet formats.

[R03] 6LoWPAN routing protocol control messages SHOULD NOT exceed a single IEEE 802.15.4 MAC frame size (maximum 127 bytes) to avoid the costly fragmentation and reassembly costs.

The maximum physical layer packet size of a single IEEE 802.15.4 frame is 127 bytes [IEEE802.15.4]. In the case where LLC/SNAP carries the Ethernet frame type, a 40-byte IPv6 header plus a UDP header requires 8 bytes, and thus, the UDP payload is 74 bytes. In general, in order to keep the protocol simple and avoid frame fragmentation and reassembly, 6LoWPAN routing protocol control messages SHOULD be sent in limited quantities and be as small as possible.

5.2. Support of 6LoWPAN Link Properties

Due to the topological conditions of LoWPANs, link failures and transmission failures occur frequently. Increased reliability of packets or the use of additional backup transmissions may be required. Handling unexpected network conditions (such as lost data or control packets, unidirectional links, varying link quality) is crucial to designing robust and reliable routing protocols. Routing protocols not only need to be aware of these types of network conditions in their design, but must also utilize the functionality provided by 6LoWPAN interconnectivity to ensure that data can be reliably delivered from source to destination. The following requirements consider the characteristics of links in LoWPANs.

[R04] The design of routing protocols for LoWPANs must consider the link reliability, link error rate, link quality, and link stability for routing optimization.

Wireless low-power links are inherently unreliable, and there are multiple reasons for packet loss, such as:

• Many devices may be in sleep mode most of the time, so there may be no neighbors listening when packets are transmitted.
• Environmental factors such as EMI, obstacles from buildings and infrastructure, terrain, etc., may cause transmission failures or symmetric links to become asymmetric and vice versa.
• Congestion, particularly in sensor networks, where multi-hop communication and routing traffic from many sources converging toward the gateway increase the likelihood of congestion around nodes near the gateway [Shelby-6LoWPAN].
• The wireless spectrum is typically shared and requires coordination among several wireless technologies that use the ISM bands, and networks operating in these bands may be affected by interference from other networks or devices.

Therefore, the design of 6LoWPAN routing protocols MUST consider link reliability, link error rate, link quality, and link stability for routing optimization.

[R05] The design of routing protocols for LoWPANs must consider asymmetric links.

6LoWPAN routing protocols MUST support asymmetric links because many practical links in LoWPANs are asymmetric (for example, links between low-power sensing nodes and power-affluent base stations) [Shelby-CoAP]. In such cases, the selection of routing paths MUST handle asymmetric links.

[R06] 6LoWPAN routing protocols SHOULD be robust to dynamic loss changes in links.

6LoWPAN routing protocols SHOULD be robust to variations in link loss to handle the unreliable nature of IEEE 802.15.4 links. Typical links connected to LoWPAN nodes may not be available all the time. Variations in link loss may be due to various factors such as node movement, power/battery depletion, sleep cycles, signal fading or reduced received signal strength, and interference, and may result in links being disabled for extended periods. Routing protocols SHOULD handle the characteristics of these links in an adequate manner.

[R07] 6LoWPAN routing protocols SHOULD be designed to correctly handle possible frame sizes.

In some LoWPANs, the maximum possible size of control packets is very limited (up to 127 bytes in a single IEEE 802.15.4 MAC frame) because the MAC layer has no native fragmentation and reassembly support.

The maximum frame size means that small headers and low state message overhead MUST be enforced. Control packets SHOULD be small enough to fit within a single link-layer frame. However, flexibility is still needed when constructing messages; message design MUST accommodate the space required for standard IPv6 headers and other headers (such as link-layer headers and adaptation layer headers), and MUST also be able to accommodate options required by other routing protocols and existing IETF protocols.

5.3. Support of 6LoWPAN Characteristics

This section considers fundamental network characteristics that may affect the design of 6LoWPAN routing protocols.

[R08] The design of 6LoWPAN routing protocols SHOULD take into account traffic patterns, network density, possible roles or functions of nodes, and the use and number of different network configurations.

6LoWPAN routing protocols SHOULD be able to handle a variety of different LoWPAN topologies, such as:

• Point-to-point, point-to-multipoint, multipoint-to-point, or multipoint-to-multipoint traffic patterns
• Communication traffic concentrated at a single point (e.g., gateway)
• Varying host and router density, varying router-to-host ratios
• Router functionality may be different from host functionality or may be on the same node
• Different node functionality, such as constrained and unconstrained nodes, or nodes performing functions such as routing, relaying, aggregation, etc.
• Different network configurations, such as peer-to-peer, star, mesh networks
• Dynamic network formation and topology changes during the post-deployment period (runtime)
• Varying network size; the size of networks can also be very diverse, from networks with a few nodes to several hundred or more nodes
• Network partitioning may occur and needs to be handled

[R09] The metric used by 6LoWPAN routing protocols SHOULD provide consideration for the combined effects of node and link attributes.

It is important to incorporate link quality and node attributes into routing metrics to minimize energy consumption and ensure successful delivery. For example, the shortest path with minimum hop count may not be the most energy-efficient path because it may go through very congested nodes or through links that experience more errors and therefore require more retransmissions.

Regarding the types of metrics, routing metrics should be able to effectively represent:

• Link metrics: Received Signal Strength Indication (RSSI), Link Quality Indication (LQI), Expected Transmission Count (ETX), throughput, latency
• Node metrics: state (sleep, awake, listening), remaining energy, hop count, geographic information (e.g., GPS coordinates)
• Composite metrics (link and node)

Other possible metrics SHOULD also be considered, such as:

• Reliability
• Robustness
• Stability

[R10] 6LoWPAN routing protocols SHOULD be designed to achieve both scalability and longevity in 6LoWPANs.

Scalability and longevity requirements are fundamental characteristics of LoWPANs:

• Scalability: A LoWPAN may contain only a few nodes (for example, for a personal area network or body-area network), but may also contain much higher numbers of devices (e.g., monitoring of a city infrastructure or a highway). For home automation applications, it is 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 containing on the order of 10^2 to 10^4 sensing nodes each [RFC5548]. It is therefore necessary that routing mechanisms are designed to be scalable for operation in networks of various sizes. However, due to a lack of memory size 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.

• Longevity: The procedure of route repair and related control messages SHOULD NOT harm overall energy consumption from the routing protocols.

[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 are repaired quickly, fewer data packets are dropped, and a smaller number of routing protocol packet transmissions are needed, since routes can be repaired without source-initiated route discovery [Lee]. One important consideration here may be to avoid 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 routing protocol message overhead.

Topological node mobility may be the result of physical movement and/or a changing radio environment, making it very likely that mobility needs to be handled even in a network with physically static nodes. 6LoWPANs do not make use of a separate protocol to maintain connectivity to moving nodes but expects the routing protocol to handle it.

In addition, some nodes may move from one 6LoWPAN to another and are expected to become functional members of the latter 6LoWPAN in a limited amount of time.

Building monitoring applications, for instance, have a number of requirements with respect to recovery and settling time for mobility that range between 5 and 20 seconds (Section 5.3.1 of [RFC5867]). For more interactive applications such as those used in home automation systems, where users provide input and expect instant feedback, mobility requirements are also 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 are not normally being used for such fast mobility, but dynamic association and disassociation MUST be supported in 6LoWPANs.

There are several challenges that should be addressed by a 6LoWPAN routing protocol 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 cannot easily be detected or distinguished by the routing protocols. Mobile nodes can be treated as nodes that disappear and reappear in another place. The tracking of movement patterns increases complexity and can be avoided by handling moving nodes using 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: In order 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. Many emerging applications include point-to-point communication as well. 6LoWPAN routing protocols should be designed with the consideration of forwarding packets from/to multiple sources/destinations. Current documents of the ROLL WG explain that the workload or traffic pattern of use cases for LoWPANs tends to be highly structured, unlike the any-to-any data transfers that dominate typical client and server workloads. In many cases, exploiting such structure may simplify difficult problems arising from resource constraints or variation in connectivity.

5.4. Support of Security

Security is a critical issue for low-power networks. Any solution for 6LoWPAN routing protocols SHOULD meet the following basic security requirements. These requirements MUST apply to the routing mechanism and network data exchange, while excessive power consumption and processing power usage should be avoided.

[R14] 6LoWPAN routing protocols SHOULD support message integrity, message source authentication, and message confidentiality services to defend against routing threats.

Considering the importance of routing protocol security and the nature of security threats to 6LoWPANs (for example, as described in [ROLL-SEC]), routing protocols SHOULD support:

• Message integrity, to prevent protocol message modification by intermediate nodes
• Message source authentication, to prevent spoofing attacks from forged sources
• Message confidentiality, to prevent passive eavesdropping

The timeliness of messages should also be considered. Outdated messages can themselves be a form of attack, in which case timeliness services at the application layer itself or together with data link security functions are helpful for 6LoWPANs.

Routing protocols MUST be protected against attacks such as replay, injection, modification, etc., which can lead to threats including routing or topology loops, targeted denial of service to specific nodes, generation of false routing information, resource exhaustion, or network partitioning [ROLL-SEC].

Security support will be an option and, if enabled, will comply with all rules for using secure 6LoWPAN routing protocols. By implementing link-layer security (security in CCM* mode as defined in Subclause 7.6 of IEEE 802.15.4) and adding additional routing protocol-specific security and message integrity checking mechanisms (such as timestamps or sequence numbers), resistance to most security threats can be achieved.

The design MUST consider the cost of heavyweight operations that the protocol MUST perform. For example, using public keys may result in higher energy consumption compared to symmetric keys. General solutions for security operations that require large amounts of node state (such as address/key management, authentication, link-layer key establishment) should be used across all LoWPAN protocols to save overhead. 6LoWPAN routing protocols SHOULD be designed to support enabling these features, and these features themselves should be careful not to consume excessive power.

5.5. Support of Mesh-Under Forwarding

The current 6LoWPAN architecture allows multi-hop forwarding through mesh-under routing [RFC4944]. A key characteristic of this approach is that the ability to support mesh-under forwarding and route-over routing can be a requirement in 6LoWPAN protocols. But whether this is a requirement for 6LoWPAN routing protocols remains an open question. In this regard, we need to consider the requirements for these two different approaches (one using IP routing, the other using its own forwarding mechanism).

The mesh-under forwarding mechanism uses link-layer addresses (MAC addresses), so it stops at the boundary of an IP subnet. When used in conjunction with route-over routing that uses IPv6 addresses and routing tables, it may require cross-layer information, including its own forwarding table.

For this reason, the mesh-under forwarding mechanism may provide its own topology maintenance messages and forwarding table for related operations. This may be comparable to the functionality required by route-over routing protocols, which are used for neighbor/link discovery, management of forwarding table entries, topology maintenance, and path discovery.

Therefore, a key question is how these two approaches (route-over and mesh-under) should be combined, how they can work in coordination, thereby avoiding any redundancy or interoperability issues that may arise. Future work should focus specifically on these architectural issues.

5.6. Support of Management

For network management, the following requirements SHOULD be considered.

LoWPANs may need to be dynamically configured and initialized, for example, after a gateway powers up, it does not know which nodes belong to its subnet. The ability of nodes to join a network is inherently independent of routing technology, although some routing protocols may facilitate this process. Routing protocols SHOULD support the initialization and configuration of the network. This may involve interaction between the routing protocol and other functions such as address assignment, autoconfiguration, and neighbor discovery.

For monitoring and debugging, the ability to obtain relevant routing protocol parameters, current configuration, and current state of router and host functionality is important. It should be possible to obtain information such as routing tables, neighbor tables, message counts, and link quality information. Interfaces for diagnostics, fault detection, monitoring, and event/alarm reporting functions should be considered. While existing protocols and interfaces may be available for this purpose in some cases, solutions specifically tailored for LoWPANs may be needed.

Because certain LoWPANs typically periodically enter sleep mode, it should be possible to control the node sleep/wake pattern so that information can be collected with lower latency.

The ability to support routing protocol evolution and to change routing parameters based on circumstances and traffic patterns is important. For example, it may be necessary to select a metric type, adjust timer values, or select/change the mode of the protocol (if supported). One possibility is to switch to a completely different protocol. However, this may not be feasible due to code size requirements. Users should be able to support implementations of multiple routing protocols.

The following additional management aspects should be considered:

• Device management and node topology configuration capabilities
• Security management, including key management
• Sleep schedule management
• Quality of service management
• Path repair, fault detection, and control
• Cross-layer integration and coordination