idnits 2.17.00 (12 Aug 2021) /tmp/idnits20160/draft-bormann-6lowpan-6lowapp-problem-01.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 13, 2009) is 4688 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-6lowpan-hc has been published as RFC 6282 == Outdated reference: draft-ietf-6lowpan-nd has been published as RFC 6775 == Outdated reference: draft-ietf-6lowpan-routing-requirements has been published as RFC 6606 == Outdated reference: draft-ietf-6lowpan-usecases has been published as RFC 6568 == Outdated reference: draft-ietf-roll-building-routing-reqs has been published as RFC 5867 == Outdated reference: draft-ietf-roll-home-routing-reqs has been published as RFC 5826 == Outdated reference: draft-ietf-roll-indus-routing-reqs has been published as RFC 5673 Summary: 3 errors (**), 0 flaws (~~), 8 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 14, 2010 Pacific Gas and Electric 6 Z. Shelby 7 Sensinode 8 July 13, 2009 10 6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols 11 draft-bormann-6lowpan-6lowapp-problem-01 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 14, 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 . . . . . . . . . . . . . . . 6 69 3. Application Protocols . . . . . . . . . . . . . . . . . . . . 7 70 4. Supporting Protocols . . . . . . . . . . . . . . . . . . . . . 9 71 5. Related Standardization Activities . . . . . . . . . . . . . . 10 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 74 8. Informative References . . . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Problem Statement 79 The 6LoWPAN and ROLL WGs are laying the groundwork to make the 80 Wireless Embedded Internet a reality, but what application protocols 81 will we use with these networks? 83 6LoWPAN's low-power area networks (LoWPANs) and, more generally, 84 ROLL's low-power lossy networks (LLNs) exhibit severe constraints on 85 the bit rates achievable and the packet sizes that can be efficiently 86 sent. Many (but not always all) nodes in these networks also are 87 constrained in the energy they can expend for computing and 88 communication, the memory available, and the code size that can be 89 accommodated in each node. More generally speaking, there are many 90 factors that play together to limit the per-node capabilities 91 compared to today's typical Internet nodes. 93 (Moreover in most cases links in LoWPANs and LLNs are "lossy" by 94 nature, thus experience high bit error ratios, making the 95 communication sometimes challenging. The existing transport 96 protocols used for reliability such as TCP may be too expensive to 97 implement for LoWPAN nodes and may not perform well in lossy 98 environments.) 100 The established application protocols for Internet applications may 101 be a poor fit for LoWPANs and LLNs. For instance, request-response 102 protocols like HTTP may require battery-operated, mostly sleeping 103 nodes to be listening for requests much more frequently than their 104 application processing requirements alone would need them to wake up. 106 In addition, some of the applications may require optimizations in 107 terms of bandwidth usage; for example, the usual data formats (both 108 headers and body) are perceived to be too chatty for the 50-60 byte 109 payloads possible in LoWPANs. Their interpretation and generation 110 may require too much code for the 8-bit and 16-bit processors 111 dominating LoWPAN nodes. 113 Still, it would be a mistake to start a new silo of application 114 protocols that do not benefit from existing application area Internet 115 experience. A number of concepts well-established in the IETF 116 application protocols, such as identifying resources by URIs, may 117 transfer very well to LoWPANs. 119 This document provides a problem statement for possible work on 120 application protocols in LoWPANs or, more generally, in low-power, 121 lossy networks (LLNs), as well as some considerations for required 122 related work. (When in doubt, it will focus on the requirements of 123 LoWPANs, as these are more well-defined than the more general LLNs; 124 we will therefore simply refer to both kinds of networks as LoWPANs.) 125 This problem statement builds on the 6LoWPAN problem statement 126 [RFC4919]; familiarity with the 6LoWPAN suite of specifications 127 [RFC4944] [I-D.ietf-6lowpan-nd] [I-D.ietf-6lowpan-hc] may be useful. 128 Application requirements may also be hinted at in the various ROLL 129 routing requirements documents [I-D.ietf-roll-indus-routing-reqs] 130 [I-D.ietf-roll-building-routing-reqs] [RFC5548] 131 [I-D.ietf-roll-home-routing-reqs] as well as the 6LoWPAN-specific 132 routing requirements [I-D.ietf-6lowpan-routing-requirements]. 134 2. Node and Network Characteristics 136 As mentioned in the introduction, the 6LowApp application protocol 137 requirements are strongly influenced by the specific characteristics 138 of LoWPAN nodes and networks. This section provides a quick summary 139 of the most important differences to the Internet nodes that most of 140 today's application protocols have been developed for, drawing 141 heavily on [I-D.ietf-6lowpan-routing-requirements]. 143 LoWPAN nodes may draw their power from primary batteries, forcing 144 them to sleep most of the time (often with duty cycles of 0.1 % or 145 lower) to achieve a reasonable battery lifetime (which may be 146 identical to the node's lifetime!). Other, more "power-affluent" 147 nodes may be mains-powered or, especially if carried around by 148 humans, work from rechargeable batteries. Some devices may also make 149 use of power scavenging where power can be harvested from solar or 150 vibration energy; these nodes are designed for a long lifetime but 151 still are power constrained and cannot afford to send long bursts of 152 traffic. 154 Both transmission and reception are consuming significant power, 155 where often keeping the receiver available for reception is nearly as 156 expensive as actual reception or transmission. A mode of 157 communication where LoWPAN nodes mostly decide on their own when to 158 transmit is therefore more efficient. 160 The underlying radio technologies are often limited in the packet 161 sizes they support [IEEE802.15.4]. While 6LoWPAN provides 162 fragmentation and reassembly to support the much larger MTU required 163 by IPv6 (1280 bytes), actually using this mechanism is expensive and 164 significantly decreases packet delivery probability. This standard 165 MTU is available if required for a specific activity, but most LoWPAN 166 application protocols should attempt to get by with 50 to 60 byte 167 packets (including some more or less compressed form of the IPv6 168 header, making this number hard to pin down). 170 Constrained LoWPAN nodes often only have a few KiB of RAM, and their 171 code size tends to be limited to a value between 48 KiB and 128 KiB. 172 Their processing speed may be limited by energy considerations to a 173 few million instructions per second (which, at a duty cycle of 0.1 % 174 or less, may mean a thousand instructions per second!). 176 Nodes may be rather limited in their abilities for user interaction, 177 requiring special considerations for their initial configuration 178 ("commissioning") including security configuration, bootstrapping, 179 and fault management. 181 3. Application Protocols 183 A large number of applications will be enabled by LoWPAN and other 184 LLN technologies becoming available for wide deployment. The four 185 ROLL requirements documents cited above hint at possible use cases 186 and their characteristics; additional use cases are documented in 187 [I-D.ietf-6lowpan-usecases]. 189 The whole point of using IP in LoWPANs is to let nodes in the LoWPANs 190 interact directly with other IP-connected nodes. While software 191 running on 6LoWPAN nodes will be highly application specific, the 192 correspondent nodes will often be based on today's commodity systems; 193 issues of integration with the software (including operating systems) 194 running on these systems should be minimized. This appears to call 195 for the use of existing, widely deployed transport protocols such as 196 UDP and TCP. 198 Today's LoWPAN nodes typically use UDP exclusively. TCP is complex 199 enough to be a concern for some very limited systems; also, its 200 reaction to loss as a congestion signal may not be appropriate for 201 lossy LoWPAN networks, in particular where some real-time 202 requirements are involved. 204 On the other hand, some form of acknowledged and numbered packet 205 delivery is required for lossy networks. So far, application 206 developers have resorted to using UDP with application specified 207 sequence numbers, transmission timeouts and retries. Not having TCP 208 available limits the availability of many established application 209 protocols that depend on TCP or at least are implemented using TCP in 210 correspondent nodes today. 212 The use of UDP and the limited packet sizes efficiently supported by 213 LoWPANs make relatively verbose protocols such as HTTP less 214 desirable. On the other hand, key principles of the web such as 215 resource identifiers (URIs), content types (MIME), statelessness, 216 proxy support etc. are most desirable. 218 Possible additional elements from solution space include: 220 Connection splitting at border devices. The LoWPAN architecture 221 calls for relatively powerful devices at the border of the 222 constrained networks ("edge routers"). These could include PEP 223 functions [RFC3135] including TCP splitting, possibly using a 224 limited/specialized form of TCP for the connection segment within 225 the LoWPAN. 227 Full support for Web services (not very likely of the WS-* 228 variety). The objective would be to enable deployment of simple 229 web-accessible resources (possibly even including human-readable 230 web pages) for small footprint devices interfaced with a compact 231 exchange protocol. Investigate deployment of a small footprint 232 condensed HTTP-like protocol. Investigate use of tokenized XML in 233 addition to condensed HTTP. 235 SNMP. The objective would be to enable SNMP services, again for 236 small footprint devices. Investigate deployment of a compact 237 version of SNMP limited to small UDP packets. Ensure that 238 security services are available for the compact version of SNMP, 239 even if it must be deployed using UDP. More generally, many nodes 240 will not have resources for implementing both SNMP and HTTP; a way 241 to obtain the benefits of both in one implementation would be 242 preferable. (The point that these two protocols address different 243 communities and are even handled in two separate areas in the IETF 244 is well taken.) 246 4. Supporting Protocols 248 Supporting protocols are needed for commissioning (including 249 security, see next section) and bootstrapping. 251 In order to simplify commissioning (plug-and-play operation) and 252 bootstrapping, a service discovery protocol (such as SLP) optimized 253 for LoWPAN usage is likely to be employed. Possible elements from 254 solution space include: 256 A Service Discovery repository for devices which sleep most of the 257 time. (The design space might include a centralized repository, 258 e.g. on the Edge Router, as well as decentralised repositories for 259 the service discovery protocol.) 261 Application specified fields in the service discovery repository 262 and in the search protocol that enable a device with specific 263 application defined characteristics to be selectively discovered 264 by other devices in the network. 266 An ability to set the scope of "the network" to produce bounded 267 service discovery requests matching network resource capabilities. 268 (The scope might not be limited to the LoWPAN, but might contain 269 hosts from the networks the edge routers are attached to. 271 A protocol that is able to differentiate between types of 272 services, such as source, processing, sink as well as 273 commissioning and bootstrapping services and possibly connects 274 matching services to each other. 276 A rich protocol for service discovery requests that wherever 277 possible tries to limit resource usage of the network to support 278 the request while supplying targeted responses. Specifically, 279 this would obviate the need for multicast and would introduce some 280 binary tags etc. rather than string-based descriptions which 281 require too much code to parse and are too chatty. 283 5. Related Standardization Activities 285 6LowApp will need to interface with various other standardization 286 efforts, such as 288 ISA SP100.11a 290 the ZigBee/IP effort 292 the Smart Energy standardization at the IEC 294 UCA International (and OpenSG) 296 Society of Automotive Engineers (SAE) 298 ETSI Machine-to-Machine (M2M) Technical Committee (TC) 300 Efficient XML Interchange (EXI) at the W3C 302 New EU smart grid standardization effort 304 Open Geospatial Consortium (SWE) 306 Device Profile Web Services (DPWS) 308 BACnet: A Data Communication Protocol for Building Automation and 309 Control Networks (ANSI/ASHRAE 135-2008, EN ISO16484-5) 311 As an example, consider the needs of "Smart Grid" Home Area 312 Networking (HAN) Applications. For Smart Grid HAN applications, 313 getting IP connectivity to devices such as thermostats, in-home 314 displays, load control wall plugs, refrigerators and plug-in electric 315 vehicles solves the problem of introducing these devices onto the 316 internet. To fully realize application deployment the following 317 features are needed: 319 A basic framework for reliability as is provided by TCP for most 320 existing application protocols (see Application Protocols above). 322 A basic framework for service discovery (see Supporting Protocols 323 above). 325 Security (see Security Considerations below). 327 Roaming support. Nodes will need to bootstrap in different 328 LoWPANs, e.g., plug-in electric vehicles (PEVs) will need the 329 ability to roam between networks. It is not clear that MobileIP 330 will solve even part of this problem as there may not be a logical 331 place to hold a forwarding registry. There will be relatively 332 many such devices; it is not clear that assuming a static global 333 IP address per car is the right approach. 6LowApp should consider 334 the ZigBee/HomePlug MRD Use Cases, the SAE use cases around PEVs 335 and consider how roaming devices can be accommocated. Also, there 336 is an IEC group (TC 22, Task Group 3) working on a similar 337 solution so that work should be reviewed for requirements. 339 In addition, this is an area where the use of intermediate processing 340 nodes -- sometimes referred to as ALG (Application Layer Gateways -- 341 providing enhanced security, local data processing and storage, 342 provisioning, etc. may be of particular interest. 344 (Another related area is future applications in support of the smart 345 grid, for example "sub-station automation" where new IP sensors and 346 actuators are being developed and for which one may consider the 347 interconnection of existing legacy applications to IP-based 348 applications, beyond IP connectivity.) 350 In addition to a compact, efficient application protocol, the content 351 carried in such a protocol is equally important. XML is not suitable 352 for use with the limited payload sizes available on LoWPANs and for 353 parsing on simple embedded devices. Relevant standardization efforts 354 are being performed which enable the encoding of XML in suitable 355 formats. For example at the W3C, the Efficient XML Interchange (EXI) 356 format has been developed, allowing for XML to be represented in a 357 very compact and machine-parsable format. 359 6. Security Considerations 361 Many LoWPAN applications have strong security requirements. Some of 362 these will need to be solved at the underlying link layer (6LoWPAN 363 devices usually have good support for confidentiality and 364 authentication), many will require solutions at the application layer 365 (possibly using transport layer security). Most devices will benefit 366 from some synergy between the key management mechanisms at these two 367 layers; in any case these mechanisms must be appropriate for highly 368 constrained devices. 370 Possible elements from solution space include: 372 EAP is well-known in the wireless world and appears to be a good 373 framework to standardize on. However, work is needed on open 374 security methods applicable to small footprint devices. 376 For applications wanting to use certificates, enhancements to the 377 current usage of certificates (X.509) and IEEE 802.1X may be 378 needed to support small footprint devices. 380 7. Acknowledgements 382 The authors would like to thank JP Vasseur, Jerry Martocci and Markus 383 Becker for useful input about applications in the Wireless Embedded 384 Internet. 386 8. Informative References 388 [I-D.ietf-6lowpan-hc] 389 Hui, J. and P. Thubert, "Compression Format for IPv6 390 Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-05 391 (work in progress), June 2009. 393 [I-D.ietf-6lowpan-nd] 394 Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. 395 Nordmark, "6LoWPAN Neighbor Discovery", 396 draft-ietf-6lowpan-nd-04 (work in progress), July 2009. 398 [I-D.ietf-6lowpan-routing-requirements] 399 Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 400 Statement and Requirements for 6LoWPAN Routing", 401 draft-ietf-6lowpan-routing-requirements-02 (work in 402 progress), March 2009. 404 [I-D.ietf-6lowpan-usecases] 405 Kim, E., Kaspar, D., Chevrollier, N., and J. Vasseur, 406 "Design and Application Spaces for 6LoWPANs", 407 draft-ietf-6lowpan-usecases-03 (work in progress), 408 July 2009. 410 [I-D.ietf-roll-building-routing-reqs] 411 Martocci, J., Riou, N., Mil, P., and W. Vermeylen, 412 "Building Automation Routing Requirements in Low Power and 413 Lossy Networks", draft-ietf-roll-building-routing-reqs-05 414 (work in progress), February 2009. 416 [I-D.ietf-roll-home-routing-reqs] 417 Porcu, G., "Home Automation Routing Requirements in Low 418 Power and Lossy Networks", 419 draft-ietf-roll-home-routing-reqs-06 (work in progress), 420 November 2008. 422 [I-D.ietf-roll-indus-routing-reqs] 423 Networks, D., Thubert, P., Dwars, S., and T. Phinney, 424 "Industrial Routing Requirements in Low Power and Lossy 425 Networks", draft-ietf-roll-indus-routing-reqs-06 (work in 426 progress), June 2009. 428 [IEEE802.15.4] 429 IEEE Computer Society, "IEEE Std. 802.15.4-2006 (as 430 amended)", 2007. 432 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 433 Shelby, "Performance Enhancing Proxies Intended to 434 Mitigate Link-Related Degradations", RFC 3135, June 2001. 436 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 437 over Low-Power Wireless Personal Area Networks (6LoWPANs): 438 Overview, Assumptions, Problem Statement, and Goals", 439 RFC 4919, August 2007. 441 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 442 "Transmission of IPv6 Packets over IEEE 802.15.4 443 Networks", RFC 4944, September 2007. 445 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 446 "Routing Requirements for Urban Low-Power and Lossy 447 Networks", RFC 5548, May 2009. 449 Authors' Addresses 451 Carsten Bormann 452 Universitaet Bremen TZI 453 Postfach 330440 454 Bremen D-28359 455 Germany 457 Phone: +49-421-218-63921 458 Fax: +49-421-218-7000 459 Email: cabo@tzi.org 461 Don Sturek 462 Consultant, Pacific Gas and Electric 463 77 Beale Street 464 San Francisco, CA 465 USA 467 Phone: +1-619-504-3615 468 Email: d.sturek@att.net 470 Zach Shelby 471 Sensinode 472 Kidekuja 2 473 Vuokatti 88600 474 FINLAND 476 Phone: +358407796297 477 Email: zach@sensinode.com