6LoWPAN Working Group E. Kim
Internet-Draft ETRI
Expires: May 7, 2009 D. Kaspar
Simula Research Laboratory
C. Gomez
Tech. Univ. of Catalonia/i2CAT
C. Bormann
Universitaet Bremen TZI
November 3, 2008
Problem Statement and Requirements for 6LoWPAN Routing
draft-dokaspar-6lowpan-routreq-07
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009.
Kim, et al. Expires May 7, 2009 [Page 1]
Internet-Draft 6LoWPAN Routing Requirements November 2008
Abstract
This document provides the problem statement for 6LoWPAN routing. It
also defines the requirements for 6LoWPAN routing considering the
low-power characteristics of the network and its devices.
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2. Design Space . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Scenario Considerations and Parameters for 6LoWPAN Routing . . 8
4. 6LoWPAN Routing Requirements . . . . . . . . . . . . . . . . . 12
4.1. Support of 6LoWPAN Device Properties . . . . . . . . . . . 12
4.2. Support of 6LoWPAN Link Properties . . . . . . . . . . . . 14
4.3. Support of 6LoWPAN Network Characteristics . . . . . . . . 16
4.4. Support of Security . . . . . . . . . . . . . . . . . . . 19
4.5. Support of Mesh-under Forwarding . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Kim, et al. Expires May 7, 2009 [Page 2]
Internet-Draft 6LoWPAN Routing Requirements November 2008
1. Problem Statement
Low-power wireless personal area networks (LoWPANs) are formed by
devices complying to the IEEE 802.15.4 standard [5]. LoWPAN devices
are distinguished by their low bandwidth, short range, scarce memory
capacity, limited processing capability and other attributes of
inexpensive hardware. In this document, the characteristics of nodes
participating in LoWPANs are assumed to be those described in [3].
IEEE 802.15.4 networks support star and mesh topologies and consist
of two different device types: reduced-function devices (RFDs) and
full-function devices (FFDs). RFDs have the most limited
capabilities and are intended to perform only simple and basic tasks.
RFDs may only associate with a single FFD at a time, but FFDs may
form arbitrary topologies and accomplish more advanced functions,
such as multi-hop routing.
However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format
specification ("IPv6 over IEEE 802.15.4" [4]) specify how mesh
topologies could be obtained and maintained. Thus, the 6LoWPAN
formation and multi-hop routing should be supported by higher layer,
either 6LoWPAN adaptation layer or IP layer. In the IETF, a number
of experimental protocols in IP layer have been developed in many
working groups. However, these existing routing protocols may not be
satisfying for mesh routing in a LoWPAN domain, for the following
reasons:
o 6LoWPAN nodes have special types and roles, such as primary
battery-operated RFDs, battery-operated and mains-powered FFDs,
possibly various levels of RFDs and FFDs, mains-powered and high-
performance gateways, data aggregators, etc. 6LoWPAN routing
protocols should support multiple device types and roles.
o The more stringent requirements that apply to 6LoWPANs as opposed
to higher performance or non-battery-operated networks. 6LoWPAN
nodes are characterized by small memory sizes, low processing
power, and are running on very limited power supplied by primary
non-rechargeable batteries (a few kBytes of RAM, a few dozens of
KBytes of ROM/flash memory, and a few MHz of CPU is typical). A
node's lifetime is usually defined by the lifetime of its battery.
o Handling sleeping nodes is very critical in 6LoWPANs, more than in
traditional ad-hoc networks. 6LoWPAN nodes might stay in sleep-
mode for most of the time. Time synchronization is important for
efficient forwarding of packets.
o A possibly simpler routing problem; 6LoWPANs might be either
transit-networks or stub-networks. We can focus on stub networks
Kim, et al. Expires May 7, 2009 [Page 3]
Internet-Draft 6LoWPAN Routing Requirements November 2008
first as existing 6LoWPAN documents (implicitly or explicitly)
show the 6LoWPAN picture under the configuration of stub networks
at this moment [4], [7]. We can simplify networks by an
assumption of no transit networks. (based on the necessity, we may
extend the network configuration including transit network case)
o A possibly harder routing problem; routing in 6LoWPANs requires to
consider power-optimization, harsh environment, data-aware
routing, etc. These are not easy requirements to satisfy
together.
This creates new challenges on obtaining robust and reliable routing
within LoWPANs.
The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals"
[3]) briefly mentions four requirements on routing protocols;
(a) low overhead on data packets
(b) low routing overhead
(c) minimal memory and computation requirements
(d) support for sleeping nodes considering battery saving
These four high-level requirements only describe the need for low
overhead and power saving. But, based on the fundamental features of
LoWPAN, more detailed routing requirements are presented in this
document, which can lead to further analysis and protocol design.
Using the 6LoWPAN header format[6], there are two layers routing
protocols can be defined at, commonly referred to as "mesh-under" and
"route-over". The mesh-under approach supports routing under the IP
link and is directly based on the link-layer IEEE 802.15.4 standard,
therefore using (64-bit or 16-bit short) MAC addresses. On the other
hand, the route-over approach relies on IP routing and therefore
supports routing over possibly various types of interconnected links
(see also Figure 1). Most statements in this document consider both
the mesh-under and route-over cases.
[Note] ROLL WG is now working on the protocol survey for Low power
and Lossy Networks (LLNs), not specifically for 6LoWPAN. It will
decide whether new solution will be developed or not, after that
survey. This document is focused on 6LoWPAN specific requirements,
in alignment with ROLL WG.
Considering the problems above, The detailed 6LoWPAN routing
requirements must be defined. Application-specific features affect
the design of 6lowpan routing requirements and the corresponding
Kim, et al. Expires May 7, 2009 [Page 4]
Internet-Draft 6LoWPAN Routing Requirements November 2008
solutions. However, various applications can be profiled by similar
technical characteristics, although the detail requirements differ.
(e.g., a few dozens nodes for home lighting system needs appropriate
'scalability' for the applications, while billions of nodes for
highway infrastructure system also needs appropriate 'scalability'.)
This document states the routing requirements to consider the
features of 6LoWPAN applications in general, while trying to give
example cases for different cases of routing. It is noted that this
one routing requirement document does not mean that having a single
routing solution may be the best one for all 6LoWPAN applications.
Kim, et al. Expires May 7, 2009 [Page 5]
Internet-Draft 6LoWPAN Routing Requirements November 2008
2. Design Space
Apart from a wide variety of routing algorithms possible for 6LoWPAN,
the question remains as to whether routing should be performed mesh-
under (in the adaptation layer defined by the 6lowpan format document
[4]), or in the IP-layer using a route-over approach. The most
significant consequence of mesh-under routing is that routing would
be directly based on the IEEE 802.15.4 standard, therefore using (64-
bit or 16-bit short) MAC addresses instead of IP addresses, and a
LoWPAN would be seen as a single IP link. In case a route-over
mechanism is to be applied to a LoWPAN it must also support 6LoWPAN's
unique properties using global IPv6 addressing. One radio hop would
be seen as a single IP link [7].
Figure 1 shows the place of 6LoWPAN routing in the entire network
stack;
+-----------------------------+ +-----------------------------+
| Application Layer | | Application Layer |
+-----------------------------+ +-----------------------------+
| Transport Layer (TCP/UDP) | | Transport Layer (TCP/UDP) |
+-----------------------------+ +-----------------------------+
| Network Layer (IPv6) | | Network +---------+ |
+-----------------------------+ | Layer | Routing | |
| 6LoWPAN +---------+ | | (IPv6) +---------+ |
| Adaptation | Routing | | +-----------------------------+
| Layer +---------+ | | 6LoWPAN Adaptation Layer |
+-----------------------------+ +-----------------------------+
| IEEE 802.15.4 (MAC) | | IEEE 802.15.4 (MAC) |
+-----------------------------+ +-----------------------------+
| IEEE 802.15.4 (PHY) | | IEEE 802.15.4 (PHY) |
+-----------------------------+ +-----------------------------+
Figure 1: Mesh-under (left) and route-over routing (right)
In order to avoid packet fragmentation and the overhead for
reassembly, routing packets should fit into a single IEEE 802.15.4
physical frame and application data should not be expanded to an
extent that they no longer fit.
If a mesh-under routing protocol is built for operation in 6LoWPAN's
adaptation layer, routing control packets are placed after the
6LoWPAN Dispatch, unless a new code type is assigned for mesh-under
routing. Multiple routing protocols can be supported by the usage of
different Dispatch bit sequences. In a specific use-case can use
mesh-header in [4]for pre-defined L2 forwarding. When a route-over
protocol is built in the IPv6 layer, the Dispatch value can be chosen
as one of the Dispatch patterns for 6LoWPAN compressed or
Kim, et al. Expires May 7, 2009 [Page 6]
Internet-Draft 6LoWPAN Routing Requirements November 2008
uncompressed IPv6, followed by the IPv6 header.
If a 6LoWPAN is formed like the Figure 2 , the PnC is the only IPv6
router in the LoWPAN in the assumption of [4]. The mesh-under
routing mechanism MUST be provided to forward packets which require
multi-hop forwarding.
If route-over routing is used in the stub-network, not only the PnC
but also other intermediate nodes become LoWPAN router and set up
IPv6 paths for multi-hop transmission.
O X
/ | PnC: PAN Coordinator
PnC --- O --- O --- X O: Intermediate node (FFD)
/ \ X: End host (FFD or RFD)
X O --- X
|
/ \
O - O -- X
Figure 2: An example of a 6LoWPAN
If multiple 6LoPWANs are formed with globally unique IPv6 addresses
in the 6LoWPANs, and node (a) of 6LoWPAN [A] wants to communicate
with node (b) of 6LoWPAN [B], the PnC (= IPv6 router at the edge of
the LoWPAN) will be always the default router for the outgoing packet
of the 6LoWPAN.
Kim, et al. Expires May 7, 2009 [Page 7]
Internet-Draft 6LoWPAN Routing Requirements November 2008
3. Scenario Considerations and Parameters for 6LoWPAN Routing
IP-based low-power WPAN technology is still in its early stage of
development, but the range of conceivable usage scenarios is
tremendous. The numerous possible applications of sensor networks
make it obvious that mesh topologies will be prevalent in LoWPAN
environments and routing will be a necessity for expedient
communication. Research efforts in the area of sensor networking
have put forth a large variety of multi-hop routing algorithms [6].
Most related work focuses on optimizing routing for specific
application scenarios, which can largely be categorized into several
models of communication, including the following ones:
o Flooding (in very small networks)
o Data-aware routing (dissemination vs. gathering)
o Event-driven vs. query-based routing
o Geographic routing
o Probabilistic routing
o Hierarchical routing
Depending on the topology of a 6LoWPAN and the application(s) running
over it, different types of routing may be used. However, this
document abstracts from application-specific communication and
describes general routing requirements valid for overall routing in
6LoWPANs.
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.
* Connectivity:
Due to external factors or programmed disconnections, a
6LoWPAN 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
Kim, et al. Expires May 7, 2009 [Page 8]
Internet-Draft 6LoWPAN Routing Requirements November 2008
across a LoWPAN.
* Dynamicity (include 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 is heavily dependent on the number
of moving nodes in a LoWPAN and their speed.
* Deployment:
In a LoWPAN, it is possible for nodes to be scattered randomly
or to be deployed in an organized manner. The deployment can
occur at once, or as an iterative process, which may also
affect the routing state.
* Spatial Distribution of Nodes and Gateways:
Network connectivity depends on node spatial distribution
besides other factors like device number, density and
transmission range. For instance, nodes can be placed on a
grid, or can be randomly placed in an area (bidimensional
Poisson distribution), etc. In addition, if the LoWPAN is
connected to other networks through infrastructure nodes
called gateways, the number and spatial distribution of
gateways affects network congestion and available bandwidth,
among others.
* Traffic Patterns, Topology and Applications:
The design of a LoWPAN and the requirements on its application
have a big impact on the network topology and the most
efficient routing type to be used. For different traffic
patterns (point-to-point, multipoint-to-point, point-to-
multipoint) and network architectures, various routing
mechanisms have been introduced, such as data-aware, event-
driven, address-centric, and geographic routing.
* Quality of Service (QoS):
For mission-critical applications, support of QoS is mandatory
in resource-constrained LoWPANs and cannot be achieved without
a certain degree of routing protocol overhead.
* Security:
LoWPANs may carry sensitive information and require a high
level of security support where the availability, integrity,
and confidentiality of data are primordial. Secured messages
cause overhead and affect the power consumption of LoWPAN
routing protocols.
Kim, et al. Expires May 7, 2009 [Page 9]
Internet-Draft 6LoWPAN Routing Requirements November 2008
b. Node Parameters:
* Processing Speed and Memory Size:
These basic parameters define the maximum size of the routing
state. LoWPAN nodes may have different performance
characteristics beyond the common RFD/FFD distinction.
* Power Consumption and Power Source:
The number and topology of battery- and mains-powered nodes in
a LoWPAN affect routing protocols in their selection of
optimal paths for network lifetime maximization.
* 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 high-
loaded nodes (either because they are the source of packets to
be transmitted or due to forwarding) may incur a greater
contribution to delivery delays than low-loaded nodes. This
applies to both data packets and routing control messages
themselves.
c. Link Parameters:
* 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 [17]:
+ 16-bit MAC addresses, unreliable mode: 151.6 kbps
+ 16-bit MAC addresses, reliable mode: 139.0 kbps
+ 64-bit MAC addresses, unreliable mode: 135.6 kbps
+ 64-bit MAC addresses, reliable mode: 124.4 kbps
In the case of 915 MHz band:
+ 16-bit MAC addresses, unreliable mode: 31.1 kbps
+ 16-bit MAC addresses, reliable mode: 28.6 kbps
Kim, et al. Expires May 7, 2009 [Page 10]
Internet-Draft 6LoWPAN Routing Requirements November 2008
+ 64-bit MAC addresses, unreliable mode: 27.8 kbps
+ 64-bit MAC addresses, reliable mode: 25.6 kbps
In the case of 868 MHz band:
+ 16-bit MAC addresses, unreliable mode: 15.5 kbps
+ 16-bit MAC addresses, reliable mode: 14.3 kbps
+ 64-bit MAC addresses, unreliable mode: 13.9 kbps
+ 64-bit MAC addresses, reliable mode: 12.8 kbps
* Latency:
The range of latencies 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 follows
[20]:
+ 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]
In the case of 915 MHz band:
+ 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]
In the case of 868 MHz band:
+ 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]
Kim, et al. Expires May 7, 2009 [Page 11]
Internet-Draft 6LoWPAN Routing Requirements November 2008
4. 6LoWPAN Routing Requirements
This section defines a list of requirements for 6LoWPAN routing. The
most important design property unique to low-power networks is that
6LoWPANs have to support multiple device types and roles, for
example:
o primarily battery-operated host nodes
o mains-powered host nodes
o possibly various levels of nodes (data aggregators, relayers,
etc.)
o mains-powered, high-performance gateway(s)
Due to these unique device types and roles 6LoWPANs need to consider
the following two primary features:
o Power conservation: some devices are mains-powered, but most 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 for possibly extended periods
from batteries (e.g. on a construction site before building power
is switched on for the first time).
o Low performance: tiny devices, small memory sizes, low-performance
processors, low bandwidth, high loss rates, etc.
These fundamental features of LoWPANs affect the design of routing
solutions, so that existing routing specifications should be
simplified and modified to the smallest extent possible when there
are appropriate solutions to adapt, otherwise, new solutions should
be introduced in order to fit the low-power requirements of LoWPANs,
meeting the following requirements:
4.1. Support of 6LoWPAN Device Properties
The general objectives listed in this subsection should be followed
by 6LoWPAN routing protocols. The importance of each requirement is
dependent on what device type the protocol is running on and what the
role of the device is. The following requirements are based on
battery-powered LoWPAN devices.
[R01] 6LoWPAN routing protocols SHOULD have small code size of
routing protocol stack and require low routing state to fit the
typical 6LoWPAN node capacity. (e.g., code size considering its
typical flash memory size, and routing table less than 32 entries)
Kim, et al. Expires May 7, 2009 [Page 12]
Internet-Draft 6LoWPAN Routing Requirements November 2008
A LoWPAN routing protocol solution should consider the limited
memory size typically starting at 4KB. RAM size of 6LoWPAN nodes
often ranges between 2KB and 10KB, and program flash memory
normally consists of 48KB to 128KB. (e.g., in the current market,
MICAz has 128KB program flash, 4KB EEPROM, 512KB external flash
ROM; TIP700CM has 48KB program flash, 10KB RAM, 1MB external flash
ROM).
Due to these hardware restrictions, code length should be
considered to fit within a small memory size; no more than 48KB to
128KB of flash memory including at least a few tens of KB of
application code size. A routing protocol of low complexity helps
to achieve the goal of reducing power consumption, improves
robustness, requires lower routing state, is easier to analyze,
and may be implicitly less prone to security attacks.
In addition, operation with low routing state (such as routing
tables and neighbor lists) SHOULD be maintained since some typical
memory sizes preclude to store state of a large number of nodes.
For instance, industrial monitoring applications need to support
at maximum 20 hops [14]. Small networks, can be designed to
support a smaller number of hops. It is highly dependent on
network architecture, but considering the 6LoWPAN device
properties, there should be at least one mode of operation that
can function with 32 forwarding entries or less.
[R02] 6LoWPAN routing protocol control messages SHOULD not create
fragmentation of physical layer (PHY) frames.
In order to save energy, routing overhead should be minimized to
prevent fragmentation of frames on the physical layer (PHY).
Therefore, 6LoWPAN routing should not cause packets to exceed the
IEEE 802.15.4 frame size. This reduces the energy required for
transmission, avoids unnecessary waste of bandwidth, and prevents
the need for packet reassembly. As calculated in RFC4944 [4], the
maximum size of a 6LoWPAN frame, in order not to cause
fragmentation on the PHY layer, is 81 octets.
[R03] 6LoWPAN routing protocols SHOULD cause minimal power
consumption by the efficient use of control packets (e.g., minimize
expensive multicast which cause broadcast to the entire LoWPAN).
Routing protocol design for 6LoWPAN should consider IEEE 802.15.4
link layer feedback on energy consumption. Power-aware routing is
a non-trivial task, because it is affected by many mutually
conflicting goals:
Kim, et al. Expires May 7, 2009 [Page 13]
Internet-Draft 6LoWPAN Routing Requirements November 2008
* Minimization of total energy consumed in the network
* Maximization of the time until a network partition occurs
* Minimizing the energy variance at each node
* Minimizing the cost per packet
while maintaining packet delivery ratio, latency or other
requirements depending on each application.
One way of battery lifetime optimization is by achieving a minimal
control message overhead. Compared to functions such as in many
devices, computational operations or taking sensor samples, radio
communications is by far the dominant factor of power consumption
[8]. 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 [11].
In [9] the energy consumption of two example RF controllers for
low-power nodes is shown. The TR1000 radio consumes 21mW on
transmitting at 0.75mW, and 15mW on reception (with a receiver
sensitivity of -85dBm). The CC1000 consumes 31.6mW on
transmitting 0.75mW, and 20mW for receiving (with a receiver
sensitivity of -105dBm). [9] explains the power continuation under
the concept of an idealized power source: based on the energy of
idealized AA battery, the CC1000 can transmit for approximately 4
days straight or receive for 9 days straight.
One multicast packet causes reception of the entire nodes in the
LoWPAN, while only the nodes in the path use the reception energy
at unicast. Thus, 6LoWPAN routing protocol SHOULD minimize the
control cost by the routing packets.
4.2. Support of 6LoWPAN Link Properties
6LoWPAN links have the characteristics of low bandwidth and possibliy
high loss rates. The routing requirements described in this
subsection are from the link properties.
[R04] The design of routing protocols for 6LoWPANs must consider the
fact that packets are to be delivered with reasonable probability.
Latency requirements may differ from a few hundreds milliseconds
to minutes, depending on the type of application. Real-time
building automation applications usually need response times below
500 ms between ingress and egress, while forced entry securty
alerts must be routed to one or more fixed or mobile user devices
Kim, et al. Expires May 7, 2009 [Page 14]
Internet-Draft 6LoWPAN Routing Requirements November 2008
within 5 seconds [16]. 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
1s [14]. In contrast to this, urban monitoring applications allow
latencies smaller than the typical intervals used for reporting
sensed information; for instance, in the order of seconds or
minutes [15].
The range of latencies of a frame transmission between a single
sender and a single receiver through an unslotted IEEE 802.15.4
2.4 GHz channel is between 2.46ms and 6.02ms in 64 bit MAC address
unreliable mode and 2.20 ms to 6.56ms in 64 bit address reliable
mode. The range of latencies of 868 MHz band is from 11.7 ms to
63.7 ms, different from address types and reliable/unreliable
mode.
Considering the 6LoWPAN link latency, routing protocols can
calculate the probable delivering time of the control packets in a
normal case not more than a few hundred ms between two nodes.
[R05] 6LoWPAN routing protocols SHOULD be robust to dynamic loss
caused by link failure or device unavailability either in short-term
(e.g. due to RSSI variation, interference variation, noise and
asynchrony) or in long-term (e.g. due to a depleted power source,
hardware breakdown, operating system misbehavior, etc).
An important trait of 6LoWPAN devices is their unreliability due
to limited system capabilities, and also because they might be
closely coupled to the physical world with all its unpredictable
variation. In harsh environments, LoWPANs easily suffer from link
failure. Collision or link failure easily increases Send Queue/
Receive Queue (SQ/RQ) and it can lead to queue overflow and packet
losses.
For home applications, where users expect feedback after carrying
out 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 [13]. The tolerance of
the recovery time can vary dependent 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 of node failure.
Kim, et al. Expires May 7, 2009 [Page 15]
Internet-Draft 6LoWPAN Routing Requirements November 2008
4.3. Support of 6LoWPAN Network Characteristics
6LoWPAN can be deployed with different tolerance levels, network
scales, topologies, levels of mobility, etc. In any case, 6LoWPAN
must be maintain low energy consumption. The requirements described
in the following subsection are derived from the network feature of
6LoWPANs.
[R06] 6LoWPAN routing protocols SHOULD be reliable despite
unresponsive nodes due to periodic hibernation. (e.g., management
with the duty cycle)
Many nodes in 6LoWPAN environments might periodically hibernate
(i.e. disable their transceiver activity) in order to save energy.
Therefore, routing protocols must ensure robust packet delivery
despite nodes frequently shutting off their radio transmission
interface. Feedback, for instance from periodic beacons, from the
lower IEEE 802.15.4 layer may be considered to enhance the power-
awareness of 6LoWPAN routing protocols.
In [9] it is explained that CC1000-based nodes must operate at a
duty cycle of approximately 2% to survive for one year from
idealized AA battery power source. For home automation purposes,
it is suggested that that the devices have to maximize the sleep
phase with a duty cycle lower than 1% [13], while in building
automation, batteries must be operational for at least 5 years
when the sensing devices are transmitting data (e.g. 64 bytes)
once per minute [16].
Dependent on the application in use, packet rates differ from
1/sec to 1/day. Routing protocols need to know the cycle of the
packet transmission and utilize the information to calculate
routing pathes.
[R07] The metric used by 6LoWPAN routing protocols MAY utilize a
combination of the inputs provided by the MAC layer and other
measures to obtain optimal path considering energy balance and link
quality.
Simple hop-count-only mechanisms may be inefficient in 6LoWPANs.
In home, buildings, or infrastructure, some nodes will be
installed with mains-powered. Such power-installed node MUST be
considered as a relay point for more roles in packet delivery.
6LoWPAN routing protocols MUST know the power source of the nodes.
There is a Link Quality Indicator (LQI), Link Delivery Ratio
(LDR), or/and RSSI from IEEE 802.15.4 that may be taken into
account for better metrics. The metric to be used (and its goal)
Kim, et al. Expires May 7, 2009 [Page 16]
Internet-Draft 6LoWPAN Routing Requirements November 2008
may depend on application and requirements.
The numbers in Figure 3 represent the Link Delivery Ratio (LDR)
between each pair of nodes. There are studies that show a
piecewise linear dependence between LQI and LDR [12].
0.6
A-------C
\ /
0.9 \ / 0.9
\ /
B
Figure 3: An example network
In this simple example, there are two options in routing from node
A to node C:
A. Path AC:
+ (1/0.6) = 1.67 avg. transmissions needed for each packet
+ one-hop path
+ good in energy consumption, bad in delivery ratio (0.6)
B. Path ABC
+ 2*(1/0.81) = 2.47 avg. transmissions needed for each packet
+ two-hop path
+ bad in energy consumption, good in delivery ratio (0.81)
If energy consumption of the network must be minimized, path AC is
the best (this path would be chosen by hop count metric).
However, if delivery ratio in that case is not sufficient, best
path is ABC (it would be chosen by an LQI based metric).
Combinations of both of metrics can be used.
[R08] 6LoWPAN routing protocols SHOULD be designed to achieve both
scalability from a few nodes to millions of nodes and minimality in
terms of used system resources.
A 6LoWPAN may consist of just a couple of nodes (for instance in a
body-area network), but may expand to much higher numbers of
devices (e.g. monitoring of a city infrastructure or a highway).
Kim, et al. Expires May 7, 2009 [Page 17]
Internet-Draft 6LoWPAN Routing Requirements November 2008
For home automation applications it is envisioned that the routing
protocol must support 250 devices in the network [13], 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 [15].
It is therefore necessary that routing mechanisms are designed to
be scalable for operation in various network sizes. However, due
to a lack of memory size and computational power, 6LoWPAN routing
might limit forwarding entries to a small number, such as at
maximum 32 routing table entries.
[R09] 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 is needed since routes can be
repaired without source initiated Route Discovery [10].
[R10] 6LoWPAN routing protocols SHOULD allow for dynamically adaptive
topologies and mobile nodes. When supporting dynamic topologies and
mobile nodes, route maintenance should be managed by keeping in mind
the goal of a minimal routing state.
Building monitoring applications, for instance, require that the
mobile devices SHOULD be capable of unjoining (handing-off) from
an old network joining onto a new network within 15 seconds [16].
More interactive applications such as used in home automation
systems, where users are giving input and expect instant feedback,
mobility requirements are also stricter and a convergence time
below 0.5 seconds is commonly required [13]. In industrial
environments, where mobile equipment such as cranes move around,
vehicular speeds of up to 35 kmph are required to be supported by
the routing protocol [14]. Currently, 6LoWPANs are not being used
for such a fast mobility cases, but dynamic association and
deassociation MUST be supported in 6LoWPAN.
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 6LoWPAN:
If the nodes' movement pattern is unknown, mobility cannot
easily be detected or distinguished from the routing protocols.
Mobile nodes can be treated as nodes that disappear and re-
appear in another place. Movement pattern tracking increases
Kim, et al. Expires May 7, 2009 [Page 18]
Internet-Draft 6LoWPAN Routing Requirements November 2008
complexity and can be avoided by handling moving nodes using
reactive route updates.
* Movement of a 6LoWPAN with respect to other (inter)connected
6LoWPANs:
Within stub networks, more powerful gateway nodes need to be
configured to handle moving 6LoWPANs.
* Nodes permanently joining or leaving the 6LoWPAN:
In order to ease routing table updates and reduce error control
messages, it would be helpful if nodes leaving the network
inform their coordinator about their intention to disassociate.
[R11] 6LoWPAN routing protocol SHOULD support various traffic
patterns; point-to-point, point-to-multipoint, and multipoint-to-
point, while avoid excessive multicast traffic (broadcast in Link) in
6LoWPAN.
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 WG drafts in the ROLL
working group explain that the workload or traffic pattern of use
cases for 6LoWPANs tend 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.
4.4. Support of Security
The routing requirement described in this subsection allow secure
transmission of routing messages. Solutions may take into account
the specific features of IEEE 802.15.4 MAC layers.
[R12] 6LoWPAN protocols SHOULD support secure delivery of control
messages. A minimal security level can be achieved by utilizing AES-
based mechanism provided by IEEE 802.15.4.
Security threats within LoWPANs may be different from existing
threat models in ad-hoc network environments. Neighbor Discovery
in IEEE 802.15.4 links may be susceptible to threats as listed in
RFC3756 [2]. Bootstrapping may also impose additional threats.
Security is also very important for designing robust routing
protocols, but it should not cause significant transmission
overhead. While there are applications which require very high
security, such as in traffic control, other applications are less
Kim, et al. Expires May 7, 2009 [Page 19]
Internet-Draft 6LoWPAN Routing Requirements November 2008
easily harmed by wrong node behavior, such as a home entertainment
system.
The IEEE 802.15.4 MAC provides an AES-based security mechanism.
Routing protocols need to define how this mechanism can be used to
obtain the intended security. 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.
4.5. Support of Mesh-under Forwarding
One 6LoWPAN may be built as one IPv6 link. In this case, mesh-under
forwarding/routing must be supported. The routing requirements
described in this subsection allow optimization and correct operation
of routing solutions taking into account the specific features mesh-
under routing.
[R13] In case a routing protocol operates in 6LoWPAN's adaptation
layer, then routing tables and neighbor lists MUST support 16-bit
short and 64-bit extended addresses.
[R14] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending
"Hello" messages. Instead, link-layer mechanisms (such as
acknowledgments or beacon responses) MAY be utilized to keep track of
active neighbors.
After an IEEE 802.15.4 PAN coordinator permits a device to join,
the new device adds the PAN coordinator to its neighbor list and
starts transmitting periodic beacons. These beacons can be used
as an indication of current neighbors.
[R15] In case there are one or more alternative PAN coordinators, the
coordinators MAY take the role of keeping track of node association
and de-association within the LoWPAN.
[R16] Alternative PAN coordinators, if any, MAY be a relay point of
group-targeting message instead of using multicast (broadcast in the
link layer).
For example, RS and RA can be only sent to the coordinators,
instead of being multicast. The coordinators take the role to
pass the packets to their own neighbors.
Kim, et al. Expires May 7, 2009 [Page 20]
Internet-Draft 6LoWPAN Routing Requirements November 2008
5. Security Considerations
Security issues are described in Section 4.4. More security
considerations will follow the 6LoWPAN security analysis work.
Kim, et al. Expires May 7, 2009 [Page 21]
Internet-Draft 6LoWPAN Routing Requirements November 2008
6. Acknowledgements
The authors thank Myung-Ki Shin for giving the idea of writing this
draft. The authors also thank to S. Chakrabarti who gave valuable
comments for mesh-under requirements.
Kim, et al. Expires May 7, 2009 [Page 22]
Internet-Draft 6LoWPAN Routing Requirements November 2008
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[3] 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.
[4] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks",
RFC 4944, September 2007.
[5] IEEE Computer Society, "IEEE Std. 802.15.4-2006 (as amended)",
2007.
7.2. Informative References
[6] Bulusu, N. and S. Jha, "Wireless Sensor Networks", July 2005.
[7] Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E.
Nordmark, "LoWPAN Neighbor Discovery Extensions,
draft-shelby-6lowpan-nd-00 (work in progress)", October 2008.
[8] Pister, K. and B. Boser, "Smart Dust: Wireless Networks of
Millimeter-Scale Sensor Nodes".
[9] Hill, J., "System Architecture for Wireless Sensor Networks".
[10] Lee, S., Belding-Royer, E., and C. Perkins, "Scalability Study
of the Ad Hoc On-Demand Distance-Vector Routing Protocol",
March 2003.
[11] Shih, E., "Physical Layer Driven Protocols and Algorithm Design
for Energy-Efficient Wireless Sensor Networks", July 2001.
[12] Chen, B., Muniswamy-Reddy, K., and M. Welsh, "Ad-Hoc Multicast
Routing on Resource-Limited Sensor Nodes", 2006.
[13] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing
Requirement in Low Power and Lossy Networks,
draft-ietf-roll-home-routing-reqs-04 (work in progress)",
Kim, et al. Expires May 7, 2009 [Page 23]
Internet-Draft 6LoWPAN Routing Requirements November 2008
October 2008.
[14] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial
Routing Requirements in Low Power and Lossy Networks,
draft-ietf-roll-indus-routing-reqs-01 (work in progress)",
July 2008.
[15] Dohler, M., Watteyne, T., Winter, T., Barthel, D., and C.
Jacquenet, "Urban WSNs Routing Requirements in Low Power and
Lossy Networks, draft-ietf-roll-urban-routing-reqs-02 (work in
progress)", October 2008.
[16] Martocci, J., De Mil, P., Vermeylen, W., and N. Riou, "Building
Automation Routing Requirements in Low Power and Lossy
Networks, draft-ietf-roll-building-routing-reqs-01 (work in
progress)".
[17] Latre, M., De Mil, P., Moerman, I., Dhoedt, B., and P.
Demeester, "Throughput and Delay Analysis of Unslotted IEEE
802.15.4", May 2006.
Kim, et al. Expires May 7, 2009 [Page 24]
Internet-Draft 6LoWPAN Routing Requirements November 2008
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
Snaroya 1367
Norway
Phone: +47-6782-8223
Email: dokaspar.ietf@gmail.com
Carles Gomez
Tech. Univ. of Catalonia/i2CAT
Escola Politecnica Superior de Castelldefels
Avda. del Canal Olimpic, 15
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
Fax: +49-421-218-7000
Email: cabo@tzi.org
Kim, et al. Expires May 7, 2009 [Page 25]
Internet-Draft 6LoWPAN Routing Requirements November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Kim, et al. Expires May 7, 2009 [Page 26]