idnits 2.17.1 draft-shelby-6lowapp-coap-00.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 (December 24, 2009) is 5236 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 6lowapp Z. Shelby 3 Internet-Draft Sensinode 4 Intended status: Informational M. Garrison Stuber 5 Expires: June 27, 2010 Itron 6 D. Sturek 7 Pacific Gas & Electric 8 B. Frank 9 Tridium, Inc 10 R. Kelsey 11 Ember 12 December 24, 2009 14 CoAP Feature Analysis 15 draft-shelby-6lowapp-coap-00 17 Abstract 19 This document considers the requirements and resulting features 20 needed for the design of the Constrained Application Protocol (CoAP). 21 Starting from requirements for energy and building automation 22 applications, the basic features are identified along with an 23 analysis of possible realizations. The goal of the document is to 24 provide a basis for protocol design and related discussion. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on June 27, 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. CoAP Requirements . . . . . . . . . . . . . . . . . . . . 3 80 2. CoAP Feature Analysis . . . . . . . . . . . . . . . . . . . . 5 81 2.1. Compact Header . . . . . . . . . . . . . . . . . . . . . . 5 82 2.2. Basic Messages . . . . . . . . . . . . . . . . . . . . . . 6 83 2.3. REST Methods . . . . . . . . . . . . . . . . . . . . . . . 6 84 2.4. Content-type encoding . . . . . . . . . . . . . . . . . . 6 85 2.5. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 2.6. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 2.7. Subscribe/Notify . . . . . . . . . . . . . . . . . . . . . 8 88 2.8. Transport Binding . . . . . . . . . . . . . . . . . . . . 9 89 2.8.1. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 2.8.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 2.9. Resource Discovery . . . . . . . . . . . . . . . . . . . . 10 92 2.10. HTTP Mapping . . . . . . . . . . . . . . . . . . . . . . . 10 93 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 94 3.1. Energy Applications . . . . . . . . . . . . . . . . . . . 10 95 3.2. Building Automation . . . . . . . . . . . . . . . . . . . 11 96 3.3. General M2M Applications . . . . . . . . . . . . . . . . . 12 97 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 98 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 100 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 102 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 103 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 106 1. Introduction 108 The use of web services on the Internet has become ubiquitous in most 109 applications, and depends on the basic REST architecture of the web. 110 The proposed Constrained RESTful Environments (CoRE) working group 111 aims at extending the REST architecture to a suitable form for the 112 most constrained nodes (e.g. 8-bit microcontrollers with limited RAM 113 and ROM) and networks (e.g. 6LoWPAN). One of the main goals of CoRE 114 is to design a generic RESTful protocol for the special requirements 115 of this constrained environment, especially considering energy and 116 building automation applications. The result of this work should be 117 a Constrained Application Protocol (CoAP) which easily traslates to 118 HTTP for integration with the web while meeting specialized 119 requirements such as multicast support, very low overhead and 120 simplicity. 122 This document first analyzes the requirements for CoAP from the 123 proposed charter and related application requirement drafts in 124 Section 1.1. The key features needed for the CoAP protocol are then 125 identified in Section 2. Possible ways of realizing each feature are 126 considered and recommendations made where possible. Finally, the 127 applicability of these features to energy, building automation and 128 general M2M applications is considered in Section 3. 130 1.1. CoAP Requirements 132 Paragraph 1. The following requirements for CoAP have been 133 identified in the proposed charter of the working group, in the 134 6lowapp problem statement [I-D.bormann-6lowpan-6lowapp-problem], or 135 in the application specific requirement documents. The requirements 136 relevant to CoAP are summarizes as follows: 138 REQ1: Nodes have limited code size and limited RAM (typically on 139 the order of 128K flash and 4K of RAM). [charter], 140 [I-D.sturek-6lowapp-smartenergy] 142 REQ2: A header size on the order of 10 bytes, and assumes an 143 underlying network bandwidth of several dozen kbit/s. 144 [charter] 146 REQ3: Ability to deal with sleeping nodes. Devices may be powered 147 off at any point in time but periodically "wake up" for brief 148 periods of time. [charter], [I-D.sturek-6lowapp-smartenergy], 149 [I-D.gold-6lowapp-sensei] 151 REQ4: Protocol must support the caching of recent resource 152 requests, along with caching subscriptions to sleeping nodes. 153 [charter] 155 REQ5: Must support the manipulation of simple resources on 156 constrained nodes and networks. The architecture requires 157 push, pull and a notify approach to manipulating resources. 158 CoAP will be able to set and query a resource on a Device. 159 It will allow a Device to publish a value or event to another 160 Device. [charter], [I-D.sturek-6lowapp-smartenergy], 161 [I-D.martocci-6lowapp-building-applications], 162 [I-D.gold-6lowapp-sensei] 164 REQ6: Must define a mapping from CoAP to a HTTP REST API; this 165 mapping will not depend on a specific application and must be 166 as transparent as possible using standard protocol response 167 and error codes where possible. [charter], 168 [I-D.sturek-6lowapp-smartenergy], [I-D.gold-6lowapp-sensei] 170 REQ7: Each interface profile will define the Resources on the 171 Device that applications can manipulate and what 172 manipulations are possible. CoAP must be able to discover 173 Devices on the CNN and to interrogate them to find out which 174 interface profiles they support. [charter] 176 REQ8: CoAP will support a non-reliable multicast message to be sent 177 to a group of Devices to manipulate a resource on all the 178 Devices simultaneously (roughly within 50 ms of each other) 179 [charter]. The use of multicast for discovery and 180 advertisement must be supported, along with the support of 181 unicast responses [I-D.sturek-6lowapp-smartenergy]. 183 REQ9: The protocol will operate by default over UDP, it may 184 optionally be bound to TCP or other reliable transports. 185 [charter], [I-D.sturek-6lowapp-smartenergy], 186 [I-D.martocci-6lowapp-building-applications] 188 REQ10: Reliability must be provided for application layer messages 189 [I-D.sturek-6lowapp-smartenergy]. Must achieve < 0.01% 190 Application layer errors on all messages assuming a .1% 191 Network layer error rate. 193 REQ11: Latency times should be mimimized of the Home Area Network 194 (HAN), and ideally a typical exchange should consist of just 195 a single request and a single response message. 196 [I-D.sturek-6lowapp-smartenergy] 198 REQ12: Internet media type and transfer encoding type support. 199 [I-D.sturek-6lowapp-smartenergy], [I-D.gold-6lowapp-sensei] 201 2. CoAP Feature Analysis 203 This section introduces the minimum set of features needed to realize 204 CoAP, and looks at the possible options for realizing them. These 205 features are considered in light on the requirements listed in 206 Section 1.1. The goal is to consider the cross-dependencies, 207 benefits and drawbacks of alternatives for realizing CoAP and to 208 narrow down the options where obvious. 210 2.1. Compact Header 212 There is a requirement for a header overhead on the order of 10 bytes 213 with limited complexity due to node limitations. It should be noted 214 that in wireless networks bits transmitted are much more expensive 215 than processing cycles. The following header design options are 216 considered: 218 Fixed approach: The simplest approach is to assume as fixed set of 219 byte-aligned fields. The use of variable length fields should 220 be avoided if possible, one obvious exception being a string 221 URL (see Section 2.5). This results in a simple header that 222 can be represented as a struct and easily parsed/created. The 223 disadvantages are difficult evolvability and the tendency to 224 design missing tranport features on-top of CoAP. 226 Extensible approach: The approach of [I-D.frank-6lowapp-chopan] is 227 to encode HTTP headers as binary tuples, assuming that a large 228 number of optional headers will be needed. A similar approach 229 could be takenin CoAP, giving total header flexibility. The 230 disadvantage is header parsing complexity. 232 Hybrid approach: It is unclear how much extensibility is really 233 required from the headers of CoAP. Some of the fields in the 234 protocol will obviously require a sufficient value space for 235 future extensions, such as for indicating content type. Other 236 headers are clearly optional, such as those related to cache 237 control (see Section 2.6) or even the URL (see Section 2.5). A 238 hybrid approach would be to design a small fixed header, with 239 the ability to include extension headers, such as in ICMP 240 [RFC0792]. 242 Considering the features foreseen by this document, some kind of 243 extensible hybrid approach is recommended. Most features are fixed 244 for messages, whereas only a some are expected to be optional. 246 2.2. Basic Messages 248 It is assumed that basic Request and Response messages will be 249 required by the CoAP protocol. This also provides a natural mapping 250 to HTTP (See Section 2.10) and the response may be useful as an 251 acknowledgement in UDP reliability (See Section 2.8.1). It can be 252 considered that CoAP methods are different kinds of Request messages. 254 2.3. REST Methods 256 The core methods of REST must be supported within CoAP. To minimize 257 confusion with HTTP methods, having their own protocol semantics, in 258 CoAP we call the basic REST methods READ, WRITE, CREATE, DESTROY. 260 Additionally, CoAP must support a light-weight Subscribe/Notify 261 mechanism (see Section 2.7). This may require a new NOTIFY method. 262 The discovery mechanism of CoAP may also require a new method called 263 DISCOVER which has different semantics than a READ (see Section 2.9). 264 In order to maintain compatibility with HTTP, these new messages must 265 be mapped to a standard HTTP method. See Section 2.10 for more about 266 HTTP mapping. 268 2.4. Content-type encoding 270 In order to support hetergenous uses, it is important that CoAP is 271 transparent to the use of different application payloads. In order 272 for the application process receiving a packet to properly parse a 273 payload, its content-type and encoding should be explicitly known 274 from the header (as e.g. with HTTP). The use of typical binary 275 encodings for XML is discussed in [I-D.shelby-6lowapp-encoding], 276 which includes recommendations for header indication. The draft 277 recommends the indication of at least 10 Internet media types (MIME) 278 [RFC2046] and 2 content transfer encodings. 280 It is obvious that string names of Internet media types [RFC2046] are 281 not appropriate for use in the CoAP header. But then how to make 282 this small yet extensible? One possible solution is to simply assign 283 codes to a small subset of common MIME and content transfer encoding 284 types and have IANA maintain that. A field of 16-bits should be 285 sufficient for encoding both media and content transfer encoding 286 types. 288 2.5. URLs 290 The Universal Resource Locator (URL) [RFC3986] is an important 291 feature of the REST architecture, the relative part of the URL 292 indicates which resource on the server is being manipulated. It is 293 surely useful for CoAP to support string URLs, which requires a 294 variable length-value field. Although URLs can be designed for 295 compactness, this still often results in 10s of bytes of overhead. 296 The encoding of of a URL string needs to be considered, as this is 297 becoming increasingly complex. It is recommended that only US-ASCII 298 is supported in URL strings for CoAP as defined in [RFC3986], or even 299 a stricter subset as URL parsing is complex and may result in 300 security problems. 302 Constrained devices are not general purpose web servers, and thus 303 often won't host but a small set of resources with fixed URLs. Thus 304 in addition to string URLs a feature for compressing fixed URLs would 305 be useful. 307 One way of achieving this would be to assign an integer identifier 308 (7-8 bits should be sufficient) to each fixed URL in an off-line 309 interface description (e.g. Web Application Description Langauge 310 (WADL)) or in its profile. This identifier could be encoded in the 311 URL length field instead of the string length. 313 2.6. Caching 315 The cachability of CoAP messages will be important, especially with 316 the sleeping node configurations and power limitations typically 317 found in constrained networks and nodes. What features of 318 cachability are really required and how much energy are we willing to 319 spend on it? Roughly 50% of the HTTP specifications are dedicated to 320 sohpisticated caching. With CoAP we should look at the bare minimum 321 caching feature possible. 323 Before talking about caching solutiongs, we should consider in what 324 scenarios caching will actually be required. The following two 325 scenarios have been identified: 327 o An intermediate CoAP proxy may cache resources and answer READ 328 requests using a cached version. The resource may be cached from 329 previous responses or notifications. This requires at least Max- 330 Age cache control information about each resource. 332 o An intermediate CoAP proxy may cache subscriptions to a sleeping 333 node. This requires at least Max-Age information about the 334 subscription. 336 Three possible approaches have been identified for caching support. 338 In-band approach: One approach is suggested in 339 [I-D.frank-6lowapp-chopan], which analyses the subset of 340 features from HTTP that could be used for simple sensor data 341 purposes. The proposal is that simply using the using the HTTP 342 Age header (for resource age) and Cache-Control header (for 343 max-age). Max-age may also be applied in requests. Both 344 headers make use of a 2-byte value in seconds. The advantage 345 of this approach is that cache control information is easily 346 available from the header. The disadvantage is the header 347 overhead. 349 Out-of-band approach: Here the CoAP protocol would be agnostic to 350 the cachability of the resources it is carrying, instead 351 leaving the definition of cache control parameters to the body 352 of the resources in an application specific way. The 353 disadvantage is that this makes proxies dependent on the 354 application. 356 Discovery approach: In this approach the cache control information 357 for resources is defined off-line in the list of a server's 358 resources. This approach is used e.g. in the SENSEI system 359 [I-D.gold-6lowapp-sensei]. The disadvantage id that the 360 caching is dependent on the profile, which may not be a problem 361 if the cache information is in a universal format (see 362 Section 2.9). 364 Based on the current analysis either the In-band or Profile approach 365 would be reasonable for CoAP considering the requirements. 367 2.7. Subscribe/Notify 369 CoAP is required to integrate a push model for interaction in 370 addition to traditional request/response. Meaning that interested 371 clients could subscribe to a resource (a URL), and receive 372 notifications to a call-back URL of their choice. In its most basic 373 form a notification would be sent each time the resource changes. 374 There are many issues to consider including managing subscription 375 leasing and timeouts, how to batch multiple changes and how to tune 376 notify times. Before considering the details, there are a few 377 general general models possible for realizing the Subscribe/Notify 378 mechanism: 380 Resource: Subscribe is realized using CREATE on a well known 381 resource (e.g. /subsribe) with the URL of the resource of 382 interest and a URL call-back in the body). Notifications would 383 be made using a NOTIFY message to the call-back URL. Likewise, 384 de-subscribe is realized using DESTROY on the same well known 385 resource with the URL in the body. Notifications would cease 386 after the DESTROY. 388 Watch: This method would require a CREATE to a new URI to "create" a 389 new watch resource. WRITE is then used to add/remove a set of 390 URIs being "watched" along with call-backs. 392 2.8. Transport Binding 394 The CoAP protocol will operate by default over UDP and it may 395 optionally be bound to TCP or other reliable transports. In this 396 section we look at the issues regarding these bindings. 398 2.8.1. UDP 400 The goal of binding CoAP to UDP is to provide the bare minimum 401 features for the protocol to operate over UDP, going nowhere near 402 trying to re-create the full feature set of TCP. The bare minimum 403 features required would be: 405 o Stop-and-wait would be sufficient for reliability. A simple 406 response message itself would suffice as an acknowledgement with 407 retransmission support. Not all requests require reliability, 408 thus this should be optional. Performance is not the key here and 409 for more sophisticated reliability and flow control TCP can be 410 used. 412 o A sequence number (transaction ID) is needed to match responses to 413 open requests and would be generated by the client. A 12-16 bit 414 unsigned interger would be sufficient. [I-D.frank-6lowapp-chopan] 415 also considered this solution. 417 o Multicast support. Providing reliability with a multicast 418 destination address would be very complex. Therefore the goal is 419 to provide non-reliable multicast service. In many cases there 420 may not be a response to a multi-cast message. A multicast 421 command might result in an action being taken at a device, but no 422 response being sent. Therefore a multicast request may be 423 answered with a unicast response, however without reliability 424 (retransmission e.g.). 426 2.8.2. TCP 428 The CoAP protocol also has the goal of defining a TCP binding. As 429 TCP provides a reliable stream this binding does not require anything 430 special from the CoAP protcol design. The same basic messages could 431 be applied over TCP without stop-and-wait. A transaction ID should 432 still be used over TCP. 434 2.9. Resource Discovery 436 CoAP is required to support the discovery of resources offered by 437 CoAP servers. In order to achieve this, the protocol would need to 438 suport multicast with optional responses for discovery (over UDP), 439 along with unicast requests and posting of profiles (over UDP or 440 TCP). A well-known resource (/profile) could be used to enable 441 profile discovery through a new DISCOVER method along with profile 442 sending on an optional broker with a CREATE or modification with a 443 WRITE to /profile. The response to a DISCOVER message would include 444 a list of resource URLs available, or those matched if the DISCOVER 445 has a body with one or more URLs. Such a resource list could include 446 optional information such as the URL to a description of the 447 interface. 449 Section 2.6 discusses different caching models. If caching would be 450 realized using the Profile model, then the resource list would need 451 to indicate at least the Max-Age of each resource. 453 2.10. HTTP Mapping 455 It shall be possible to map from CoAP directly to HTTP, CoAP however 456 only offers a subset of the HTTP protocol features. As a result, 457 programs implementing translation between HTTP and CoAP must either 458 implement other HTTP 1.1 commands on behalf of the CoAP nodes (e.g. 459 LINK, TRACE, OPTIONS), or must reject such request. The primary 460 responsibility of a program translating between HTTP and CoAP is to 461 rewrite the headers, translating between the highly optimized CoAP 462 headers and plain text HTTP headers. It must also manage/maintain 463 TCP sessions necessary for HTTP. Depending on how some of the 464 features of CoAP are realized, the mapping may also need to make 465 further translations for subscription or caching. 467 3. Applicability 469 This sections looks at the applicability of the CoAP features for 470 energy, building automation and other macine-to-machine (M2M) 471 applications. 473 3.1. Energy Applications 475 Rising energy prices, concerns about global warming and energy 476 resource depletion, and societal interest in more ecologically 477 friendly living have resulted in government mandates for Smart Energy 478 solutions. In a Smart Energy environment consumers of energy have 479 direct, immediate access to information about their consumption, and 480 are able to take action based on that information. Smart Energy 481 systems also allow device to device communication to optimize the 482 transport, reliability, and safety of energy delivery systems. While 483 often Smart Energy solutions are electricity-centric, i.e. Smart 484 Grid, gas and water are also subject to the same pressures, and can 485 benefit from the same technology. 487 Smart Energy Transactions typically include the exchange of current 488 consumption information, text messages from providers to consumers, 489 and control signals requesting a reduction in consumption. Advanced 490 features such as billing information, energy prepayment transactions, 491 management of distributed energy resources (e.g. generators and 492 photo-voltaics), and management of electric vehicles are also being 493 developed. 495 Smart Energy benefits from Metcalfe's Law. The more devices that are 496 part of a smart energy network within the home or on the grid, the 497 more valuable it becomes. Showing a consumer how much energy they 498 are using is useful. Combining that with specific information about 499 their major appliances, and enabling them to adjust their consumption 500 based on current pricing and system demand is much much more 501 powerful. To do this however requires a system that is resillient, 502 low cost, and easy to install. In many areas this is being done with 503 systems built around IEEE 802.15.4 radios. In the United States, 504 there are over 30 million electric meters that will be deployed with 505 these radios. These radios will be combined to form a mesh network, 506 enabling Smart Energy communication within the home. The maximum 507 packet size for IEEE 802.15.4 is only 127 bytes. Additionally, there 508 is the well known issue of how TCP manages congestion working sub- 509 optimally over wireless networks. IEEE 802.15.4 is ideal for these 510 applications because of its low cost and its support for battery 511 powered devices; however, it is not as well suited for heavier 512 protocols like HTTP. These technical issues with IEEE 802.15.4 513 networks combined with a desire to facilitate broader compatibility, 514 makes a protocol like CoAP desireable. Its REST architecture will 515 allow seamless compatibility with the rest of the Internet, allowing 516 it to be easily integrated with web browsers and web-based service 517 providers, while at the same time being appropriately sized for the 518 low-cost networks necessary for its success. 520 3.2. Building Automation 522 Building automation applications were analyzed in detail including 523 use cases in [I-D.martocci-6lowapp-building-applications]. Although 524 many of the embedded control solutions for building automation make 525 use of industry-specific application protocols like BACnet over IP, 526 there is a growing use of web services in building monitoring, remote 527 control and IT integration. The OASIS oBIX standard [ref] is one 528 example of the use of web services for the monitoring and 529 interconnection of heterogeneous building systems. Several of the 530 CoAP requirements have been taken from 531 [I-D.martocci-6lowapp-building-applications]. The resulting features 532 should allow for peer-to-peer interactions as well as node-server 533 request/response and push interfactions for monitoring and some 534 control purposes. For building automation control with very strict 535 timing requirements using e.g. multicast, further features may be 536 required on top of CoAP. 538 3.3. General M2M Applications 540 CoAP provides a natural extension of the REST architecture into the 541 domain of constrained nodes and networks, aiming at requirements from 542 automation applications in energy and building automation. A very 543 wide range of machine-to-machine (M2M) applications have similar 544 requirements to those considered in this document, and thus it is 545 foreseen that CoAP may be widely applied in the industry. One 546 standardization group considering a general M2M architecture and API 547 is the ETSI M2M TC [ref], which considers a wide range of 548 applications including energy. Another group developing solutions 549 for general embedded device control is the OASIS Device Proile Web 550 Services (DPWS) group. The consideration of DPWS over 6LoWPAN is 551 available in [I-D.moritz-6lowapp-dpws-enhancements]. 553 4. Conclusions 555 This document analyzed the requirements associated with the design of 556 the foreseen Constrained Application Protocol (CoAP). Based on these 557 requirements a list of minumum features was analyzed along with 558 different options for realizing them. If possible a recommendation 559 was also made where obvious. Finally, the identified features of 560 CoAP are considered for energy, building automation and M2M 561 applications. This document is meant to serve as a basis for the 562 design of the CoAP protocol and relevant discussion. 564 CoAP is proposed as a transport agnostic extension of REST for 565 deployment in confined computing environments. The intent is to 566 align CoAP with HTTP wherever possible to leverage the web services 567 computing environment already in place. 569 Whereas REST envisions just 4 primitives (READ, SET, CREATE and 570 DESTROY), CoAP proposes to extend this paradigm with a NOTIFY 571 primitive to enable publish/subscribe along with a DISCOVER primitive 572 to support multicast discovery of services denoted by URL. The main 573 architectural difference between READ and the new discovery primitive 574 is the requirement to not respond if the URL is not present on a 575 local device. 577 Finally, CoAP seeks to preserve the caching facilities of HTTP and 578 extend that capability for power saving devices that are not always 579 active on the network. 581 5. Security Considerations 583 Some of the features considered in this document will need further 584 security considerations during a protocol design. For example the 585 use of string URLs may have entail security risks due to complex 586 processing on limited microcontroller implementations. 588 The CoAP protocol will be designed for use with (D)TLS or object 589 security. A protocol design should consider how integration with 590 these security methods will be done, how to secure the CoAP header 591 and other implications. 593 6. IANA Considerations 595 This draft requires no IANA consideration. 597 7. Acknowledgments 599 Thanks to Cullen Jennings for helpful comments and discussions. 601 8. References 603 8.1. Normative References 605 [I-D.frank-6lowapp-chopan] 606 Frank, B., "Chopan - Compressed HTTP Over PANs", 607 draft-frank-6lowapp-chopan-00 (work in progress), 608 September 2009. 610 [I-D.gold-6lowapp-sensei] 611 Gold, R., Krco, S., Gluhak, A., and Z. Shelby, "SENSEI 612 6lowapp Requirements", draft-gold-6lowapp-sensei-00 (work 613 in progress), October 2009. 615 [I-D.martocci-6lowapp-building-applications] 616 Martocci, J. and A. Schoofs, "Commercial Building 617 Applications Requirements", 618 draft-martocci-6lowapp-building-applications-00 (work in 619 progress), October 2009. 621 [I-D.shelby-6lowapp-encoding] 622 Shelby, Z., Luimula, M., and D. Peintner, "Efficient XML 623 Encoding and 6LowApp", draft-shelby-6lowapp-encoding-00 624 (work in progress), October 2009. 626 [I-D.sturek-6lowapp-smartenergy] 627 Sturek, D., Shelby, Z., Lohman, D., Stuber, M., and S. 628 Ashton, "Smart Energy Requiements for 6LowApp", 629 draft-sturek-6lowapp-smartenergy-00 (work in progress), 630 October 2009. 632 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 633 Extensions (MIME) Part Two: Media Types", RFC 2046, 634 November 1996. 636 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 637 Resource Identifier (URI): Generic Syntax", STD 66, 638 RFC 3986, January 2005. 640 8.2. Informative References 642 [I-D.bormann-6lowpan-6lowapp-problem] 643 Bormann, C., Sturek, D., and Z. Shelby, "6LowApp: Problem 644 Statement for 6LoWPAN and LLN Application Protocols", 645 draft-bormann-6lowpan-6lowapp-problem-01 (work in 646 progress), July 2009. 648 [I-D.moritz-6lowapp-dpws-enhancements] 649 Moritz, G., "DPWS for 6LoWPAN", 650 draft-moritz-6lowapp-dpws-enhancements-00 (work in 651 progress), December 2009. 653 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 654 RFC 792, September 1981. 656 Authors' Addresses 658 Zach Shelby 659 Sensinode 660 Kidekuja 2 661 Vuokatti 88600 662 FINLAND 664 Phone: +358407796297 665 Email: zach@sensinode.com 666 Michael Garrison Stuber 667 Itron 668 2111 N. Molter Road 669 Liberty Lake, WA 99025 670 U.S.A. 672 Phone: +1.509.891.3441 673 Email: Michael.Stuber@itron.com 675 Don Sturek 676 Pacific Gas & Electric 677 77 Beale Street 678 San Francisco, CA 679 USA 681 Phone: +1-619-504-3615 682 Email: d.sturek@att.net 684 Brian Frank 685 Tridium, Inc 686 Richmond, VA 687 USA 689 Phone: 690 Email: brian.tridium@gmail.com 692 Richard Kelsey 693 Ember 694 47 Farnsworth Street 695 Boston, MA 02210 696 U.S.A. 698 Phone: +1.617.951.1201 699 Email: richard.kelsey@ember.com