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