6LoWPAN Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Informational D. Sturek
Expires: January 6, 2010 Pacific Gas and Electric
Z. Shelby
Sensinode
July 5, 2009
6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols
draft-bormann-6lowpan-6lowapp-problem-00
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 6, 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 6, 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 6, 2010 [Page 2]
Internet-Draft 6LowApp Problem Statement July 2009
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
2. Node and Network Characteristics . . . . . . . . . . . . . . . 5
3. Application Protocols . . . . . . . . . . . . . . . . . . . . 6
4. Supporting Protocols . . . . . . . . . . . . . . . . . . . . . 8
5. Related Standardization Activities . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Bormann, et al. Expires January 6, 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.
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, 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.)
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 6, 2010 [Page 4]
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.
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 6, 2010 [Page 5]
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 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 6, 2010 [Page 6]
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 6, 2010 [Page 7]
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.
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.
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 6, 2010 [Page 8]
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)
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
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 review
Bormann, et al. Expires January 6, 2010 [Page 9]
Internet-Draft 6LowApp Problem Statement July 2009
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 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 6, 2010 [Page 10]
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 6, 2010 [Page 11]
Internet-Draft 6LowApp Problem Statement July 2009
7. 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, "Neighbor Discovery for 6LoWPAN",
draft-ietf-6lowpan-nd-03 (work in progress), May 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., Chevrollier, N., Kaspar, D., and J. Vasseur,
"Design and Application Spaces for 6LoWPANs",
draft-ietf-6lowpan-usecases-02 (work in progress),
March 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 6, 2010 [Page 12]
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 6, 2010 [Page 13]
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 6, 2010 [Page 14]