6LoWPAN Working Group E. Kim
Internet-Draft ETRI
Expires: September 26, 2009 D. Kaspar
Simula Research Laboratory
C. Gomez
Tech. Univ. of Catalonia/i2CAT
C. Bormann
Universitaet Bremen TZI
March 25, 2009
Problem Statement and Requirements for 6LoWPAN Routing
draft-ietf-6lowpan-routing-requirements-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 26, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Kim, et al. Expires September 26, 2009 [Page 1]
Internet-Draft 6LoWPAN Routing Requirements March 2009
Abstract
This document provides the problem statement for 6LoWPAN routing. It
also defines the requirements for 6LoWPAN routing considering IEEE
802.15.4 specificities and the low-power characteristics of the
network and its devices.
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Design Space . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. 6LoWPAN Headers for Routing . . . . . . . . . . . . . . . 8
3.2. Reference Network Model . . . . . . . . . . . . . . . . . 9
4. Scenario Considerations and Parameters for 6LoWPAN Routing . . 11
5. 6LoWPAN Routing Requirements . . . . . . . . . . . . . . . . . 16
5.1. Support of 6LoWPAN Device Properties . . . . . . . . . . . 16
5.2. Support of 6LoWPAN Link Properties . . . . . . . . . . . . 18
5.3. Support of 6LoWPAN Network Characteristics . . . . . . . . 20
5.4. Support of Security . . . . . . . . . . . . . . . . . . . 24
5.5. Support of Mesh-under Forwarding . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Kim, et al. Expires September 26, 2009 [Page 2]
Internet-Draft 6LoWPAN Routing Requirements March 2009
1. Problem Statement
In the context of this document, low-power wireless personal area
networks (LoWPANs) are formed by devices that are compatible with the
IEEE 802.15.4 standard [refs.IEEE802.15.4]. Most of the LoWPAN
devices are distinguished by their low bandwidth, short range, scarce
memory capacity, limited processing capability and other attributes
of inexpensive hardware. The characteristics of nodes participating
in LoWPANs are assumed to be those described in the 6LoWPAN problem
statement [RFC4919].
IEEE 802.15.4 networks support star and mesh topologies. However,
neither the IEEE 802.15.4 standard nor the 6LoWPAN format
specification ("IPv6 over IEEE 802.15.4" [RFC4944]) define how mesh
topologies could be obtained and maintained. Thus, the 6LoWPAN
formation and multi-hop routing should be supported by higher layers,
either the 6LoWPAN adaptation layer or the IP layer. A number of IP
routing protocols have been developed in various IETF working groups.
However, these existing routing protocols may not satisfy the
requirements of multi-hop routing in 6LoWPANs, for the following
reasons:
o 6LoWPAN nodes have special types and roles, such as nodes drawing
their power from primary batteries, power-affluent nodes, mains-
powered and high-performance gateways, data aggregators, etc.
6LoWPAN routing protocols should support multiple device types and
roles.
o More stringent requirements apply to LoWPANs, 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 LoWPANs, more than in
traditional ad-hoc networks. LoWPAN nodes might stay in sleep-
mode for most of the time. Taking advantage of appropriate times
for transmissions is important for efficient forwarding of
packets.
o Routing in 6LoWPANs might possibly translate to a simpler problem
than routing in higher-performance networks. LoWPANs might be
either transit networks or stub networks. Under the assumption
that LoWPANs are never transit networks (as implied by [RFC4944]),
routing protocols may be drastically simplified. This document
will focus on the requirements for stub networks. Additional
Kim, et al. Expires September 26, 2009 [Page 3]
Internet-Draft 6LoWPAN Routing Requirements March 2009
requirements may apply to transit networks.
o Routing in LoWPANs might possibly translate to a harder problem
than routing in higher-performance networks. Routing in LoWPANs
requires power-optimization, stable operation in harsh
environments, data-aware routing, etc. These requirements are not
easily satisfiable all at once [I-D.ietf-roll-protocols-survey].
This creates new challenges on obtaining robust and reliable routing
within LoWPANs.
The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals"
[RFC4919]) 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 describe the basic need for
6LoWPAN routing. Based on the fundamental features of 6LoWPAN, more
detailed routing requirements are presented in this document, which
can lead to further analysis and protocol design.
Using the 6LoWPAN header format [RFC4944], there are two layers
routing protocols can be defined at, commonly referred to as "Mesh
Under" and "Route Over". The Mesh Under approach performs its
routing below the IP link. It therefore is directly based on the
link-layer IEEE 802.15.4 standard, 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: The ROLL WG is now working on Route Over approaches for Low
power and Lossy Networks (LLNs), not specifically for 6LoWPAN. This
document focuses on 6LoWPAN-specific requirements; it may be used in
conjunction with the more application-oriented requirements defined
by the ROLL WG.
Considering the problems above, detailed 6LoWPAN routing requirements
must be defined. Application-specific features affect the design of
6LoWPAN routing requirements and the corresponding solutions.
However, various applications can be profiled by similar technical
characteristics, although the related detailed requirements might
differ (e.g., a few dozens of nodes for home lighting system need
Kim, et al. Expires September 26, 2009 [Page 4]
Internet-Draft 6LoWPAN Routing Requirements March 2009
appropriate scalability for the applications, while millions of nodes
for a highway infrastructure system also need appropriate
scalability). This document states the routing requirements of
6LoWPAN applications in general, while trying to give examples for
different cases of routing. This routing requirements document does
not imply that a single routing solution may be the best one for all
6LoWPAN applications.
Kim, et al. Expires September 26, 2009 [Page 5]
Internet-Draft 6LoWPAN Routing Requirements March 2009
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
that are 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 document defines additional terms:
LoWPAN Mesh Node
A LoWPAN node that forwards data between arbitary source-
destination pairs in 6LoWPAN adaptation layer using link-layer
addresses (and thus only exist in Mesh Under LoWPANs). A Mesh
Node may also serve as a LoWPAN Host.
Additionally, in alignment with all other 6LoWPAN drafts, this
document uses the same terms and definitions as provided by the
6LoWPAN ND draft [I-D.ietf-6lowpan-nd]:
LoWPAN Host
A node that only sources or sinks IPv6 datagrams is referred to as
a host in this document. The term node (see LoWPAN Node) is used
when the the differentiation between host and router is not
important.
LoWPAN Edge Router
An IPv6 router that interconnects the LoWPAN to another network.
Referred to as an edge router (ER) in this document.
LoWPAN Router
A node that forwards datagrams between arbitrary source-
destination pairs using a single 6LoWPAN interface performing IP
routing (and thus only exist in Route Over LoWPANs). A LoWPAN
Router may also serve as a LoWPAN Host - both sourcing and sinking
IPv6 datagrams. Refered to as a router in 6LoWPAN documents. All
LoWPAN Routers perform ND message relay on behalf of other nodes.
Kim, et al. Expires September 26, 2009 [Page 6]
Internet-Draft 6LoWPAN Routing Requirements March 2009
LoWPAN Node
A node that composes a LoWPAN. In Mesh Under, each intermediate
node performs multi-hop forwarding at L2. In Route Over, each
intermediate node serves as a LoWPAN router performing IP routing.
Mesh Under
A LoWPAN configuration where the link-local scope is defined by
the boundaries of the LoWPAN and includes all nodes within.
Forwarding and multihop routing functions are achieved at L2
between mesh nodes.
Route Over
A LoWPAN configuration where the link-local scope is defined as
the set of nodes reachable over a single radio transmission. Due
to the time-varying characteristics of wireless communication, the
neighbor set may change over time even when nodes maintain the
same physical locations. Multihop is achieved using IP routing.
Backbone Link
This is an IPv6 link that interconnects two or more edge routers.
It is expected to be deployed as a high speed backbone in order to
federate a potentially large set of LoWPANs.
LoWPAN Link
A low-power wireless link which is shared by a link-local scope in
a LoWPAN. In a LoWPAN, a link can be a very instable set of
nodes, for instance the set of nodes that can receive a packet
that is broadcast over the air in a Route Over LoWPAN, or the set
of nodes currently reachable in an L2 mesh in a Mesh Under LoWPAN.
Such a set may vary from one packet to the next as the nodes move
or as the radio propagation conditions change.
LoWPAN Subnet
A subnet including a LoWPAN or an aggregation of multiple LoWPANs
interconnected by a backbone link via Edge Routers, including the
backbone link, all with the same subnet prefix and prefix length.
Kim, et al. Expires September 26, 2009 [Page 7]
Internet-Draft 6LoWPAN Routing Requirements March 2009
3. Design Space
Apart from a wide variety of routing algorithms possible for 6LoWPAN,
it is possible to perform routing in the adaptation layer defined by
the 6LoWPAN format document [RFC4944], using the Mesh Under approach,
or in the IP-layer, using a Route Over approach. The most
significant consequence of Mesh Under routing is that the
characteristics of IEEE 802.15.4 directly affect the 6LoWPAN routing
mechanisms, therefore using (64-bit or 16-bit short) MAC addresses
instead of IP addresses, and a 6LoWPAN would be seen as a single IP
link. When a Route Over mechanism is to be applied to a 6LoWPAN it
must also support 6LoWPAN's unique properties using global IPv6
addressing.
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.
3.1. 6LoWPAN Headers for Routing
In the simplest case for a Mesh Under where layer two forwarding can
be performed without piggy-backing routing protocol information, the
mesh-header defined in RFC 4944 [RFC4944] is sufficient, see
Figure 2. Frame Delivery in a Link-Layer Mesh is described in the
Section 11 in RFC 4944.
Kim, et al. Expires September 26, 2009 [Page 8]
Internet-Draft 6LoWPAN Routing Requirements March 2009
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|V|F|HopsLft| originator address, final address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: 6LoWPAN Mesh Header
However, beyond the mesh header, additional information may need to
be transmitted for full routing functionality. If a Mesh Under
routing protocol is built for operation in 6LoWPAN's adaptation
layer, routing control packets with MAC addresses are placed after
the 6LoWPAN Dispatch. A new Dispatch value is REQUIRED to be
assigned for Mesh Under routing, see Figure 3. As shown in Figure 3,
multiple routing protocols can be supported by the usage of different
Dispatch bit sequences.
+---------------------+----------------+---------+----
| Dispatch (new val.) | Routing header | ...
+---------------------+----------------+---------+----
Figure 3: 6LoWPAN packet format and Mesh Under routing
When a Route Over protocol is built over the IPv6 layer, the Dispatch
value can be chosen as one of the Dispatch patterns for 6LoWPAN,
followed by a compressed or uncompressed IPv6 header, and Route Over
routing header will be included in the payload of IPv6 packet.
Figure 4 depicts an example of 6LoWPAN encapsulated Route Over
routing packets for the new header compression format defined in
[I-D.ietf-6lowpan-hc]:
+----------------------+-------------+------------------------+--
|Dispatch + LOWPAN_IPHC| IPv6 Header | Payload(Routing packet)|...
+----------------------+-------------+------------------------+--
Figure 4: 6LoWPAN IPHC packet format and Route Over routing
3.2. Reference Network Model
When a 6LoWPAN follows the Mesh Under configuration, the LoWPAN Edge
Router (ER) is the only IPv6 router in the 6LoWPAN (see Figure 5).
This means that the IPv6 link-local scope includes all nodes in the
LoWPAN. For this, a Mesh Under routing mechanism MUST be provided to
support multi-hop transmission.
If a Route Over routing is used in the stub-network, not only the ER
but also other intermediate nodes become LoWPAN Routers and perform
Kim, et al. Expires September 26, 2009 [Page 9]
Internet-Draft 6LoWPAN Routing Requirements March 2009
standard layer 3 routing (see Figure 6). In this case, the link-
local scope is defined by one radio hop.
h h
/ | ER: Edge Router
ER --- m --- m --- h m: Mesh Node
/ \ h: LoWPAN Host
h m --- h
|
/ \
m - m -- h
Figure 5: An example of a Mesh Under LoWPAN
h h
/ | ER: Edge Router
ER --- r --- r --- h r: LoWPAN Router
/ \ h: LoWPAN Host
h r --- h
|
/ \
r - r -- h
Figure 6: An example of a Route Over LoWPAN
When multiple 6LoWPANs 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 normal IPv6 mechanisms will be
employed. For Mesh Under, there is one IP hop from a node (a) to ER
of [A], no matter how many radio hops they are apart from each other.
This, of course, assumes the existence of a Mesh Under routing
protocol in order to reach the ER. For Route Over, the IPv6 address
of (b) is set as the destination of the packets, and the nodes
perform IP routing to the ER for these outgoing packets. In this
case, one radio hop is one IPv6 link. Additionally, a default route
to the ER could be inserted into the 6LoWPAN routing system.
Kim, et al. Expires September 26, 2009 [Page 10]
Internet-Draft 6LoWPAN Routing Requirements March 2009
4. Scenario Considerations and Parameters for 6LoWPAN Routing
IP-based LoWPAN 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 robust 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
[refs.bulusu]. Most related work focuses on optimizing routing for
specific application scenarios, which can be realized using several
models of communication, including the following ones [refs.cctc]:
o Flooding (in very small networks)
o Hierarchical routing
o Geographic routing
o 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 from application-specific communication and
describes general routing requirements 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.
* 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
Kim, et al. Expires September 26, 2009 [Page 11]
Internet-Draft 6LoWPAN Routing Requirements March 2009
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 frequently environmental characteristics
influencing radio propagation change.
* 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 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 can be randomly placed in an area (as can be
modeled by a 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 data rate, 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 developed, such as data-aware, 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 may require 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 of prime relevance. Secured
messages cause overhead and affect the power consumption of
LoWPAN routing protocols.
Kim, et al. Expires September 26, 2009 [Page 12]
Internet-Draft 6LoWPAN Routing Requirements March 2009
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.
* Power Consumption and Power Source:
The number of battery- and mains-powered nodes and their
positions in the topology created by them 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 due to 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 [refs.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
In the case of 915 MHz band:
Kim, et al. Expires September 26, 2009 [Page 13]
Internet-Draft 6LoWPAN Routing Requirements March 2009
+ 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
In the case of 868 MHz band:
+ 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:
The range of latencies, 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 next [refs.Latre]. For unreliable
mode, the actual latency is provided. For reliable mode, the
round-trip-time including transmission of a layer two
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]
For the 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.85 ms]
For the 868 MHz band:
Kim, et al. Expires September 26, 2009 [Page 14]
Internet-Draft 6LoWPAN Routing Requirements March 2009
+ 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 September 26, 2009 [Page 15]
Internet-Draft 6LoWPAN Routing Requirements March 2009
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:
o host nodes drawing their power from primary batteries or using
energy harvesting (both called "power-constrained nodes" in the
following)
o mains-powered host nodes (an example for what we call "power-
affluent nodes")
o power-affluent (but not necessarily mains-powered) high-
performance gateway(s)
o 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:
o 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 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 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 in the following.
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
Kim, et al. Expires September 26, 2009 [Page 16]
Internet-Draft 6LoWPAN Routing Requirements March 2009
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 (2 KB
minimum) and 10 KB, and program flash memory normally consists of
48 KB to 128 KB. (e.g., in the current market, MICAz has 128 KB
program flash, 4 KB EEPROM, 512 KB external flash ROM; TIP700CM
has 48 KB program flash, 10 KB RAM, 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 achieving 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 at maximum 20 hops
[I-D.ietf-roll-indus-routing-reqs]. 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 the efficient use of control packets (e.g., minimize
expensive IP multicast which causes link broadcast to the entire
LoWPAN) and by the efficient routing of data packets.
One way of battery lifetime optimization is by achieving a minimal
control message overhead. Compared to functions such as
computational operations or taking sensor samples, radio
communications is by far the dominant factor of power consumption
[refs.SmartDust]. 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
[refs.Shih].
The energy consumption of two example RF controllers for low-power
nodes is shown in [refs.Hill]. The TR1000 radio consumes 21 mW
when transmitting at 0.75 mW, and 15 mW on reception (with a
receiver sensitivity of -85 dBm). The CC1000 consumes 31.6 mW
when transmitting 0.75 mW, and 20 mW for receiving (with a
Kim, et al. Expires September 26, 2009 [Page 17]
Internet-Draft 6LoWPAN Routing Requirements March 2009
receiver sensitivity of -105 dBm). The power endurance under the
concept of an idealized power source is explained in [refs.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 [I-D.ietf-roll-protocols-survey].
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.
In order to save energy, routing overhead should be minimized to
prevent fragmentation of frames. 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 [RFC4944], the maximum size
of a 6LoWPAN frame, in order not to cause fragmentation, is 81
octets. This 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 on successful end-to-end packet delivery ratio (where
delivery may be bounded within certain latency) vary depending on
applications. In industrial applications, some non-critical
monitoring applications may tolerate successful delivery ratio of
less than 90% with hours of latency; in some other cases, a
delivery ratio of 99.9% is required
[I-D.ietf-roll-indus-routing-reqs]. In building automation
applications, application layer errors must be below 0.01%
[I-D.ietf-roll-building-routing-reqs].
Kim, et al. Expires September 26, 2009 [Page 18]
Internet-Draft 6LoWPAN Routing Requirements March 2009
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 the transmission has failed and
notifies the next higher layer of the failure. Note that
excessive retransmission 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 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 egress and ingress, while forced entry security
alerts must be routed to one or more fixed or mobile user devices
within 5 s [I-D.ietf-roll-building-routing-reqs]. 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
[I-D.ietf-roll-indus-routing-reqs]. 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 to minutes
[I-D.ietf-roll-urban-routing-reqs].
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 in 64 bit
MAC address unreliable mode and 2.20 ms to 6.56 ms in 64 bit
address reliable mode. The range of latencies of 868 MHz band is
from 11.7 ms to 63.7 ms, depending on the address type and
reliable/unreliable mode used. Note that the latencies may be
larger than that depending on channel load, MAC layer settings
procedure-->, and reliable/unreliable mode choice. Note that
Kim, et al. Expires September 26, 2009 [Page 19]
Internet-Draft 6LoWPAN Routing Requirements March 2009
other MAC approaches than the legacy 802.15.4 may be used (e.g.
TDMA). Duty cycling may further affect latency (see [R08]).
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 (e.g. due to RSSI variation, interference variation, noise and
asynchrony) or in the 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 and
receive queues and 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 and must converge within
0.5 seconds if only the sender has moved
[I-D.ietf-roll-home-routing-reqs]. 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 of node failure.
[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 one. 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 Network Characteristics
6LoWPANs can be deployed in different sizes and topologies, adhere to
various models of mobility, be exposed to various levels of
interference, etc. In any case, LoWPANs must maintain low energy
consumption. The requirements described in the following subsection
are derived from the network attributes of 6LoWPANs.
[R08] 6LoWPAN routing protocols SHOULD be reliable despite
Kim, et al. Expires September 26, 2009 [Page 20]
Internet-Draft 6LoWPAN Routing Requirements March 2009
unresponsive nodes due to periodic hibernation.
Many nodes in LoWPAN 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 from the lower IEEE 802.15.4 layer may be
considered to enhance the power-awareness of 6LoWPAN routing
protocols.
CC1000-based nodes must operate at a duty cycle of approximately
2% to survive for one year from idealized AA battery power source
[refs.Hill]. For home automation purposes, it is suggested that
the devices have to maximize the sleep phase with a duty cycle
lower than 1% [I-D.ietf-roll-home-routing-reqs], while 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 [I-D.ietf-roll-building-routing-reqs].
Dependent on the application in use, packet rates may range from
one per second to one per day or beyond. Routing protocols may
take advantage of knowledge about the packet transmission rate and
utilize this information in calculating routing paths.
[R09] The metric used by 6LoWPAN routing protocols MAY utilize a
combination of the inputs provided by the lower layers and other
measures to optimize path selection considering energy balance and
link qualities.
In homes, buildings, or infrastructure, some nodes will be
installed with mains power. Such power-installed nodes MUST be
considered as relay points for 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 is a Link Quality Indication (LQI), 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) may depend on applications and
requirements.
The numbers in Figure 7 represent the Link Delivery Ratio (LDR) of
each pair of nodes. There are studies that show a piecewise
linear dependence between LQI and LDR [refs.Chen].
Kim, et al. Expires September 26, 2009 [Page 21]
Internet-Draft 6LoWPAN Routing Requirements March 2009
0.6
A-------C
\ /
0.9 \ / 0.9
\ /
B
Figure 7: An example network
In this simple example, there are two options in routing from node
A to node C, with the following features:
A. Path AC:
+ (1/0.6) = 1.67 avg. transmissions needed for each packet
+ one-hop path
+ good in energy consumption and end-to-end latency of data
packets, bad in delivery ratio (0.6)
+ bad in probability of route reconfigurations
B. Path ABC:
+ 2*(1/0.81) = 2.47 avg. transmissions needed for each packet
+ two-hop path
+ bad in energy consumption and end-to-end latency of data
packets, 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 based on a hop count metric).
However, if the delivery ratio in that case is not sufficient, the
best path is ABC (it would be chosen by an LQI based metric).
Combinations of both metrics can be used.
The metric also affects the probability of route reconfiguration.
Route reconfiguration, which may be triggered by packet losses,
may require transmission of routing protocol messages. It is
possible to use a metric aimed at selecting the path with low
route reconfiguration rate by using LQI as an input to the metric.
Such a path has good properties, including stability and low
control message overhead.
[R10] 6LoWPAN routing protocols SHOULD be designed to achieve both
scalability from a few nodes to maybe millions of nodes and
Kim, et al. Expires September 26, 2009 [Page 22]
Internet-Draft 6LoWPAN Routing Requirements March 2009
minimality in terms of used system resources.
A LoWPAN may consist of just a couple of nodes (for instance in a
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
[I-D.ietf-roll-home-routing-reqs], 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
[I-D.ietf-roll-urban-routing-reqs]. 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.
[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 [refs.Lee]. One
important consideration here may be to avoid premature energy
depletion, even in case 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.
Building monitoring applications, for instance, require that the
mobile devices SHOULD be capable of leaving (handing-off) from an
old network joining onto a new network within 15 seconds
[I-D.ietf-roll-building-routing-reqs]. 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, for moves within a network, a
convergence time below 0.5 seconds is commonly required
[I-D.ietf-roll-home-routing-reqs]. In industrial environments,
where mobile equipment such as cranes move around, the support of
vehicular speeds of up to 35 km/h are required to be supported by
the routing protocol [I-D.ietf-roll-indus-routing-reqs].
Currently, 6LoWPANs are not normally being used for such a fast
Kim, et al. Expires September 26, 2009 [Page 23]
Internet-Draft 6LoWPAN Routing Requirements March 2009
mobility, but dynamic association and disassociation 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 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 re-
appear in another place. Movement pattern tracking 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 stub networks, more powerful gateway nodes need to be
configured to handle moving LoWPANs.
* Nodes permanently joining or leaving the LoWPAN:
In order to ease routing table updates, reduce their size, and
minimize error control messages, nodes leaving the network may
announce their disassociation to the closest edge router or if
any, to a specific node which 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
working group 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
The routing requirement described in this subsection allows secure
transmission of routing messages. Solutions may take into account
the specific features of IEEE 802.15.4 MAC layers.
Kim, et al. Expires September 26, 2009 [Page 24]
Internet-Draft 6LoWPAN Routing Requirements March 2009
[R14] 6LoWPAN protocols SHOULD support secure delivery of control
messages. A minimal security level can be achieved by utilizing the
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 [RFC3756]. 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 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, either for the routing protocol
alone or in conjunction with the security used for the data. 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 does not specify protection for acknowledgement
frames. Since the sequence numbers of data frames are sent in the
clear, an adversary can forge an acknowledgement for each data
frame. This weakness can be combined with targeted jamming to
prevent delivery of selected packets. In consequence, IEEE
802.15.4 acknowledgements cannot be relied upon. In applications
that require high security, the routing protocol must not exploit
feedback from acknowledgements (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/routing mechanisms must be supported. The routing
requirements described in this subsection allow optimization and
correct operation of routing solutions taking into account the
specific features of the mesh-under configuration.
[R15] When a routing protocol operates in 6LoWPAN's adaptation layer,
routing tables and neighbor lists MUST support 16-bit short and 64-
bit extended 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"
Kim, et al. Expires September 26, 2009 [Page 25]
Internet-Draft 6LoWPAN Routing Requirements March 2009
messages. Instead, link-layer mechanisms (such as acknowledgments)
MAY be utilized to keep track of active neighbors.
Reception of an acknowledgement after a frame transmission may
render unnecessary the transmission of explicit Hello messages,
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] In case there are one or more nodes allocated for the specific
role of local management, such a management node MAY take the role of
keeping track of nodes within the area of the LoWPAN it takes
responsibility for.
[R18] If the routing protocol functionality includes enabling IP
multicast, then it may want to employ structure in the network for
efficient distribution [I-D.ietf-manet-smf], such as Connected
Dominating Sets (CDS), Multi-Point Relays (MPR), or relay points
sending point-to-multipoint messages in unicast messages instead of
using link-layer multicast (broadcast).
Kim, et al. Expires September 26, 2009 [Page 26]
Internet-Draft 6LoWPAN Routing Requirements March 2009
6. Security Considerations
Security issues are described in Section 4.4. Security
considerations of RFC 4919 [RFC4919] and RFC 4944 [RFC4944] apply as
well. More security considerations will result from the 6LoWPAN
security analysis work.
Kim, et al. Expires September 26, 2009 [Page 27]
Internet-Draft 6LoWPAN Routing Requirements March 2009
7. Acknowledgements
The authors thank Myung-Ki Shin for giving the idea of writing this
draft. The authors also thank S. Chakrabarti who gave valuable
comments for mesh-under requirements and A. Petrescu for significant
review.
Kim, et al. Expires September 26, 2009 [Page 28]
Internet-Draft 6LoWPAN Routing Requirements March 2009
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
[RFC3819] Karn, P., 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.
[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.
[refs.IEEE802.15.4]
IEEE Computer Society, "IEEE Std. 802.15.4-2006 (as
amended)", 2007.
8.2. Informative References
[I-D.ietf-6lowpan-hc]
Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-04
(work in progress), December 2008.
[I-D.ietf-6lowpan-nd]
Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E.
Nordmark, "Neighbor Discovery for 6LoWPAN",
draft-ietf-6lowpan-nd-02 (work in progress), March 2009.
[I-D.ietf-manet-smf]
Macker, J. and S. Team, "Simplified Multicast Forwarding
for MANET", draft-ietf-manet-smf-08 (work in progress),
November 2008.
[I-D.ietf-roll-building-routing-reqs]
Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
Kim, et al. Expires September 26, 2009 [Page 29]
Internet-Draft 6LoWPAN Routing Requirements March 2009
"Building Automation Routing Requirements in Low Power and
Lossy Networks", draft-ietf-roll-building-routing-reqs-05
(work in progress), February 2009.
[I-D.ietf-roll-home-routing-reqs]
Porcu, G., "Home Automation Routing Requirements in Low
Power and Lossy Networks",
draft-ietf-roll-home-routing-reqs-06 (work in progress),
November 2008.
[I-D.ietf-roll-indus-routing-reqs]
Networks, D., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low Power and Lossy
Networks", draft-ietf-roll-indus-routing-reqs-04 (work in
progress), January 2009.
[I-D.ietf-roll-protocols-survey]
Tavakoli, A., Dawson-Haggerty, S., and P. Levis, "Overview
of Existing Routing Protocols for Low Power and Lossy
Networks", draft-ietf-roll-protocols-survey-06 (work in
progress), February 2009.
[I-D.ietf-roll-urban-routing-reqs]
Dohler, M., Watteyne, T., Winter, T., Barthel, D.,
Jacquenet, C., Madhusudan, G., and G. Chegaray, "Urban
WSNs Routing Requirements in Low Power and Lossy
Networks", draft-ietf-roll-urban-routing-reqs-04 (work in
progress), February 2009.
[refs.Chen]
Chen, B., Muniswamy-Reddy, K., and M. Welsh, "Ad-Hoc
Multicast Routing on Resource-Limited Sensor Nodes", 2006.
[refs.Hill]
Hill, J., "System Architecture for Wireless Sensor
Networks".
[refs.Latre]
Latre, M., De Mil, P., Moerman, I., Dhoedt, B., and P.
Demeester, "Throughput and Delay Analysis of Unslotted
IEEE 802.15.4", May 2006.
[refs.Lee]
Lee, S., Belding-Royer, E., and C. Perkins, "Scalability
Study of the Ad Hoc On-Demand Distance-Vector Routing
Protocol", March 2003.
[refs.Shih]
Kim, et al. Expires September 26, 2009 [Page 30]
Internet-Draft 6LoWPAN Routing Requirements March 2009
Shih, E., "Physical Layer Driven Protocols and Algorithm
Design for Energy-Efficient Wireless Sensor Networks",
July 2001.
[refs.SmartDust]
Pister, K. and B. Boser, "Smart Dust: Wireless Networks of
Millimeter-Scale Sensor Nodes".
[refs.bulusu]
Bulusu, N. and S. Jha, "Wireless Sensor Networks",
July 2005.
[refs.cctc]
Lu, J., Valois, F., Dohler, M., and D. Barthel,
"Quantifying Organization by Means of Entropy", 2008.
Kim, et al. Expires September 26, 2009 [Page 31]
Internet-Draft 6LoWPAN Routing Requirements March 2009
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 September 26, 2009 [Page 32]
