[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                     N. Kushalnagar
Internet-Draft                                                Intel Corp
Expires: August 15, 2005                                   G. Montenegro
                                                  Sun Microsystems, Inc.
                                                       February 14, 2005

      6LoWPAN: Overview, Assumptions, Problem Statement and Goals

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 15, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This document describes the assumptions, problem statement and goals
   for transmitting IP over IEEE 802.15.4 networks.  The set of goals
   enumerated in this document form an initial set only.  Additional
   goals may be found necessary over time and may be added to this

Kushalnagar & Montenegro    Expires August 15, 2005             [Page 1]

Internet-Draft         6lowpan Problems and Goals          February 2005

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Requirements notation  . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Problems . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1   IP Connectivity  . . . . . . . . . . . . . . . . . . . . .  5
     4.2   Topologies . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.3   Limited Packet Size  . . . . . . . . . . . . . . . . . . .  6
     4.4   Limited configuration and management . . . . . . . . . . .  6
     4.5   Service discovery  . . . . . . . . . . . . . . . . . . . .  7
     4.6   Security . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   9.1   Normative References . . . . . . . . . . . . . . . . . . . .  9
   9.2   Informative References . . . . . . . . . . . . . . . . . . . 10
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
       Intellectual Property and Copyright Statements . . . . . . . . 11

Kushalnagar & Montenegro    Expires August 15, 2005             [Page 2]

Internet-Draft         6lowpan Problems and Goals          February 2005

1.  Introduction

   Low-power wireless personal area networks (LoWPAN) comprise of
   devices that conform to the IEEE 802.15.4-2003 standard by the IEEE
   [ieee802.15.4].  The IEEE 802.15.4 devices are characterized by short
   range, low bit rate, low power and low cost.

   This document gives an overview of LoWPANs and describes how IP and
   IPv6 networking benefits LoWPANs.  It describes the requirements of
   LoWPANs with regards to IP layer and above.  It spells out the
   underlying assumptions of IP for LoWPANs.  Finally, it describes
   problems associated with enabling IP communication between LoWPAN
   devices, and defines goals to address these in a prioritized manner.
   Admittedly, not all items on this list are necessarily appropriate
   tasks for the IETF.  Nevertheless, they are documented here to give a
   general overview of the larger problem.  This is useful both to
   structure work within the IETF as well as to understand better how to
   coordinate with external organizations.

1.1  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2.  Overview

   A LoWPAN is a simple low cost communication network that allows
   wireless connectivity in applications with limited power and relaxed
   throughput requirements.  LoWPAN typically comprises of devices that
   work together to connect the physical environment to real world
   applications, e.g., wireless sensors.  It may also comprise point to
   point wireless controls.  LoWPAN devices conform to the IEEE
   802.15.4-2003 standard by the IEEE [ieee802.15.4].

   Some of the characteristics of LoWPANs are:

   1.  Small packet size.  Given that the maximum physical layer packet
       is 127 bytes, the resulting maximum frame size at the media
       access control layer is 102 octets.  Link-layer security imposes
       further overhead, which in the maximum case (21 octets of
       overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32
       and AES-CCM-64, respectively) leaves 81 octets for data packets.

   2.  Support for both 16-bit short or IEEE 64-bit extended media
       access control addresses.

Kushalnagar & Montenegro    Expires August 15, 2005             [Page 3]

Internet-Draft         6lowpan Problems and Goals          February 2005

   3.  Low bandwidth.  Data rates of 250 kbps, 40 kbps and 20 kbps for
       each of the currently defined physical layers (2.4 GHz, 915 MHz
       and 868 MHz, respectively).

   4.  Topologies include star and mesh operation.

   5.  Low power, typically battery operated.

   6.  Relatively low cost, typically associated with sensors, switches,
       etc.  These drive some of the other characteristics such as low
       processing, low memory, etc.  Numerical values for "low" have not
       been explicitly mentioned here as historically the costs tend to
       change over time.

   7.  Large number of devices expected to be deployed during the
       life-time of the technology.  This number is expected to dwarf
       the number of deployed personal computers, for example.

   8.  Location of the devices are typically not predefined, thus these
       devices are deployed in an adhoc fashion.  Furthermore, sometimes
       the location of these devices may not be easily accessible.

   9.  Devices within LoWPANs have a higher possibility of being
       unreliable due to variety of reasons: uncertain radio
       connectivity, battery drain, device lockups, physical tampering,

   The following sections take into account these characteristics in
   describing the  assumptions, problems statement and goals for

3.  Assumptions

   Given the small packet size of LoWPANs, this document presumes
   applications typically send small amounts of data.  However, the
   protocols themselves do not restrict bulk data transfers.

   LoWPAN networks described in this document is based on IEEE
   802.15.4-2003.  It is possible that the specification may undergo
   changes in the future and may change some of the above mentioned

   Some of these assumptions are based on the limited capabilities of
   devices within LoWPANs.  As devices become more powerful, and consume
   less power, additional functionalities may be supported within
   LoWPAN, somewhat relaxing some of the requirements mentioned above.

   Nevertheless, not all devices in a LoWPAN network are expected to be

Kushalnagar & Montenegro    Expires August 15, 2005             [Page 4]

Internet-Draft         6lowpan Problems and Goals          February 2005

   extremely limited.  This is true of so-called "Reduced Function
   Devices" (RFDs), but not necessarily of "Full Function Devices"
   (FFDs).  These will also be present albeit in much smaller numbers,
   and will typically have more resources and be mains powered.
   Accordingly, FFDs will aid RFDs by providing functions such as
   network coordination, packet forwarding, interfacing with other
   (non-LoWPAN) networks, etc.

4.  Problems

   Based on the characteristics defined in the overview section, the
   following sections elaborate on the main problems with IP for LoWPANs
   Note that a common underlying goal is to reduce packet overhead,
   bandwidth consumption, and processing requirements.

4.1  IP Connectivity

   The requirement for having IP connectivity within LoWPAN is driven by
   the following:

   1.  The pervasive nature of IP networks allows use of existing
   2.  IP based technologies already exist, are well known and proven to
       be working.
   3.  An admittedly  non-technical but important consideration is that
       intellectual property conditions for IP networking technology are
       either more favorable or at least better understood than
       proprietary and newer solutions.

   Furthermore, the requirement for having IPv6 connectivity within
   LoWPAN is driven by the following:

   1.  Such devices make network autoconfiguration and statelessness
       highly desirable.  And for this, IPv6 has ready solutions.
   2.  The large number of devices poses the need for a large address
       space, well met by IPv6.
   3.  Given the limited packet size of LoWPANs, the IPv6 address format
       allows subsuming of IEEE 802.15.4 addresses if so desired.

   However, given the limited packet size, headers for IPv6 and above
   layers must be compressed whenever possible.

4.2  Topologies

   LoWPANs must support various topologies including mesh and star.

   Mesh topologies imply multi-hop routing.  to a desired destination.

Kushalnagar & Montenegro    Expires August 15, 2005             [Page 5]

Internet-Draft         6lowpan Problems and Goals          February 2005

   In this case, intermediate devices act as packet forwarders at the
   link layer (akin to routers at the network layer).  Typically these
   are "full function devices" that have more capabilities in terms of
   power, computation, etc.  The requirements that apply on the chosen
   routing protocol are:

   1.  Given the minimal packet size of LoWPANs, the routing protocol
       must impose low (or no) overhead on data packets, hopefully
       independently of the number of hops.
   2.  The routing protocols should have low routing overhead (less
       chatty) balanced with topology changes and power conservation.
   3.  The computation and memory requirements in the routing protocol
       should be minimal to satisfy low cost and low power
       characteristics.  Thus storage and maintaining of large routing
       tables may be detrimental.

   As with mesh topologies, star topologies include provisioning a
   subset of devices with packet forwarding functionality.  If these
   devices use the same IEEE 802.15.4 radio, then the requirement
   specified in the mesh topology must exist.  If these devices use
   different kinds of network interfaces such as ethernet, IEEE 802.11,
   etc., the goal is for seamless integration with networks built over
   those technologies.  This, or course, is a primary motivation to use
   IP to begin with.

4.3  Limited Packet Size

   Applications within LoWPANs are expected to originate small packets.
   Adding all layers for IP connectivity should still allow transmission
   in one frame without incurring excessive fragmentation and
   reassembly.  Furthermore, protocols must be designed or chosen so
   that the individual "control/protocol packets" fit within a single
   802.15.4 frame.

4.4  Limited configuration and management

   As alluded to above, LoWPAN devices are expected to be deployed in
   exceedingly large numbers.  Additionally, LoWPAN devices are expected
   to have limited display and input capabilities.  Furthermore, the
   location of some of these devices may be hard to access.  As such,
   protocols designed for LoWPANs should have minimal configuration,
   preferably work "out of the box", provide easy bootstrapping, and
   should be able to self heal given the inherent unreliable
   characteristic of these devices.  The network management should have
   less overhead yet be powerful to control dense deployment of devices.

Kushalnagar & Montenegro    Expires August 15, 2005             [Page 6]

Internet-Draft         6lowpan Problems and Goals          February 2005

4.5  Service discovery

   LoWPAN require simple service discovery network protocols to
   discover, control and maintain services provided by devices.  In some
   cases, especially in dense deployments, abstraction of several nodes
   to provide a service may be beneficial.  In order to enable such
   features, new protocols may have to be designed.

4.6  Security

   Although IEEE 802.15.4 provides AES link layer security, a complete
   end-to-end security is needed.

5.  Goals

   Goals mentioned here may point at relevant work that can be done
   within the IETF (e.g., specification required to transmit IP, profile
   of best practices for transmitting IP packets, and associated upper
   level protocols, etc).  It may also point at work to be done in other
   standards bodies that exist or may exist in the future (e.g.,
   desirable changes or profiles relevant to IEEE 802.15.4, W3C, etc).
   When the goals fall under the IETF's purview, they serve to point out
   what those efforts should strive to accomplish.  Regardless of
   whether they are pursued within one (or more) new (or existing)
   working groups.  When the goals do not fall under the purview of the
   IETF, documenting them here serves as input to those other
   organizations [liaison].

   The following are the goals according to priority for LoWPAN:

   1.  As mentioned in the overview, the protocol data units may be as
       small 81 bytes.  This is obviously far below the minimum IPv6
       packet size of 1280 octets, and in keeping with section 5 of the
       IPv6 specification [RFC2460], a fragmentation and reassembly
       adaptation layer must be provided at the layer below IP.

   2.  Given that in the worst case the maximum size available for
       transmitting IP packets over IEEE 802.15.4 frame is 81 octets,
       and that the IPv6 header is 40 octets long, (without optional
       headers), this leaves only 41 octets for upper-layer protocols,
       like UDP and TCP.  UDP uses 8 octets in the header and TCP uses
       20 octets.  This leaves 33 octets for data over UDP and 21 octets
       for data over TCP.  Additionally, as pointed above, there is also
       a need for a fragmentation and reassembly layer, which will use
       even more octets leaving very few octets for data.  Thus if one
       were to use the protocols as is, it would lead to excessive
       fragmentation and reassembly even when data packets are just 10s
       of octets long.  This points at the need for header compression

Kushalnagar & Montenegro    Expires August 15, 2005             [Page 7]

Internet-Draft         6lowpan Problems and Goals          February 2005

       As there is much published and in-progress standardization work
       on header compression, this goal needs to investigate using
       existing header compression techniques and if necessary specify
       new ones.

   3.  [I-D.ietf-ipv6-rfc2462bis] specify methods for creating IPv6
       stateless address autoconfiguration.  Stateless auto
       configuration has an advantage over stateful by having less
       configuration overhead on the hosts suitable for LoWPANs.  The
       goal should specify a method to generate an "interface
       identifier" from the EUI-64 [EUI64] assigned to the IEEE 802.15.4

   4.  A routing protocol to support a multi-hop mesh network is
       necessary.  There is much published work on adhoc multi hop
       routing for devices.  Some examples include [RFC3561], [RFC3626],
       [RFC3684], all experimental.  Also, these protocols are designed
       to use IP based addresses that have large overheads.  For
       example, the AODV [RFC3561] routing protocol uses 48 octets for a
       route request based on IPv6 addressing.  Given the packet size
       constraints, transmitting this packet without fragmentation and
       reassembly may be difficult.  Thus care should be taken when
       using existing protocols or designing new protocols for routing
       so that the routing packets fit within a single IEEE 802.15.4

   5.  One of the points of transmitting IPv6 packets, is to reuse
       existing protocols as much as possible.  Network management
       functionality is critical for LoWPANs.  [RFC3411] specifies
       SNMPv3 protocol operations.  SNMP functionality may be translated
       "as is" to LoWPANs.  However, further investigation is required.
       SNMPv3 may not be the best protocol for this task.  Or it may be
       only after adapting it appropriately.

   6.  It may be the case that transmitting IP over IEEE 802.15.4 would
       become more beneficial if implemented in a "certain" way.
       Accordingly, implementation considerations are to be documented.

   7.  As header compression becomes more prevalent, overall performance
       will depend even more on efficiency of application protocols.
       Heavyweight protocols based on XML such as SOAP [SOAP], may not
       be suitable for LoWPANs.  As such, more compact encodings (and
       perhaps protocols) may become necessary.  The goal here is to
       specify or suggest modifications to existing protocols so that it
       is suitable for LoWPANs.  Furthermore, application level
       interoperability specifications may also become necessary in the
       future and may thus be specified.

Kushalnagar & Montenegro    Expires August 15, 2005             [Page 8]

Internet-Draft         6lowpan Problems and Goals          February 2005

   8.  Security threats at different layers must be clearly understood
       and documented.  Bootstrapping of devices into a secure network
       could also be considered given the location, limited display,
       high density and ad hoc deployment of devices.

6.  IANA Considerations


7.  Security Considerations


8.  Acknowledgements

   Thanks to :

   Geoff Mulligan

   Soohong Daniel Park

   Samita Chakrabarti

   Brijesh Kumar

   for their comments and help shaping this document.

9.  References

9.1  Normative References


              Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
              draft-ietf-ipv6-2461bis-01 (work in progress), October

              Thomson, S., "IPv6 Stateless Address Autoconfiguration",
              draft-ietf-ipv6-rfc2462bis-07 (work in progress), December

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

Kushalnagar & Montenegro    Expires August 15, 2005             [Page 9]

Internet-Draft         6lowpan Problems and Goals          February 2005

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

              IEEE Computer Society, "IEEE Std. 802.15.4-2003", October

9.2  Informative References

   [RFC3411]  Harrington, D., Presuhn, R. and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

   [RFC3561]  Perkins, C., Belding-Royer, E. and S. Das, "Ad hoc
              On-Demand Distance Vector (AODV) Routing", RFC 3561, July

   [RFC3626]  Clausen, T. and P. Jacquet, "Optimized Link State Routing
              Protocol (OLSR)", RFC 3626, October 2003.

   [RFC3684]  Ogier, R., Templin, F. and M. Lewis, "Topology
              Dissemination Based on Reverse-Path Forwarding (TBRPF)",
              RFC 3684, February 2004.

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

   [SOAP]     "SOAP", W3C http://www.w3c.org/2000/xp/Group/.

   [liaison]  "LIASONS", IETF

Authors' Addresses

   Nandakishore Kushalnagar
   Intel Corp

   EMail: nandakishore.kushalnagar@intel.com

   Gabriel Montenegro
   Sun Microsystems, Inc.

   EMail: gab@sun.com

Kushalnagar & Montenegro    Expires August 15, 2005            [Page 10]

Internet-Draft         6lowpan Problems and Goals          February 2005

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Kushalnagar & Montenegro    Expires August 15, 2005            [Page 11]