6LoWPAN Working Group D. Kaspar
Internet-Draft E. Kim
Expires: August 29, 2007 M. Shin
H. Kim
ETRI / PEC
February 25, 2007
Design Goals and Requirements for 6LoWPAN Mesh Routing
draft-dokaspar-6lowpan-routreq-00
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 August 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Kaspar, et al. Expires August 29, 2007 [Page 1]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
Abstract
This document defines the problem statement, design goals, and
requirements for mesh routing in low-power wireless personal area
networks (LoWPANs).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scenario Considerations . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3. LoWPAN Mesh Routing Design Goals . . . . . . . . . . . . . . . 6
3.1. Reuse of Existing MANET Protocols . . . . . . . . . . . . 6
3.2. Adaptation Layer Routing . . . . . . . . . . . . . . . . . 6
3.3. Minimizing Overhead and Complexity . . . . . . . . . . . . 6
3.4. Power Conservation . . . . . . . . . . . . . . . . . . . . 6
3.5. Reliability and Robustness . . . . . . . . . . . . . . . . 7
3.6. Connectivity . . . . . . . . . . . . . . . . . . . . . . . 7
3.7. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 7
3.8. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 8
3.9. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.10. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8
3.11. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 8
3.12. Security . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.13. Implementation Considerations . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Analysis of Existing Mesh Routing Candidates . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Kaspar, et al. Expires August 29, 2007 [Page 2]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
1. Introduction
Low-power wireless personal area networks (LoWPANs) are formed by
devices complying to the IEEE 802.15.4 standard [1]. 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 [2].
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 among each other and accomplish more
advanced functions, such as multi-hop routing.
Neither the IEEE 802.15.4 standard nor the "IPv6 over IEEE 802.15.4"
[3] specification provide any information as to how mesh topologies
could be obtained and maintained. However, routing in mesh networks
has been the subject of much research in the IETF. A number of
experimental protocols have been developed in the Mobile Ad-hoc
Networks (MANET) working group, such as AODV [4], OLSR [5], or DYMO
[6].
This document defines the problem statement of mesh routing in LoWPAN
environments and outlines the relevant design goals and requirements.
1.1. Scenario Considerations
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.
In general, the requirements on a routing protocol are depending on
the hardware parameters of the participating nodes and the properties
of the network;
1. Network properties:
* Device number and density
* Network scale and topology
* Mobility issues
Kaspar, et al. Expires August 29, 2007 [Page 3]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
* ... etc.
2. Node parameters:
* Physical dimensions
* Hardware Cost
* Processing speed and memory size
* Power consumption and source
* Transmission range, rate and bandwidth
* ... etc.
Network properties may vary arbitrarily for application scenarios in
both LoWPAN or MANET contexts. For instance, even though LoWPANs are
often regarded as more dense and consisting of more nodes than MANET
networks, it might as well occur that a MANET consists of more
devices than a LoWPAN.
On the other hand, the node parameters themselves define whether a
certain node is a LoWPAN device, a MANET device or neither of both.
The classification boundaries are only vaguely defined. However, it
is clear that pure LoWPAN devices enable services that MANET devices
can not provide because of their nature of being more expensive,
occupying greater physical space or requiring too much battery power.
We might think that the characteristics of LoWPANs are device
features only, but they enable a whole new segment of services that
MANET devices are not always able to satisfy. And for implementing
these specialized LoWPAN services, the reuse of routing protocols
tailored for MANET purposes might not suffice.
Kaspar, et al. Expires August 29, 2007 [Page 4]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
2. Problem Statement
If possible, the easiest way to achieve LoWPAN mesh routing is by
reusing existing MANET protocols without making any modifications.
However, the modification or simplification of existing MANET routing
protocols may be required for mesh routing to be feasible in a LoWPAN
domain, because other requirements apply to LoWPAN devices. Unlike
MANET devices, LoWPAN nodes are characterized by much lower power
supplies, smaller memory sizes, and lower processing power, which
creates new challenges on obtaining robust and reliable mesh routing
within LoWPANs.
Therefore, the modification and simplification of existing mesh
routing protocols have to be done in such a way as to ensure
efficient and robust packet delivery within LoWPAN networks. This
document also outlines the fundamental design goals, which mesh
routing will intend to accomplish for LoWPANs.
There exists a trade-off relationship between routing effectiveness
and the requirements posed upon the devices participating in a mesh
network. The challenge is to create a balance between protocol
simplicity and routing performance. But stripping down existing
protocols to power-aware, low-overhead protocols decreases the
efficacy and functionality of their sophisticated routing techniques,
or possibly even endangers the goals they were designed for.
Kaspar, et al. Expires August 29, 2007 [Page 5]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
3. LoWPAN Mesh Routing Design Goals
This section outlines the fundamental design goals, which mesh
routing implementations will intend to accomplish for LoWPANs.
3.1. Reuse of Existing MANET Protocols
If the application of MANET routing protocols is feasible in LoWPAN
environments, existing specifications should be simplified and
modified to the smallest extent possible, in order to fit their low-
power requirements.
3.2. Adaptation Layer Routing
Because network layer routing imposes too much overhead for LoWPANs
and link layer techniques are out of scope of IETF, LoWPAN mesh
routing should be performed within the adaptation layer defined in
[3].
3.3. Minimizing Overhead and Complexity
Because energy-efficient routing is important in LoWPANs, control
messages must be trimmed from overhead to the highest degree
possible. Routing overhead must be minimized in order to prevent
fragmentation of frames on the physical layer, reducing the energy
required for transmission and preventing the need for packet
reassembly.
Routing protocols should be designed to minimize the required number
of control messages, memory size and computational complexity.
Possible techniques might include the omission of routing tables or
local repair procedures, but the actual details are left to the
protocol designers.
3.4. Power Conservation
Saving energy is crucially important to LoWPAN devices that are not
mains-powered but have to rely on a depleting source, such as a
battery. The lifetime of a LoWPAN node depends on the energy it can
store and harvest.
Compared to functions such as performing memory operations or taking
sensor samples, radio communications is by far the dominant factor of
power consumption [7]. Therefore, optimization of mesh routing
protocols in terms of achieving a minimal number of control messages
is essential for the longevity of battery-powered nodes.
Many nodes in LoWPAN environments might periodically hibernate (i.e.
Kaspar, et al. Expires August 29, 2007 [Page 6]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
disable their transceiver activity) to save energy. Therefore, mesh
routing protocols must ensure robust packet delivery despite of nodes
frequently shutting off their radio transmission interface.
In order to find energy-optimal routing paths, LoWPAN mesh routing
protocols should minimize power consumption by utilizing the link
quality indication (LQI) provided by the MAC layer.
3.5. Reliability and Robustness
An important characteristic of LoWPAN 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, noise, and asynchrony.
It is predicted that LoWPANs will be comprised of significantly
higher numbers of devices than counted in current networks, causing
user interaction and maintenance to become impractical and therefore
requiring robustness and self-healing capabilities in their
fundamental network structure.
Mesh routing must be aware of unreliable nodes. One method to
estimate the reliability of a node is to use the link quality
indication (LQI) provided by the MAC layer.
Route repair and route error messages should be avoided for
minimizing the overall number of control messages and the required
energy for sending them.
Loop-freedom is a desirable property of any routing protocol.
3.6. Connectivity
IP routing between LoWPAN domains and higher layer networks must be
provided bidirectionally. A LoWPAN mesh routing protocol must allow
for gateways to forward packets out of the local domain and it must
be possible to query a LoWPAN device from outside of the local
domain.
Strategies must be considered to avoid battery depletion of nodes by
too many queries from higher level networks. End-to-end
communication is not a design goal of LoWPAN.
3.7. Neighbor Discovery
Neighbor discovery is a major precondition to allow routing in a
network. Especially in a low-power environment, where nodes might be
in periodic sleeping states, it is difficult to define whether a node
Kaspar, et al. Expires August 29, 2007 [Page 7]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
is a neighbor of another or not. In addition to that, LoWPAN devices
must be very economical in terms of power consumption and should
avoid sending "Hello" messages. Instead, link layer mechanisms (such
as acknowledgments or beacon responses) could be utilized to keep
track of active neighbors.
3.8. Bootstrapping
Bootstrapping a LoWPAN network may be a prerequisite for mesh
routing.
3.9. Mobility
Routing must be allowed both for fixed and dynamically adaptive
topologies. Mesh networks are likely to consist of nodes with a
certain degree of mobility. Due to the low performance
characteristics of LoWPAN devices, fast mobility detection will be a
huge challenge. Nodes might even change their location while being
in state of hibernation. Routing must be robust and remain energy-
efficient in all such cases.
Also, as recently seen in discussions related to MANEMO (Network
mobility for MANET), a similar point was stated regarding network
mobility in LoWPAN environments.
3.10. Scalability
Low-power WPAN topologies are foreseen to comprise of significantly
more devices than current networks. Therefore, the design of mesh
routing protocols must consider the fact that packets are to be
reliably delivered over a much higher number of hops, too.
3.11. Addressing
Both addressing modes provided by the IEEE 802.15.4 standard, 16 bit
short addresses and 64 bit extended addresses, must be considered by
LoWPAN mesh routing protocols.
It is assumed that nodes participating in LoWPAN mesh routing are
assigned a single address/identifier and do not support multiple
interfaces.
3.12. Security
Security threats within LoWPANs may be different from existing threat
models in MANET environments. Neighbor Discovery in IEEE 802.15.4
links may be susceptible to threats as listed in RFC3756 [8].
Bootstrapping may also impose additional threats. Nevertheless,
Kaspar, et al. Expires August 29, 2007 [Page 8]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
security should not cause significant transmission overhead.
3.13. Implementation Considerations
Even though implementation details are out of IETF scope, due to the
hardware restrictions of LoWPAN devices, code length should be
considered to fit within their small memory size.
Kaspar, et al. Expires August 29, 2007 [Page 9]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
4. Requirements
This section lists the requirements on mesh routing protocols for
LoWPANs;
R01: Protocol control messages must not create fragmentation of
PHY layer frames.
R02: Shortest path calculation must be based on minimal energy
usage.
R03: Connectivity to higher layer networks must be provided by
seamless IP routing.
R04: Routing must be aware of sleeping nodes.
R05: The solution must be simple and robust, despite of unreliable
or sleeping nodes.
R06: The solution must allow for dynamically adaptive topologies.
It may support local mobility and global mobility.
R07: The solution should support self-organization on deployment.
R08: Neighbor discovery should be based on link layer mechanisms.
R09: The solution should support high scalability.
R10: Protocol control messages must be secured (TBD).
Kaspar, et al. Expires August 29, 2007 [Page 10]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
5. Analysis of Existing Mesh Routing Candidates
This section is still to be defined.
An objective analysis on existing MANET routing protocols should be
carried out to evaluate their suitability within LoWPANs.
Kaspar, et al. Expires August 29, 2007 [Page 11]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
6. Security Considerations
Security issues are handled as described in Section 3.12
Kaspar, et al. Expires August 29, 2007 [Page 12]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
7. References
[1] IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003.
[2] Kushalnagar, N., Montenegro, G., and C. Schumacher, "6LoWPAN:
Overview, Assumptions, Problem Statement and Goals,
draft-ietf-6lowpan-problem-07 (work in progress)",
February 2007.
[3] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks,
draft-ietf-6lowpan-format-10 (work in progress)", October 2005.
[4] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand
Distance Vector (AODV) Routing", RFC 3561, July 2003.
[5] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol (OLSR)", RFC 3626, October 2003.
[6] Chakeres, I., "Dynamic MANET On-demand (DYMO) Routing,
draft-ietf-manet-dymo-06 (work in progress)", June 2005.
[7] Pfister, K. and B. Boser, "Smart Dust: Wireless Networks of
Millimeter-Scale Sensor Nodes".
[8] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[9] Bradner, S., "Intellectual Property Rights in IETF Technology",
BCP 79, RFC 3979, March 2005.
Kaspar, et al. Expires August 29, 2007 [Page 13]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
Authors' Addresses
Dominik Kaspar
ETRI / PEC
161 Gajeong-dong
Yuseong-gu
Daejeon 305-700
Korea
Phone: +82-42-860-1072
Email: dominik@etri.re.kr
Eunsook Kim
ETRI / PEC
161 Gajeong-dong
Yuseong-gu
Daejeon 305-700
Korea
Phone: +82-42-860-6124
Email: eunah@etri.re.kr
Myungki Shin
ETRI / PEC
161 Gajeong-dong
Yuseong-gu
Daejeon 305-700
Korea
Phone: +82-42-860-4847
Email: mkshin@etri.re.kr
Hyoungjun Kim
ETRI / PEC
161 Gajeong-dong
Yuseong-gu
Daejeon 305-700
Korea
Phone: +82-42-860-6576
Email: hjk@etri.re.kr
Kaspar, et al. Expires August 29, 2007 [Page 14]
Internet-Draft 6LoWPAN Mesh Routing Requirements February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kaspar, et al. Expires August 29, 2007 [Page 15]