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]