idnits 2.17.1 draft-li-core-conditional-observe-05.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2014) is 3482 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 415, but not defined == Unused Reference: 'I-D.bormann-coap-misc' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-link-format' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'SENSORS' is defined on line 462, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-14 == Outdated reference: A later version (-27) exists of draft-bormann-coap-misc-13 == Outdated reference: A later version (-14) exists of draft-ietf-core-interfaces-01 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 core S. Li 3 Internet-Draft K. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 18, 2015 J. Hoebeke 6 F. Van den Abeele 7 iMinds-IBCN/UGent 8 A. Jara 9 University of Murcia 10 October 15, 2014 12 Conditional observe in CoAP 13 draft-li-core-conditional-observe-05 15 Abstract 17 CoAP is a RESTful application protocol for constrained nodes and 18 networks. Through the Observe option, clients can observe changes in 19 the state of resources and obtain a current representation of the 20 last resource state. This document defines two new options for CoAP 21 Observe so that a CoAP client can specify timing conditions when 22 observing a resource on a CoAP server. As a result, the CoAP client 23 is only informed about resource state changes when the timing 24 conditions are met. This offers possibilities to extend network 25 intelligence, enhance scalability, and optimize the lifetime and 26 performance in order to address the requirements from the Constrained 27 Nodes and Networks. 29 Note 31 Discussion and suggestions for improvement are requested, and should 32 be sent to core@ietf.org. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 18, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Justification . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Conditional Observe Options . . . . . . . . . . . . . . . . . 5 72 4. Using the Condition Option . . . . . . . . . . . . . . . . . 6 73 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 9.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 CoAP [RFC7252] is an Application Protocol for Constrained Nodes/ 86 Networks. The observe [I-D.ietf-core-observe] specification 87 describes a protocol design so that a CoAP client and server can use 88 the subject/observer design pattern to establish an observation 89 relationship. When observe is used, the CoAP client will get a 90 notification response whenever the state of the observed resource 91 changed. However, in some scenarios, the CoAP client may only be 92 interested in the state changes of the resource after a specified 93 time interval, to avoid superfluous traffic. This memo defines two 94 new CoAP options "Minimum-Interval" and "Maximum-Interval" that can 95 be used to allow the CoAP client to set conditions for the 96 observation relationship, and only when such condition is met, the 97 CoAP server will send the notification response with the latest state 98 change. When such a condition fails, the CoAP server does not need 99 to send the notification response. 101 1.1. Justification 103 A GET request that includes an Observe Option creates an observation 104 relationship. When a server receives such a request, it first serves 105 the request like a GET request without this option and, if the 106 resulting response indicates success, establishes an observation 107 relationship between the client and the target resource. The client 108 is notified of resource state changes by additional responses sent in 109 reply to the GET request to the client. 111 CoAP is used for Constrained Networks, especially used for 112 transporting sensor data. Different sensor equipments have different 113 properties, e.g. different change rates, different response time, 114 etc. resulting in varying clients' interests that differ from mere 115 state changes. As such, when a client wants to collect information 116 from a sensor, it does not want to receive too many notification 117 messages within a short time period, if the state of a server 118 resource changes too often. Also, if the resource's representation 119 does not change for a long time, the client wants to receive 120 notifications in order to make sure that the observe relantionship is 121 still alive. 123 Consider the following example. 125 CLIENT SERVER 126 | | 127 | ------- GET:/temperature, Observe:0 ------> | 128 | | 129 | <------ 2.05 Content, Observe:5 Payload:22 ------- | 130 | | 131 | <------ 2.05 Content, Observe:10 Payload:22.3 ------- | 132 | | 133 | <------ 2.05 Content, Observe:15 Payload:22.6 ------- | 134 | | 136 Figure 1: GET request with observe 138 In this example, the sensor acts as a server, and it collects the 139 resource data every 5 seconds. When the client observes a resource 140 on the server, it will receive a response whenever the server updates 141 the resource, that is to say, mostly every 5 seconds the client will 142 receive a notification response. However, the client might be a 143 simple constrained device not too sensitive to the resource state 144 change, so it may not want to receive notifications that often. One 145 possible solution could be to alter the sensor's configuration, e.g. 146 to shorten the collecting frequency. However, the sensor should be 147 able to provide services to many other clients, making it hard to 148 find the best configuration that fits all clients' requirements. 150 1.2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 2. Motivation 158 The CoAP Observe Option gives clients the ability to observe changes 159 in the state of resources. An observe relationship is established 160 and whenever the state of the resource changes, the new 161 representation is pushed to the observer. In some cases, the server 162 resource changes too often, while the client does not want to receive 163 notifications that often. The client just wants to receive 164 notifications after a specific time interval. 166 Defining a standardized set of commonly used conditional observations 167 has a number of advantages. In a well-defined way, clients can 168 observe different resources conditionally. At the same time, these 169 resources can clearly announce how they can be observed, facilitating 170 machine processing of this information. Also, intermediaries can 171 process multiple conditional observations, with the goal to alleviate 172 the load on the constrained network and devices. In the absence of 173 such a set of commonly used conditional observations, where every 174 application developer can specify its own mechanisms, these 175 advantages are lost. 177 In [I-D.ietf-core-interfaces], a mechanism is described to provide 178 additional information to the Observe Option through the use of query 179 parameters. It is possible to define a fixed set of query parameters 180 to enable conditional observations. However, many more query 181 parameters can be offered by a resource for different purposes. This 182 complicates the automatic processing of conditional observations. 183 Also embedding the query parameters in the URI encumbers processing 184 at intermediaries. To alleviate this problem, this draft proposes to 185 use CoAP options to specify timing-related conditions, that is, 186 minimum time interval and maximum time interval, for the 187 notifications. Using options ensures a compact representation and 188 well-defined meaning. For resource value related conditions, e.g. 189 larger than, smaller than, another mechanism such as query parameters 190 can be used to complement the Minimum-Interval and Maximum-Interval 191 Options. 193 3. Conditional Observe Options 195 +-----+---+---+---+---+-----------------+--------+--------+---------+ 196 | No. | C | U | N | R | Name | Format | Length | Default | 197 +-----+---+---+---+---+-----------------+--------+--------+---------+ 198 | TBD | | x | - | | Minimum-Interval | int | 0-2 B | (none) | 199 | TBD | | x | - | | Maximum-Interval | int | 0-2 B | (none) | 200 +-----+---+---+---+---+-----------------+--------+--------+---------+ 202 C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable 204 Figure 2: Conditional Observe Options 206 This draft defines two condition options for observe, Minimum- 207 Interval and Maximum-Interval. Both options are elective, and Proxy 208 Unsafe (similar to the Observe Option). 210 The Minimum-Interval and Maximum-Interval options can only be present 211 in a GET request message and its response message. They must be used 212 together with the Observe Option, since they extend the meaning of 213 the Observe Option. The Minimum-Interval/Maximum-Interval MUST be 214 included in the first notification message if the conditional 215 observation relationship is created successfully. If the server does 216 not support the Minimum-Interval/Maximum-Interval option contained in 217 the observe request, it will ignore the them. 219 The Minimum-Interval Option indicates the minimum time interval 220 between two notification responses sent from the server, even if the 221 resource representation changes. After sending the previous 222 notification response, the server has to wait for the minimum time 223 interval to expire, before sending the subsequent notification 224 response, if the resource representation changes within the specified 225 minimum time interval. 227 The Maximum-Interval Option indicates that the maximum time interval 228 between two notification responses sent from the server, even if the 229 resource representation does not change. After sending the previous 230 notification response, if the resource representation does not change 231 after the maximum time interval, the server needs to send the same 232 resource representation immediately after timeout of the maximum time 233 interval. This can be used to show the liveness of the server. 235 Basically, a similar procedure as described in the observe draft 236 [I-D.ietf-core-observe] is followed, but extended with additional 237 behavior by taking the Minimum-Interval and Maximum-Interval Options 238 into account. The exact semantics are described below. 240 The values of the Minimum-Interval and Maximum-Interval Options are 241 measured in seconds. The range is from 1 second to 2^16 seconds, 242 that is, 65256 seconds, around 18 hours. There is no default value 243 for the Minimum-Interval/Maximum-Interval option. 245 The Minimum-Interval Option and Maximum-Interval Option are elective, 246 and may be present separately or together. If both of the options 247 are included in a request, their relationship is "AND", meaning that 248 the server will only send a notification when both conditions are 249 fulfilled. Note that if both options are present, Maximum-Interval 250 option should be greater than or equal to Minimum-Interval option. 251 If the Minimum-Interval Option and Maximum-Interval Option are both 252 present and have the same value, then the server should send 253 notifications periodically, regardless whether the resource 254 representation has changed or not. 256 4. Using the Condition Option 258 Whenever a client wants to initiate a Conditional Observation 259 relationship, it sends a GET request with both an Observe option and 260 at least one Conditional Observe Option. The Conditional Observe 261 Options represent the minimum and maximum time interval conditions 262 the client wants to apply to the observation relationship. 264 When a server receives such a request, it first services the request 265 in the same way as described in [I-D.ietf-core-observe]. Next, if 266 the server supports the Minimum-Interval or Maximum-Interval option, 267 it analyzes the options to find the condition requested by the 268 client. If the Minimum-Interval/Maximum-Interval option is 269 supported, the relationship is stored and the client is informed 270 about the successful establishment of the conditional relationship. 271 This is done by sending a response containing both the Observe and 272 Minimum-Interval/Maximum-Interval option, which implies that the 273 client has now been added to the list of observers and will only be 274 informed about state changes or resource states satisfying the 275 conditions described in the Minimum-Interval/ Maximum-Interval 276 option. 278 Since the Minimum-Interval/Maximum-Interval option is elective, an 279 observe request that includes the option will automatically fall back 280 to a basic observe request if the server does not support the 281 Minimum-Interval/Maximum-Interval option. This implies that the 282 client will now receive notifications as described in 283 [I-D.ietf-core-observe] and that the client itself is responsible for 284 processing the resource state in the notifications in order to 285 identify whether the condition of interest is fulfilled or not. 287 Whenever the state of a resource that supports conditional 288 observations changes on the server, the server needs to check the 289 established conditional relationships. Whenever the relationship 290 condition(s) is(are) met, the server sends the notification response 291 to the client that has established the relationship. In case the 292 server is still waiting for a confirmable notification to be 293 acknowledged or the 3 seconds on average for a non-confirmable 294 notification to elapse, it MUST adhere to the behaviour specified in 295 section 4.5 of [I-D.ietf-core-observe]. 297 5. Examples 299 This section gives some short examples with message flows to 300 illustrate the use of the Minimum-Interval and Maximum-Interval 301 Options in an observe GET request. 303 The following example shows that the client sets the Minimum-Interval 304 Option to 10 seconds, This means that the server shall wait at least 305 10s between sending notification responses, indicating changes in the 306 state of the resource, to the client. 308 CLIENT SERVER 309 | | 310 | GET:/temperature,Observe:0,Minimum-Interval:10 ---> 22|0s 311 | | 312 | <------ 2.05 Content,Observe:0,payload:22 | 313 | | 314 | <------ 2.05 Content,Observe:10,payload:22.4 22.4|10s 315 | | 316 | 23|15s 317 | | 318 | <------ 2.05 Content,Observe:20,payload:23.5 23.5|20s 319 | | 320 | 24|25s 321 | | 322 | <------ 2.05 Content,Observe:30,payload:22 22|30s 323 | | 324 | 22|35s 325 | | 326 | 22|90s 327 | | 328 | <------ 2.05 Content,Observe:120,payload:22.2 22.2|120s 329 | | 331 Figure 3: Minimum-Interval Option Usage 333 The next example shows that the client sets the Maximum-Interval 334 Option to 60 seconds. The server will send notifications upon every 335 state change, but will leave maximally 60s between subsequent 336 notifications, even if they do not incur a state change. 338 CLIENT SERVER 339 | | 340 | GET:/temperature,Observe:0,Maximum-Interval:60 ---> 22|0s 341 | | 342 | <------ 2.05 Content,Observe:0,payload:22 | 343 | | 344 | <------ 2.05 Content,Observe:10,payload:22.4 22.4|10s 345 | | 346 | <------ 2.05 Content,Observe:15,payload:23 23|15s 347 | | 348 | <------ 2.05 Content,Observe:20,payload:23.5 23.5|20s 349 | | 350 | <------ 2.05 Content,Observe:25,payload:24 24|25s 351 | | 352 | <------ 2.05 Content,Observe:30,payload:22 22|30s 353 | | 354 | 22|35s 355 | | 356 | <------ 2.05Content,observe:90,payload:22 22|90s 357 | | 358 | <------ 2.05Content,observe:120,payload:22.2 22.2|120s 359 | | 361 Figure 4: Maximum-Interval Option Usage 363 The next example shows a client that sets both the Minimum-Interval 364 Option and the Maximum-Interval Option to 30 seconds. As a result, 365 the server sends notifications every 30 seconds, independent of 366 whether the resource has changed or not. 368 CLIENT SERVER 369 | | 370 | GET:/temperature,Observe:0,Minimum:30,Maximum:30 --> 22|0s 371 | | 372 | <------ 2.05 Content,Observe:0,payload:22 | 373 | | 374 | 22.4|10s 375 | | 376 | 23|15s 377 | | 378 | 23.5|20s 379 | | 380 | 24|25s 381 | | 382 | <------ 2.05 Content,Observe:30,payload:22 22|30s 383 | | 384 | <------ 2.05 Content,Observe:60,payload:22 22|60s 385 | | 386 | <------ 2.05 Content,Observe:90,payload:22 22|60s 387 | | 388 | <------ 2.05 Content,Observe:120,payload:22.2 22.2|120s 389 | | 391 Figure 5: Minimum-Interval and Maximum-Interval Options together 393 Further, in [CPSCOM], an evaluation can be found regarding the 394 feasibility of implementing conditional observations on real 395 constrained devices, together with a basic performance comparison 396 between conditional observe (server-filtering) and normal observe in 397 combination with client-side filtering. 399 6. Security Considerations 401 As the Minimum-Interval and Maximum-Interval options are used 402 together with the Observe option, when it is used it must follow the 403 security considerations as described in Observe draft 404 [I-D.ietf-core-observe]. 406 7. IANA Considerations 408 This draft adds the following option numbers to the CoAP Option 409 Numbers registry of [RFC7252] 410 +--------+------------------+----------------+ 411 | Number | Name | Reference | 412 +--------+------------------+----------------+ 413 | TBD | Minimal-Interval | [RFCXXXX] | 414 +--------+------------------+----------------+ 415 | TBD | Maximum-Interval | [RFCXXXX] | 416 +--------+------------------+----------------+ 418 Table 3: Conditional Observe Option Numbers 420 8. Acknowledgements 422 Thanks to the IoT6 European Project (STREP) of the 7th Framework 423 Program (Grant 288445). 425 Thanks to Zach Shelby, Bert Greevenbosch for the discussions. 427 9. References 429 9.1. Normative References 431 [I-D.ietf-core-observe] 432 Hartke, K., "Observing Resources in CoAP", draft-ietf- 433 core-observe-14 (work in progress), June 2014. 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 439 Application Protocol (CoAP)", RFC 7252, June 2014. 441 9.2. Informative References 443 [CPSCOM] Ketema, G., Hoebeke, J., Moerman, I., Demeester, P., Li, 444 Shi., and A. Jara, "Efficiently observing Internet of 445 Things Resources", The 2012 IEEE International Conference 446 on Cyber, Physical and Social Computing November 20-23, 447 2012, Besancon, France, Novemer 2012. 449 [I-D.bormann-coap-misc] 450 Bormann, C. and K. Hartke, "Miscellaneous additions to 451 CoAP", draft-bormann-coap-misc-13 (work in progress), 452 March 2012. 454 [I-D.ietf-core-interfaces] 455 Shelby, Z. and M. Vial, "CoRE Interfaces", draft-ietf- 456 core-interfaces-01 (work in progress), December 2013. 458 [I-D.ietf-core-link-format] 459 Shelby, Z., "CoRE Link Format", draft-ietf-core-link- 460 format-14 (work in progress), June 2012. 462 [SENSORS] Castro, M., Jara, A., and A. Skarmeta, "Architecture for 463 Improving Terrestrial Logistics Based on the Web of 464 Things", Sensors 12, no. 5, 6538-6575, 2012, May 2012. 466 Appendix A. Change log 468 Changes in v05 470 o Simplified to contain only two options: 472 * Minimal Interval 474 * Maximum Interval 476 Changes in v04 478 o Updated draft to be consistent with observe draft: 480 * (Took request URI into consideration for Cancellation.) 482 * (Explicitly stated that the draft diverts from a MUST NOT 483 defined in the observe draft) 485 * Stated that a server should follow the text from the observe 486 draft for an unacknowledged notification in regards to the 487 transmission of new notifications and the cancellation of 488 existing relationships. 490 * Removed obsolete Pledge and Keep-Alive options due to 491 decoupling the freshness of a representation from whether or 492 not the client is still on the list of observers in observe 493 v08. Instead, rely on server-side initiated CONfirmable 494 messages (as defined in the Observe) for checking the existence 495 of a relationship. 497 o (Switched Reliability flag with Logic flag.) 499 o Updated source endpoint terminology. 501 Changes in v03 503 o Examples for most condition types 505 o Update the option number according to the new numbering scheme 506 o Added reference to paper validating implementation on constrained 507 device 509 Changes in v02 511 o Restructured entire document 513 o Detailed description of the Condition Option and updated format of 514 the Condition Option value 516 o Added more Condition Types 518 o New section on cancellation, updating and existence of conditional 519 relationships 521 o New section on discovery 523 Authors' Addresses 525 Shitao Li 526 Huawei Technologies 527 Huawei Base 528 101 Software Avenue, Yuhua District 529 Nanjing, Jiangsu 210012 530 China 532 Phone: +86-25-56624157 533 Email: lishitao@huawei.com 535 Kepeng Li 536 Huawei Technologies 537 Huawei Base 538 Bantian, Longgang 539 Shenzhen, Guangdong 518129 540 China 542 Phone: +86-755-28970231 543 Email: likepeng@huawei.com 544 Jeroen Hoebeke 545 iMinds-IBCN/UGent 546 Department of Information Technology 547 Internet Based Communication Networks and Services (IBCN) 548 Ghent University - iMinds 549 Gaston Crommenlaan 8 bus 201 550 Ghent B-9050 551 Belgium 553 Phone: +32-9-3314954 554 Email: jeroen.hoebeke@intec.ugent.be 556 Floris Van den Abeele 557 iMinds-IBCN/UGent 558 Department of Information Technology 559 Internet Based Communication Networks and Services (IBCN) 560 Ghent University - iMinds 561 Gaston Crommenlaan 8 bus 201 562 Ghent B-9050 563 Belgium 565 Phone: +32-9-3314946 566 Email: floris.vandenabeele@intec.ugent.be 568 Antonio J. Jara 569 University of Murcia 570 Department of Information Technology and Communications 571 Computer Science Faculty 572 Campus de Espinardo 573 Murcia ES-30100 574 Spain 576 Phone: +34-868-88-8771 577 Email: jara@um.es