[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

6LoWPAN Working Group                                         C. Bormann
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Informational                                 D. Sturek
Expires: January 14, 2010                       Pacific Gas and Electric
                                                               Z. Shelby
                                                               Sensinode
                                                           July 13, 2009


  6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols
                draft-bormann-6lowpan-6lowapp-problem-01

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 January 14, 2010.

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.






Bormann, et al.         Expires January 14, 2010                [Page 1]

Internet-Draft          6LowApp Problem Statement              July 2009


Abstract

   The 6LoWPAN and ROLL WGs are laying the groundwork to make the
   Wireless Embedded Internet a reality, but what application protocols
   will we use?  Request-response protocols like HTTP are a poor fit to
   a communication model with battery-operated, mostly sleeping nodes.
   In addition, the usual data formats (both headers and body) are
   perceived to be too chatty for the 50-60 byte payloads possible in
   LoWPANs and to require too much code for the 8-bit and 16-bit
   processors dominating the Internet of Things.  Still, it would be a
   mistake to start a new silo of application protocols that do not
   benefit from existing application area Internet experience.

   This document provides a problem statement for possible work on of
   application protocols in 6LoWPAN networks or, more generally, in low-
   power, lossy networks, as well as some considerations for required
   related work.


































Bormann, et al.         Expires January 14, 2010                [Page 2]

Internet-Draft          6LowApp Problem Statement              July 2009


Table of Contents

   1.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Node and Network Characteristics . . . . . . . . . . . . . . .  6
   3.  Application Protocols  . . . . . . . . . . . . . . . . . . . .  7
   4.  Supporting Protocols . . . . . . . . . . . . . . . . . . . . .  9
   5.  Related Standardization Activities . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16








































Bormann, et al.         Expires January 14, 2010                [Page 3]

Internet-Draft          6LowApp Problem Statement              July 2009


1.  Problem Statement

   The 6LoWPAN and ROLL WGs are laying the groundwork to make the
   Wireless Embedded Internet a reality, but what application protocols
   will we use with these networks?

   6LoWPAN's low-power area networks (LoWPANs) and, more generally,
   ROLL's low-power lossy networks (LLNs) exhibit severe constraints on
   the bit rates achievable and the packet sizes that can be efficiently
   sent.  Many (but not always all) nodes in these networks also are
   constrained in the energy they can expend for computing and
   communication, the memory available, and the code size that can be
   accommodated in each node.  More generally speaking, there are many
   factors that play together to limit the per-node capabilities
   compared to today's typical Internet nodes.

   (Moreover in most cases links in LoWPANs and LLNs are "lossy" by
   nature, thus experience high bit error ratios, making the
   communication sometimes challenging.  The existing transport
   protocols used for reliability such as TCP may be too expensive to
   implement for LoWPAN nodes and may not perform well in lossy
   environments.)

   The established application protocols for Internet applications may
   be a poor fit for LoWPANs and LLNs.  For instance, request-response
   protocols like HTTP may require battery-operated, mostly sleeping
   nodes to be listening for requests much more frequently than their
   application processing requirements alone would need them to wake up.

   In addition, some of the applications may require optimizations in
   terms of bandwidth usage; for example, the usual data formats (both
   headers and body) are perceived to be too chatty for the 50-60 byte
   payloads possible in LoWPANs.  Their interpretation and generation
   may require too much code for the 8-bit and 16-bit processors
   dominating LoWPAN nodes.

   Still, it would be a mistake to start a new silo of application
   protocols that do not benefit from existing application area Internet
   experience.  A number of concepts well-established in the IETF
   application protocols, such as identifying resources by URIs, may
   transfer very well to LoWPANs.

   This document provides a problem statement for possible work on
   application protocols in LoWPANs or, more generally, in low-power,
   lossy networks (LLNs), as well as some considerations for required
   related work.  (When in doubt, it will focus on the requirements of
   LoWPANs, as these are more well-defined than the more general LLNs;
   we will therefore simply refer to both kinds of networks as LoWPANs.)



Bormann, et al.         Expires January 14, 2010                [Page 4]

Internet-Draft          6LowApp Problem Statement              July 2009


   This problem statement builds on the 6LoWPAN problem statement
   [RFC4919]; familiarity with the 6LoWPAN suite of specifications
   [RFC4944] [I-D.ietf-6lowpan-nd] [I-D.ietf-6lowpan-hc] may be useful.
   Application requirements may also be hinted at in the various ROLL
   routing requirements documents [I-D.ietf-roll-indus-routing-reqs]
   [I-D.ietf-roll-building-routing-reqs] [RFC5548]
   [I-D.ietf-roll-home-routing-reqs] as well as the 6LoWPAN-specific
   routing requirements [I-D.ietf-6lowpan-routing-requirements].











































Bormann, et al.         Expires January 14, 2010                [Page 5]

Internet-Draft          6LowApp Problem Statement              July 2009


2.  Node and Network Characteristics

   As mentioned in the introduction, the 6LowApp application protocol
   requirements are strongly influenced by the specific characteristics
   of LoWPAN nodes and networks.  This section provides a quick summary
   of the most important differences to the Internet nodes that most of
   today's application protocols have been developed for, drawing
   heavily on [I-D.ietf-6lowpan-routing-requirements].

   LoWPAN nodes may draw their power from primary batteries, forcing
   them to sleep most of the time (often with duty cycles of 0.1 % or
   lower) to achieve a reasonable battery lifetime (which may be
   identical to the node's lifetime!).  Other, more "power-affluent"
   nodes may be mains-powered or, especially if carried around by
   humans, work from rechargeable batteries.  Some devices may also make
   use of power scavenging where power can be harvested from solar or
   vibration energy; these nodes are designed for a long lifetime but
   still are power constrained and cannot afford to send long bursts of
   traffic.

   Both transmission and reception are consuming significant power,
   where often keeping the receiver available for reception is nearly as
   expensive as actual reception or transmission.  A mode of
   communication where LoWPAN nodes mostly decide on their own when to
   transmit is therefore more efficient.

   The underlying radio technologies are often limited in the packet
   sizes they support [IEEE802.15.4].  While 6LoWPAN provides
   fragmentation and reassembly to support the much larger MTU required
   by IPv6 (1280 bytes), actually using this mechanism is expensive and
   significantly decreases packet delivery probability.  This standard
   MTU is available if required for a specific activity, but most LoWPAN
   application protocols should attempt to get by with 50 to 60 byte
   packets (including some more or less compressed form of the IPv6
   header, making this number hard to pin down).

   Constrained LoWPAN nodes often only have a few KiB of RAM, and their
   code size tends to be limited to a value between 48 KiB and 128 KiB.
   Their processing speed may be limited by energy considerations to a
   few million instructions per second (which, at a duty cycle of 0.1 %
   or less, may mean a thousand instructions per second!).

   Nodes may be rather limited in their abilities for user interaction,
   requiring special considerations for their initial configuration
   ("commissioning") including security configuration, bootstrapping,
   and fault management.





Bormann, et al.         Expires January 14, 2010                [Page 6]

Internet-Draft          6LowApp Problem Statement              July 2009


3.  Application Protocols

   A large number of applications will be enabled by LoWPAN and other
   LLN technologies becoming available for wide deployment.  The four
   ROLL requirements documents cited above hint at possible use cases
   and their characteristics; additional use cases are documented in
   [I-D.ietf-6lowpan-usecases].

   The whole point of using IP in LoWPANs is to let nodes in the LoWPANs
   interact directly with other IP-connected nodes.  While software
   running on 6LoWPAN nodes will be highly application specific, the
   correspondent nodes will often be based on today's commodity systems;
   issues of integration with the software (including operating systems)
   running on these systems should be minimized.  This appears to call
   for the use of existing, widely deployed transport protocols such as
   UDP and TCP.

   Today's LoWPAN nodes typically use UDP exclusively.  TCP is complex
   enough to be a concern for some very limited systems; also, its
   reaction to loss as a congestion signal may not be appropriate for
   lossy LoWPAN networks, in particular where some real-time
   requirements are involved.

   On the other hand, some form of acknowledged and numbered packet
   delivery is required for lossy networks.  So far, application
   developers have resorted to using UDP with application specified
   sequence numbers, transmission timeouts and retries.  Not having TCP
   available limits the availability of many established application
   protocols that depend on TCP or at least are implemented using TCP in
   correspondent nodes today.

   The use of UDP and the limited packet sizes efficiently supported by
   LoWPANs make relatively verbose protocols such as HTTP less
   desirable.  On the other hand, key principles of the web such as
   resource identifiers (URIs), content types (MIME), statelessness,
   proxy support etc. are most desirable.

   Possible additional elements from solution space include:

      Connection splitting at border devices.  The LoWPAN architecture
      calls for relatively powerful devices at the border of the
      constrained networks ("edge routers").  These could include PEP
      functions [RFC3135] including TCP splitting, possibly using a
      limited/specialized form of TCP for the connection segment within
      the LoWPAN.

      Full support for Web services (not very likely of the WS-*
      variety).  The objective would be to enable deployment of simple



Bormann, et al.         Expires January 14, 2010                [Page 7]

Internet-Draft          6LowApp Problem Statement              July 2009


      web-accessible resources (possibly even including human-readable
      web pages) for small footprint devices interfaced with a compact
      exchange protocol.  Investigate deployment of a small footprint
      condensed HTTP-like protocol.  Investigate use of tokenized XML in
      addition to condensed HTTP.

      SNMP.  The objective would be to enable SNMP services, again for
      small footprint devices.  Investigate deployment of a compact
      version of SNMP limited to small UDP packets.  Ensure that
      security services are available for the compact version of SNMP,
      even if it must be deployed using UDP.  More generally, many nodes
      will not have resources for implementing both SNMP and HTTP; a way
      to obtain the benefits of both in one implementation would be
      preferable.  (The point that these two protocols address different
      communities and are even handled in two separate areas in the IETF
      is well taken.)



































Bormann, et al.         Expires January 14, 2010                [Page 8]

Internet-Draft          6LowApp Problem Statement              July 2009


4.  Supporting Protocols

   Supporting protocols are needed for commissioning (including
   security, see next section) and bootstrapping.

   In order to simplify commissioning (plug-and-play operation) and
   bootstrapping, a service discovery protocol (such as SLP) optimized
   for LoWPAN usage is likely to be employed.  Possible elements from
   solution space include:

      A Service Discovery repository for devices which sleep most of the
      time.  (The design space might include a centralized repository,
      e.g. on the Edge Router, as well as decentralised repositories for
      the service discovery protocol.)

      Application specified fields in the service discovery repository
      and in the search protocol that enable a device with specific
      application defined characteristics to be selectively discovered
      by other devices in the network.

      An ability to set the scope of "the network" to produce bounded
      service discovery requests matching network resource capabilities.
      (The scope might not be limited to the LoWPAN, but might contain
      hosts from the networks the edge routers are attached to.

      A protocol that is able to differentiate between types of
      services, such as source, processing, sink as well as
      commissioning and bootstrapping services and possibly connects
      matching services to each other.

      A rich protocol for service discovery requests that wherever
      possible tries to limit resource usage of the network to support
      the request while supplying targeted responses.  Specifically,
      this would obviate the need for multicast and would introduce some
      binary tags etc. rather than string-based descriptions which
      require too much code to parse and are too chatty.















Bormann, et al.         Expires January 14, 2010                [Page 9]

Internet-Draft          6LowApp Problem Statement              July 2009


5.  Related Standardization Activities

   6LowApp will need to interface with various other standardization
   efforts, such as

      ISA SP100.11a

      the ZigBee/IP effort

      the Smart Energy standardization at the IEC

      UCA International (and OpenSG)

      Society of Automotive Engineers (SAE)

      ETSI Machine-to-Machine (M2M) Technical Committee (TC)

      Efficient XML Interchange (EXI) at the W3C

      New EU smart grid standardization effort

      Open Geospatial Consortium (SWE)

      Device Profile Web Services (DPWS)

      BACnet: A Data Communication Protocol for Building Automation and
      Control Networks (ANSI/ASHRAE 135-2008, EN ISO16484-5)

   As an example, consider the needs of "Smart Grid" Home Area
   Networking (HAN) Applications.  For Smart Grid HAN applications,
   getting IP connectivity to devices such as thermostats, in-home
   displays, load control wall plugs, refrigerators and plug-in electric
   vehicles solves the problem of introducing these devices onto the
   internet.  To fully realize application deployment the following
   features are needed:

      A basic framework for reliability as is provided by TCP for most
      existing application protocols (see Application Protocols above).

      A basic framework for service discovery (see Supporting Protocols
      above).

      Security (see Security Considerations below).

      Roaming support.  Nodes will need to bootstrap in different
      LoWPANs, e.g., plug-in electric vehicles (PEVs) will need the
      ability to roam between networks.  It is not clear that MobileIP
      will solve even part of this problem as there may not be a logical



Bormann, et al.         Expires January 14, 2010               [Page 10]

Internet-Draft          6LowApp Problem Statement              July 2009


      place to hold a forwarding registry.  There will be relatively
      many such devices; it is not clear that assuming a static global
      IP address per car is the right approach. 6LowApp should consider
      the ZigBee/HomePlug MRD Use Cases, the SAE use cases around PEVs
      and consider how roaming devices can be accommocated.  Also, there
      is an IEC group (TC 22, Task Group 3) working on a similar
      solution so that work should be reviewed for requirements.

   In addition, this is an area where the use of intermediate processing
   nodes -- sometimes referred to as ALG (Application Layer Gateways --
   providing enhanced security, local data processing and storage,
   provisioning, etc. may be of particular interest.

   (Another related area is future applications in support of the smart
   grid, for example "sub-station automation" where new IP sensors and
   actuators are being developed and for which one may consider the
   interconnection of existing legacy applications to IP-based
   applications, beyond IP connectivity.)

   In addition to a compact, efficient application protocol, the content
   carried in such a protocol is equally important.  XML is not suitable
   for use with the limited payload sizes available on LoWPANs and for
   parsing on simple embedded devices.  Relevant standardization efforts
   are being performed which enable the encoding of XML in suitable
   formats.  For example at the W3C, the Efficient XML Interchange (EXI)
   format has been developed, allowing for XML to be represented in a
   very compact and machine-parsable format.
























Bormann, et al.         Expires January 14, 2010               [Page 11]

Internet-Draft          6LowApp Problem Statement              July 2009


6.  Security Considerations

   Many LoWPAN applications have strong security requirements.  Some of
   these will need to be solved at the underlying link layer (6LoWPAN
   devices usually have good support for confidentiality and
   authentication), many will require solutions at the application layer
   (possibly using transport layer security).  Most devices will benefit
   from some synergy between the key management mechanisms at these two
   layers; in any case these mechanisms must be appropriate for highly
   constrained devices.

   Possible elements from solution space include:

      EAP is well-known in the wireless world and appears to be a good
      framework to standardize on.  However, work is needed on open
      security methods applicable to small footprint devices.

      For applications wanting to use certificates, enhancements to the
      current usage of certificates (X.509) and IEEE 802.1X may be
      needed to support small footprint devices.































Bormann, et al.         Expires January 14, 2010               [Page 12]

Internet-Draft          6LowApp Problem Statement              July 2009


7.  Acknowledgements

   The authors would like to thank JP Vasseur, Jerry Martocci and Markus
   Becker for useful input about applications in the Wireless Embedded
   Internet.














































Bormann, et al.         Expires January 14, 2010               [Page 13]

Internet-Draft          6LowApp Problem Statement              July 2009


8.  Informative References

   [I-D.ietf-6lowpan-hc]
              Hui, J. and P. Thubert, "Compression Format for IPv6
              Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-05
              (work in progress), June 2009.

   [I-D.ietf-6lowpan-nd]
              Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E.
              Nordmark, "6LoWPAN Neighbor Discovery",
              draft-ietf-6lowpan-nd-04 (work in progress), July 2009.

   [I-D.ietf-6lowpan-routing-requirements]
              Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
              Statement and Requirements for 6LoWPAN Routing",
              draft-ietf-6lowpan-routing-requirements-02 (work in
              progress), March 2009.

   [I-D.ietf-6lowpan-usecases]
              Kim, E., Kaspar, D., Chevrollier, N., and J. Vasseur,
              "Design and Application Spaces for 6LoWPANs",
              draft-ietf-6lowpan-usecases-03 (work in progress),
              July 2009.

   [I-D.ietf-roll-building-routing-reqs]
              Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
              "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-06 (work in
              progress), June 2009.

   [IEEE802.15.4]
              IEEE Computer Society, "IEEE Std. 802.15.4-2006 (as
              amended)", 2007.

   [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
              Shelby, "Performance Enhancing Proxies Intended to



Bormann, et al.         Expires January 14, 2010               [Page 14]

Internet-Draft          6LowApp Problem Statement              July 2009


              Mitigate Link-Related Degradations", RFC 3135, June 2001.

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

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.





































Bormann, et al.         Expires January 14, 2010               [Page 15]

Internet-Draft          6LowApp Problem Statement              July 2009


Authors' Addresses

   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


   Don Sturek
   Consultant, Pacific Gas and Electric
   77 Beale Street
   San Francisco, CA
   USA

   Phone: +1-619-504-3615
   Email: d.sturek@att.net


   Zach Shelby
   Sensinode
   Kidekuja 2
   Vuokatti  88600
   FINLAND

   Phone: +358407796297
   Email: zach@sensinode.com




















Bormann, et al.         Expires January 14, 2010               [Page 16]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/