idnits 2.17.1 draft-shelby-core-coap-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 20, 2010) is 5119 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-martocci-6lowapp-building-applications-00 == Outdated reference: A later version (-01) exists of draft-moritz-6lowapp-dpws-enhancements-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Z. Shelby 3 Internet-Draft Sensinode 4 Intended status: Informational M. Garrison Stuber 5 Expires: October 22, 2010 Itron 6 D. Sturek 7 Pacific Gas & Electric 8 B. Frank 9 Tridium, Inc 10 R. Kelsey 11 Ember 12 April 20, 2010 14 CoAP Requirements and Features 15 draft-shelby-core-coap-req-01 17 Abstract 19 This document considers the requirements for the design of the 20 Constrained Application Protocol (CoAP). The goal of the document is 21 to provide a basis for protocol design and related discussion. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on October 22, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. CoAP Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 77 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3.1. Energy Applications . . . . . . . . . . . . . . . . . . . . 5 79 3.2. Building Automation . . . . . . . . . . . . . . . . . . . . 6 80 3.3. General M2M Applications . . . . . . . . . . . . . . . . . 7 81 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 84 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 87 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 90 1. Introduction 92 The use of web services on the Internet has become ubiquitous in most 93 applications, and depends on the fundamental Representational State 94 Transfer (REST) architecture of the web. The proposed Constrained 95 RESTful Environments (CoRE) working group aims at realizing the REST 96 architecture in a suitable form for the most constrained nodes (e.g. 97 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 98 6LoWPAN). One of the main goals of CoRE is to design a generic 99 RESTful protocol for the special requirements of this constrained 100 environment, especially considering energy and building automation 101 applications. The result of this work should be a Constrained 102 Application Protocol (CoAP) which easily traslates to HTTP for 103 integration with the web while meeting specialized requirements such 104 as multicast support, very low overhead and simplicity. 106 This document first analyzes the requirements for CoAP from the 107 proposed charter and related application requirement drafts in 108 Section 2. The applicability of these requirements to energy, 109 building automation and general M2M applications is considered in 110 Section 3. 112 2. CoAP Requirements 114 The following requirements for CoAP have been identified in the 115 proposed charter of the working group (Feb 13, 2010 version), in the 116 6lowapp problem statement [I-D.bormann-6lowpan-6lowapp-problem], or 117 in the application specific requirement documents. This section is 118 not meant to introduce new requirements, only to summarize the 119 requirements from other sources. The requirements relevant to CoAP 120 can be summarizes as follows: 122 REQ1: CoRE solutions must be of appropriate complexity for use by 123 nodes have limited code size and limited RAM (e.g. 124 microcontrollers used in low-cost wireless devices typically 125 have on the order of 64-256K of flash and 4-12K of RAM). 126 [charter], [I-D.sturek-6lowapp-smartenergy] 128 REQ2: Protocol overhead and performance must be optimized for 129 constrained networks, which may exhibit extremely limited 130 throughput and a high degree of packet loss. For example, 131 multihop 6LoWPAN networks often exhibit application 132 throughput on the order of tens of kbits/s with a typical 133 payload size of 70-90 octets after transport layer headers. 134 [charter] 136 REQ3: The ability to deal with sleeping nodes. Devices may be 137 powered off at any point in time but periodically "wake up" 138 for brief periods of time. [charter], 139 [I-D.sturek-6lowapp-smartenergy], [I-D.gold-6lowapp-sensei] 141 REQ4: Protocol must support the caching of recent resource 142 requests, along with caching subscriptions to sleeping nodes. 143 [charter] 145 REQ5: Must support the manipulation of simple resources on 146 constrained nodes and networks. The architecture requires 147 push, pull and a notify approach to manipulating resources. 148 CoAP will be able to create, read, update and delete a 149 Resource on a Device. [charter], 150 [I-D.sturek-6lowapp-smartenergy], 151 [I-D.martocci-6lowapp-building-applications], 152 [I-D.gold-6lowapp-sensei] 154 REQ6: The ability to allow a Device to publish a value or event to 155 another Device that has subscribed to be notified of changes, 156 as well as the way for a Device to subscribe to receive 157 publishes from another Device. [charter] 159 REQ7: Must define a mapping from CoAP to a HTTP REST API; this 160 mapping will not depend on a specific application and must be 161 as transparent as possible using standard protocol response 162 and error codes where possible. [charter], 163 [I-D.sturek-6lowapp-smartenergy], [I-D.gold-6lowapp-sensei] 165 REQ8: A definition of how to use CoAP to advertise about or query 166 for a Device's description. This description may include the 167 device name and a list of its Resources, each with a URL, an 168 interface description URI (pointing e.g. to a Web Application 169 Description Language (WADL) document) and an optional name or 170 identifier. The name taxonomy used for this description will 171 be consistent with other IETF work, e.g. 172 draft-cheshire-dnsext-dns-sd. [charter] 174 REQ9: CoAP will support a non-reliable IP multicast message to be 175 sent to a group of Devices to manipulate a resource on all 176 the Devices simultaneously [charter]. The use of multicast 177 to query and advertise descriptions must be supported, along 178 with the support of unicast responses 179 [I-D.sturek-6lowapp-smartenergy]. 181 REQ10: The core CoAP functionality must operate well over UDP and 182 UDP must be implemented on CoAP Devices. There may be 183 optional functions in CoAP (e.g. delivery of larger chunks of 184 data) which if implemented are implemented over TCP. 185 [charter], [I-D.sturek-6lowapp-smartenergy], 186 [I-D.martocci-6lowapp-building-applications] 188 REQ11: Reliability must be possible for unicast application layer 189 messages over UDP [I-D.sturek-6lowapp-smartenergy]. 191 REQ12: Latency times should be mimimized of the Home Area Network 192 (HAN), and ideally a typical exchange should consist of just 193 a single request/response exchange. 194 [I-D.sturek-6lowapp-smartenergy] 196 REQ13: A subset of Internet media types must be supported. 197 [I-D.sturek-6lowapp-smartenergy], [I-D.gold-6lowapp-sensei] 199 REQ14: Consider operational and manageability aspects of the 200 protocol and at a minimum provide a way to tell if a Device 201 is powered on or not. [charter] 203 3. Applicability 205 This sections looks at the applicability of the CoAP features for 206 energy, building automation and other macine-to-machine (M2M) 207 applications. 209 3.1. Energy Applications 211 Rising energy prices, concerns about global warming and energy 212 resource depletion, and societal interest in more ecologically 213 friendly living have resulted in government mandates for Smart Energy 214 solutions. In a Smart Energy environment consumers of energy have 215 direct, immediate access to information about their consumption, and 216 are able to take action based on that information. Smart Energy 217 systems also allow device to device communication to optimize the 218 transport, reliability, and safety of energy delivery systems. While 219 often Smart Energy solutions are electricity-centric, i.e. Smart 220 Grid, gas and water are also subject to the same pressures, and can 221 benefit from the same technology. 223 Smart Energy Transactions typically include the exchange of current 224 consumption information, text messages from providers to consumers, 225 and control signals requesting a reduction in consumption. Advanced 226 features such as billing information, energy prepayment transactions, 227 management of distributed energy resources (e.g. generators and 228 photo-voltaics), and management of electric vehicles are also being 229 developed. 231 Smart Energy benefits from Metcalfe's Law. The more devices that are 232 part of a smart energy network within the home or on the grid, the 233 more valuable it becomes. Showing a consumer how much energy they 234 are using is useful. Combining that with specific information about 235 their major appliances, and enabling them to adjust their consumption 236 based on current pricing and system demand is much much more 237 powerful. To do this however requires a system that is resillient, 238 low cost, and easy to install. In many areas this is being done with 239 systems built around IEEE 802.15.4 radios. In the United States, 240 there are over 30 million electric meters that will be deployed with 241 these radios. These radios will be combined to form a mesh network, 242 enabling Smart Energy communication within the home. The maximum 243 packet size for IEEE 802.15.4 is only 127 bytes. Additionally, there 244 is the well known issue of how TCP manages congestion working sub- 245 optimally over wireless networks. IEEE 802.15.4 is ideal for these 246 applications because of its low cost and its support for battery 247 powered devices; however, it is not as well suited for heavier 248 protocols like HTTP. These technical issues with IEEE 802.15.4 249 networks combined with a desire to facilitate broader compatibility, 250 makes a protocol like CoAP desireable. Its REST architecture will 251 allow seamless compatibility with the rest of the Internet, allowing 252 it to be easily integrated with web browsers and web-based service 253 providers, while at the same time being appropriately sized for the 254 low-cost networks necessary for its success. 256 3.2. Building Automation 258 Building automation applications were analyzed in detail including 259 use cases in [I-D.martocci-6lowapp-building-applications]. Although 260 many of the embedded control solutions for building automation make 261 use of industry-specific application protocols like BACnet over IP, 262 there is a growing use of web services in building monitoring, remote 263 control and IT integration. The OASIS oBIX standard [ref] is one 264 example of the use of web services for the monitoring and 265 interconnection of heterogeneous building systems. Several of the 266 CoAP requirements have been taken from 267 [I-D.martocci-6lowapp-building-applications]. The resulting features 268 should allow for peer-to-peer interactions as well as node-server 269 request/response and push interfactions for monitoring and some 270 control purposes. For building automation control with very strict 271 timing requirements using e.g. multicast, further features may be 272 required on top of CoAP. 274 3.3. General M2M Applications 276 CoAP provides a natural extension of the REST architecture into the 277 domain of constrained nodes and networks, aiming at requirements from 278 automation applications in energy and building automation. A very 279 wide range of machine-to-machine (M2M) applications have similar 280 requirements to those considered in this document, and thus it is 281 foreseen that CoAP may be widely applied in the industry. One 282 standardization group considering a general M2M architecture and API 283 is the ETSI M2M TC, which considers a wide range of applications 284 including energy. Another group developing solutions for general 285 embedded device control is the OASIS Device Proile Web Services 286 (DPWS) group. The consideration of DPWS over 6LoWPAN is available in 287 [I-D.moritz-6lowapp-dpws-enhancements]. 289 4. Conclusions 291 This document analyzed the requirements associated with the design of 292 the foreseen Constrained Application Protocol (CoAP). The identified 293 requirements of CoAP are considered for energy, building automation 294 and M2M applications. This document is meant to serve as a basis for 295 the design of the CoAP protocol and relevant discussion. 297 5. Security Considerations 299 The CoAP protocol will be designed for use with e.g. (D)TLS or 300 object security. A protocol design should consider how integration 301 with these security methods will be done, how to secure the CoAP 302 header and other implications. 304 6. IANA Considerations 306 This draft requires no IANA consideration. 308 7. Acknowledgments 310 Thanks to Cullen Jennings, Guido Moritz, Peter Van Der Stok, Adriano 311 Pezzuto, Lisa Dussealt, Gilbert Clark, Salvatore Loreto, Alexey 312 Melnikov and Bob Dolin for helpful comments and discussions. 314 8. References 315 8.1. Normative References 317 [I-D.gold-6lowapp-sensei] 318 Gold, R., Krco, S., Gluhak, A., and Z. Shelby, "SENSEI 319 6lowapp Requirements", draft-gold-6lowapp-sensei-00 (work 320 in progress), October 2009. 322 [I-D.martocci-6lowapp-building-applications] 323 Martocci, J. and A. Schoofs, "Commercial Building 324 Applications Requirements", 325 draft-martocci-6lowapp-building-applications-00 (work in 326 progress), October 2009. 328 [I-D.sturek-6lowapp-smartenergy] 329 Sturek, D., Shelby, Z., Lohman, D., Stuber, M., and S. 330 Ashton, "Smart Energy Requiements for 6LowApp", 331 draft-sturek-6lowapp-smartenergy-00 (work in progress), 332 October 2009. 334 8.2. Informative References 336 [I-D.bormann-6lowpan-6lowapp-problem] 337 Bormann, C., Sturek, D., and Z. Shelby, "6LowApp: Problem 338 Statement for 6LoWPAN and LLN Application Protocols", 339 draft-bormann-6lowpan-6lowapp-problem-01 (work in 340 progress), July 2009. 342 [I-D.moritz-6lowapp-dpws-enhancements] 343 Moritz, G., "DPWS for 6LoWPAN", 344 draft-moritz-6lowapp-dpws-enhancements-00 (work in 345 progress), December 2009. 347 Authors' Addresses 349 Zach Shelby 350 Sensinode 351 Kidekuja 2 352 Vuokatti 88600 353 FINLAND 355 Phone: +358407796297 356 Email: zach@sensinode.com 357 Michael Garrison Stuber 358 Itron 359 2111 N. Molter Road 360 Liberty Lake, WA 99025 361 U.S.A. 363 Phone: +1.509.891.3441 364 Email: Michael.Stuber@itron.com 366 Don Sturek 367 Pacific Gas & Electric 368 77 Beale Street 369 San Francisco, CA 370 USA 372 Phone: +1-619-504-3615 373 Email: d.sturek@att.net 375 Brian Frank 376 Tridium, Inc 377 Richmond, VA 378 USA 380 Phone: 381 Email: brian.tridium@gmail.com 383 Richard Kelsey 384 Ember 385 47 Farnsworth Street 386 Boston, MA 02210 387 U.S.A. 389 Phone: +1.617.951.1201 390 Email: richard.kelsey@ember.com