idnits 2.17.1 draft-bormann-6lowpan-6lowapp-problem-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2009) is 5407 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-6lowpan-hc-05 == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-03 == Outdated reference: A later version (-10) exists of draft-ietf-6lowpan-routing-requirements-02 == Outdated reference: A later version (-10) exists of draft-ietf-6lowpan-usecases-02 == Outdated reference: A later version (-09) exists of draft-ietf-roll-building-routing-reqs-05 == Outdated reference: A later version (-11) exists of draft-ietf-roll-home-routing-reqs-06 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational D. Sturek 5 Expires: January 6, 2010 Pacific Gas and Electric 6 Z. Shelby 7 Sensinode 8 July 5, 2009 10 6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols 11 draft-bormann-6lowpan-6lowapp-problem-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 6, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 The 6LoWPAN and ROLL WGs are laying the groundwork to make the 50 Wireless Embedded Internet a reality, but what application protocols 51 will we use? Request-response protocols like HTTP are a poor fit to 52 a communication model with battery-operated, mostly sleeping nodes. 53 In addition, the usual data formats (both headers and body) are 54 perceived to be too chatty for the 50-60 byte payloads possible in 55 LoWPANs and to require too much code for the 8-bit and 16-bit 56 processors dominating the Internet of Things. Still, it would be a 57 mistake to start a new silo of application protocols that do not 58 benefit from existing application area Internet experience. 60 This document provides a problem statement for possible work on of 61 application protocols in 6LoWPAN networks or, more generally, in low- 62 power, lossy networks, as well as some considerations for required 63 related work. 65 Table of Contents 67 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Node and Network Characteristics . . . . . . . . . . . . . . . 5 69 3. Application Protocols . . . . . . . . . . . . . . . . . . . . 6 70 4. Supporting Protocols . . . . . . . . . . . . . . . . . . . . . 8 71 5. Related Standardization Activities . . . . . . . . . . . . . . 9 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 7. Informative References . . . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Problem Statement 78 The 6LoWPAN and ROLL WGs are laying the groundwork to make the 79 Wireless Embedded Internet a reality, but what application protocols 80 will we use with these networks? 82 6LoWPAN's low-power area networks (LoWPANs) and, more generally, 83 ROLL's low-power lossy networks (LLNs) exhibit severe constraints on 84 the bit rates achievable and the packet sizes that can be efficiently 85 sent. Many (but not always all) nodes in these networks also are 86 constrained in the energy they can expend for computing and 87 communication, the memory available, and the code size that can be 88 accommodated in each node. More generally speaking, there are many 89 factors that play together to limit the per-node capabilities 90 compared to today's typical Internet nodes. 92 The established application protocols for Internet applications may 93 be a poor fit for LoWPANs and LLNs. For instance, request-response 94 protocols like HTTP may require battery-operated, mostly sleeping 95 nodes to be listening for requests much more frequently than their 96 application processing requirements alone would need them to wake up. 98 In addition, the usual data formats (both headers and body) are 99 perceived to be too chatty for the 50-60 byte payloads possible in 100 LoWPANs. Their interpretation and generation may require too much 101 code for the 8-bit and 16-bit processors dominating LoWPAN nodes. 103 Still, it would be a mistake to start a new silo of application 104 protocols that do not benefit from existing application area Internet 105 experience. A number of concepts well-established in the IETF 106 application protocols, such as identifying resources by URIs, may 107 transfer very well to LoWPANs. 109 This document provides a problem statement for possible work on 110 application protocols in LoWPANs or, more generally, in low-power, 111 lossy networks (LLNs), as well as some considerations for required 112 related work. (When in doubt, it will focus on the requirements of 113 LoWPANs, as these are more well-defined than the more general LLNs; 114 we will therefore simply refer to both kinds of networks as LoWPANs.) 116 This problem statement builds on the 6LoWPAN problem statement 117 [RFC4919]; familiarity with the 6LoWPAN suite of specifications 118 [RFC4944] [I-D.ietf-6lowpan-nd] [I-D.ietf-6lowpan-hc] may be useful. 119 Application requirements may also be hinted at in the various ROLL 120 routing requirements documents [I-D.ietf-roll-indus-routing-reqs] 121 [I-D.ietf-roll-building-routing-reqs] [RFC5548] 122 [I-D.ietf-roll-home-routing-reqs] as well as the 6LoWPAN-specific 123 routing requirements [I-D.ietf-6lowpan-routing-requirements]. 125 2. Node and Network Characteristics 127 As mentioned in the introduction, the 6LowApp application protocol 128 requirements are strongly influenced by the specific characteristics 129 of LoWPAN nodes and networks. This section provides a quick summary 130 of the most important differences to the Internet nodes that most of 131 today's application protocols have been developed for, drawing 132 heavily on [I-D.ietf-6lowpan-routing-requirements]. 134 LoWPAN nodes may draw their power from primary batteries, forcing 135 them to sleep most of the time (often with duty cycles of 0.1 % or 136 lower) to achieve a reasonable battery lifetime (which may be 137 identical to the node's lifetime!). Other, more "power-affluent" 138 nodes may be mains-powered or, especially if carried around by 139 humans, work from rechargeable batteries. 141 Both transmission and reception are consuming significant power, 142 where often keeping the receiver available for reception is nearly as 143 expensive as actual reception or transmission. A mode of 144 communication where LoWPAN nodes mostly decide on their own when to 145 transmit is therefore more efficient. 147 The underlying radio technologies are often limited in the packet 148 sizes they support [IEEE802.15.4]. While 6LoWPAN provides 149 fragmentation and reassembly to support the much larger MTU required 150 by IPv6 (1280 bytes), actually using this mechanism is expensive and 151 significantly decreases packet delivery probability. This standard 152 MTU is available if required for a specific activity, but most LoWPAN 153 application protocols should attempt to get by with 50 to 60 byte 154 packets (including some more or less compressed form of the IPv6 155 header, making this number hard to pin down). 157 Constrained LoWPAN nodes often only have a few KiB of RAM, and their 158 code size tends to be limited to a value between 48 KiB and 128 KiB. 159 Their processing speed may be limited by energy considerations to a 160 few million instructions per second (which, at a duty cycle of 0.1 % 161 or less, may mean a thousand instructions per second!). 163 Nodes may be rather limited in their abilities for user interaction, 164 requiring special considerations for their initial configuration 165 ("commissioning") including security configuration, bootstrapping, 166 and fault management. 168 3. Application Protocols 170 A large number of applications will be enabled by LoWPAN and other 171 LLN technologies becoming available for wide deployment. The four 172 ROLL requirements documents cited above hint at possible use cases 173 and their characteristics; additional use cases are documented in 174 [I-D.ietf-6lowpan-usecases]. 176 The whole point of using IP in LoWPANs is to let nodes in the LoWPANs 177 interact directly with other IP-connected nodes. While software 178 running on 6LoWPAN nodes will be highly application specific, the 179 correspondent nodes will often be based on today's commodity systems; 180 issues of integration with the software (including operating systems) 181 running on these systems should be minimized. This appears to call 182 for the use of existing, widely deployed transport protocols such as 183 UDP and TCP. 185 Today's LoWPAN nodes typically use UDP exclusively. TCP is complex 186 enough to be a concern for very limited systems; also, its reaction 187 to loss as a congestion signal may not be appropriate for lossy 188 LoWPAN networks, in particular where some real-time requirements are 189 involved. 191 On the other hand, some form of acknowledged and numbered packet 192 delivery is required for lossy networks. So far, application 193 developers have resorted to using UDP with application specified 194 sequence numbers, transmission timeouts and retries. Not having TCP 195 available limits the availability of many established application 196 protocols that depend on TCP or at least are implemented using TCP in 197 correspondent nodes today. 199 The use of UDP and the limited packet sizes efficiently supported by 200 LoWPANs make relatively verbose protocols such as HTTP less 201 desirable. On the other hand, key principles of the web such as 202 resource identifiers (URIs), content types (MIME), statelessness, 203 proxy support etc. are most desirable. 205 Possible additional elements from solution space include: 207 Connection splitting at border devices. The LoWPAN architecture 208 calls for relatively powerful devices at the border of the 209 constrained networks ("edge routers"). These could include PEP 210 functions [RFC3135] including TCP splitting, possibly using a 211 limited/specialized form of TCP for the connection segment within 212 the LoWPAN. 214 Full support for Web services (not very likely of the WS-* 215 variety). The objective would be to enable deployment of simple 216 web-accessible resources (possibly even including human-readable 217 web pages) for small footprint devices interfaced with a compact 218 exchange protocol. Investigate deployment of a small footprint 219 condensed HTTP-like protocol. Investigate use of tokenized XML in 220 addition to condensed HTTP. 222 SNMP. The objective would be to enable SNMP services, again for 223 small footprint devices. Investigate deployment of a compact 224 version of SNMP limited to small UDP packets. Ensure that 225 security services are available for the compact version of SNMP, 226 even if it must be deployed using UDP. More generally, many nodes 227 will not have resources for implementing both SNMP and HTTP; a way 228 to obtain the benefits of both in one implementation would be 229 preferable. (The point that these two protocols address different 230 communities and are even handled in two separate areas in the IETF 231 is well taken.) 233 4. Supporting Protocols 235 Supporting protocols are needed for commissioning (including 236 security, see next section) and bootstrapping. 238 In order to simplify commissioning (plug-and-play operation) and 239 bootstrapping, a service discovery protocol (such as SLP) optimized 240 for LoWPAN usage is likely to be employed. Possible elements from 241 solution space include: 243 A Service Discovery repository for devices which sleep most of the 244 time. 246 Application specified fields in the service discovery repository 247 and in the search protocol that enable a device with specific 248 application defined characteristics to be selectively discovered 249 by other devices in the network. 251 An ability to set the scope of "the network" to produce bounded 252 service discovery requests matching network resource capabilities. 254 A rich protocol for service discovery requests that wherever 255 possible tries to limit resource usage of the network to support 256 the request while supplying targeted responses. Specifically, 257 this would obviate the need for multicast and would introduce some 258 binary tags etc. rather than string-based descriptions which 259 require too much code to parse and are too chatty. 261 5. Related Standardization Activities 263 6LowApp will need to interface with various other standardization 264 efforts, such as 266 ISA SP100.11a 268 the ZigBee/IP effort 270 the Smart Energy standardization at the IEC 272 UCA International (and OpenSG) 274 Society of Automotive Engineers (SAE) 276 ETSI Machine-to-Machine (M2M) Technical Committee (TC) 278 Efficient XML Interchange (EXI) at the W3C 280 New EU smart grid standardization effort 282 Open Geospatial Consortium (SWE) 284 Device Profile Web Services (DPWS) 286 As an example, consider the needs of "Smart Grid" Home Area 287 Networking (HAN) Applications. For Smart Grid HAN applications, 288 getting IP connectivity to devices such as thermostats, in-home 289 displays, load control wall plugs, refrigerators and plug-in electric 290 vehicles solves the problem of introducing these devices onto the 291 internet. To fully realize application deployment the following 292 features are needed: 294 A basic framework for reliability as is provided by TCP for most 295 existing application protocols (see Application Protocols above). 297 A basic framework for service discovery (see Supporting Protocols 298 above). 300 Security (see Security Considerations below). 302 Roaming support. Nodes will need to bootstrap in different 303 LoWPANs, e.g., plug-in electric vehicles (PEVs) will need the 304 ability to roam between networks. It is not clear that MobileIP 305 will solve even part of this problem as there may not be a logical 306 place to hold a forwarding registry. There will be relatively 307 many such devices; it is not clear that assuming a static global 308 IP address per car is the right approach. 6LowApp should review 309 the ZigBee/HomePlug MRD Use Cases, the SAE use cases around PEVs 310 and consider how roaming devices can be accommocated. Also, there 311 is an IEC group (TC 22, Task Group 3) working on a similar 312 solution so that work should be reviewed for requirements. 314 In addition to a compact, efficient application protocol, the content 315 carried in such a protocol is equally important. XML is not suitable 316 for use with the limited payload sizes available on LoWPANs and for 317 parsing on simple embedded devices. Relevant standardization efforts 318 are being performed which enable the encoding of XML in suitable 319 formats. For example at the W3C, the Efficient XML Interchange (EXI) 320 format has been developed, allowing for XML to be represented in a 321 very compact and machine-parsable format. 323 6. Security Considerations 325 Many LoWPAN applications have strong security requirements. Some of 326 these will need to be solved at the underlying link layer (6LoWPAN 327 devices usually have good support for confidentiality and 328 authentication), many will require solutions at the application layer 329 (possibly using transport layer security). Most devices will benefit 330 from some synergy between the key management mechanisms at these two 331 layers; in any case these mechanisms must be appropriate for highly 332 constrained devices. 334 Possible elements from solution space include: 336 EAP is well-known in the wireless world and appears to be a good 337 framework to standardize on. However, work is needed on open 338 security methods applicable to small footprint devices. 340 For applications wanting to use certificates, enhancements to the 341 current usage of certificates (X.509) and IEEE 802.1X may be 342 needed to support small footprint devices. 344 7. Informative References 346 [I-D.ietf-6lowpan-hc] 347 Hui, J. and P. Thubert, "Compression Format for IPv6 348 Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-05 349 (work in progress), June 2009. 351 [I-D.ietf-6lowpan-nd] 352 Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. 353 Nordmark, "Neighbor Discovery for 6LoWPAN", 354 draft-ietf-6lowpan-nd-03 (work in progress), May 2009. 356 [I-D.ietf-6lowpan-routing-requirements] 357 Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 358 Statement and Requirements for 6LoWPAN Routing", 359 draft-ietf-6lowpan-routing-requirements-02 (work in 360 progress), March 2009. 362 [I-D.ietf-6lowpan-usecases] 363 Kim, E., Chevrollier, N., Kaspar, D., and J. Vasseur, 364 "Design and Application Spaces for 6LoWPANs", 365 draft-ietf-6lowpan-usecases-02 (work in progress), 366 March 2009. 368 [I-D.ietf-roll-building-routing-reqs] 369 Martocci, J., Riou, N., Mil, P., and W. Vermeylen, 370 "Building Automation Routing Requirements in Low Power and 371 Lossy Networks", draft-ietf-roll-building-routing-reqs-05 372 (work in progress), February 2009. 374 [I-D.ietf-roll-home-routing-reqs] 375 Porcu, G., "Home Automation Routing Requirements in Low 376 Power and Lossy Networks", 377 draft-ietf-roll-home-routing-reqs-06 (work in progress), 378 November 2008. 380 [I-D.ietf-roll-indus-routing-reqs] 381 Networks, D., Thubert, P., Dwars, S., and T. Phinney, 382 "Industrial Routing Requirements in Low Power and Lossy 383 Networks", draft-ietf-roll-indus-routing-reqs-06 (work in 384 progress), June 2009. 386 [IEEE802.15.4] 387 IEEE Computer Society, "IEEE Std. 802.15.4-2006 (as 388 amended)", 2007. 390 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 391 Shelby, "Performance Enhancing Proxies Intended to 392 Mitigate Link-Related Degradations", RFC 3135, June 2001. 394 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 395 over Low-Power Wireless Personal Area Networks (6LoWPANs): 396 Overview, Assumptions, Problem Statement, and Goals", 397 RFC 4919, August 2007. 399 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 400 "Transmission of IPv6 Packets over IEEE 802.15.4 401 Networks", RFC 4944, September 2007. 403 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 404 "Routing Requirements for Urban Low-Power and Lossy 405 Networks", RFC 5548, May 2009. 407 Authors' Addresses 409 Carsten Bormann 410 Universitaet Bremen TZI 411 Postfach 330440 412 Bremen D-28359 413 Germany 415 Phone: +49-421-218-63921 416 Fax: +49-421-218-7000 417 Email: cabo@tzi.org 419 Don Sturek 420 Consultant, Pacific Gas and Electric 421 77 Beale Street 422 San Francisco, CA 423 USA 425 Phone: +1-619-504-3615 426 Email: d.sturek@att.net 428 Zach Shelby 429 Sensinode 430 Kidekuja 2 431 Vuokatti 88600 432 FINLAND 434 Phone: +358407796297 435 Email: zach@sensinode.com