core S. Li Internet-Draft K. Li Intended status: Standards Track Huawei Technologies Expires: April 18, 2015 J. Hoebeke F. Van den Abeele iMinds-IBCN/UGent A. Jara University of Murcia October 15, 2014 Conditional observe in CoAP draft-li-core-conditional-observe-05 Abstract CoAP is a RESTful application protocol for constrained nodes and networks. Through the Observe option, clients can observe changes in the state of resources and obtain a current representation of the last resource state. This document defines two new options for CoAP Observe so that a CoAP client can specify timing conditions when observing a resource on a CoAP server. As a result, the CoAP client is only informed about resource state changes when the timing conditions are met. This offers possibilities to extend network intelligence, enhance scalability, and optimize the lifetime and performance in order to address the requirements from the Constrained Nodes and Networks. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Li, et al. Expires April 18, 2015 [Page 1] Internet-Draft Conditional observe in CoAP October 2014 This Internet-Draft will expire on April 18, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Justification . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conditional Observe Options . . . . . . . . . . . . . . . . . 5 4. Using the Condition Option . . . . . . . . . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction CoAP [RFC7252] is an Application Protocol for Constrained Nodes/ Networks. The observe [I-D.ietf-core-observe] specification describes a protocol design so that a CoAP client and server can use the subject/observer design pattern to establish an observation relationship. When observe is used, the CoAP client will get a notification response whenever the state of the observed resource changed. However, in some scenarios, the CoAP client may only be interested in the state changes of the resource after a specified time interval, to avoid superfluous traffic. This memo defines two new CoAP options "Minimum-Interval" and "Maximum-Interval" that can be used to allow the CoAP client to set conditions for the Li, et al. Expires April 18, 2015 [Page 2] Internet-Draft Conditional observe in CoAP October 2014 observation relationship, and only when such condition is met, the CoAP server will send the notification response with the latest state change. When such a condition fails, the CoAP server does not need to send the notification response. 1.1. Justification A GET request that includes an Observe Option creates an observation relationship. When a server receives such a request, it first serves the request like a GET request without this option and, if the resulting response indicates success, establishes an observation relationship between the client and the target resource. The client is notified of resource state changes by additional responses sent in reply to the GET request to the client. CoAP is used for Constrained Networks, especially used for transporting sensor data. Different sensor equipments have different properties, e.g. different change rates, different response time, etc. resulting in varying clients' interests that differ from mere state changes. As such, when a client wants to collect information from a sensor, it does not want to receive too many notification messages within a short time period, if the state of a server resource changes too often. Also, if the resource's representation does not change for a long time, the client wants to receive notifications in order to make sure that the observe relantionship is still alive. Consider the following example. CLIENT SERVER | | | ------- GET:/temperature, Observe:0 ------> | | | | <------ 2.05 Content, Observe:5 Payload:22 ------- | | | | <------ 2.05 Content, Observe:10 Payload:22.3 ------- | | | | <------ 2.05 Content, Observe:15 Payload:22.6 ------- | | | Figure 1: GET request with observe In this example, the sensor acts as a server, and it collects the resource data every 5 seconds. When the client observes a resource on the server, it will receive a response whenever the server updates the resource, that is to say, mostly every 5 seconds the client will receive a notification response. However, the client might be a Li, et al. Expires April 18, 2015 [Page 3] Internet-Draft Conditional observe in CoAP October 2014 simple constrained device not too sensitive to the resource state change, so it may not want to receive notifications that often. One possible solution could be to alter the sensor's configuration, e.g. to shorten the collecting frequency. However, the sensor should be able to provide services to many other clients, making it hard to find the best configuration that fits all clients' requirements. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Motivation The CoAP Observe Option gives clients the ability to observe changes in the state of resources. An observe relationship is established and whenever the state of the resource changes, the new representation is pushed to the observer. In some cases, the server resource changes too often, while the client does not want to receive notifications that often. The client just wants to receive notifications after a specific time interval. Defining a standardized set of commonly used conditional observations has a number of advantages. In a well-defined way, clients can observe different resources conditionally. At the same time, these resources can clearly announce how they can be observed, facilitating machine processing of this information. Also, intermediaries can process multiple conditional observations, with the goal to alleviate the load on the constrained network and devices. In the absence of such a set of commonly used conditional observations, where every application developer can specify its own mechanisms, these advantages are lost. In [I-D.ietf-core-interfaces], a mechanism is described to provide additional information to the Observe Option through the use of query parameters. It is possible to define a fixed set of query parameters to enable conditional observations. However, many more query parameters can be offered by a resource for different purposes. This complicates the automatic processing of conditional observations. Also embedding the query parameters in the URI encumbers processing at intermediaries. To alleviate this problem, this draft proposes to use CoAP options to specify timing-related conditions, that is, minimum time interval and maximum time interval, for the notifications. Using options ensures a compact representation and well-defined meaning. For resource value related conditions, e.g. larger than, smaller than, another mechanism such as query parameters Li, et al. Expires April 18, 2015 [Page 4] Internet-Draft Conditional observe in CoAP October 2014 can be used to complement the Minimum-Interval and Maximum-Interval Options. 3. Conditional Observe Options +-----+---+---+---+---+-----------------+--------+--------+---------+ | No. | C | U | N | R | Name | Format | Length | Default | +-----+---+---+---+---+-----------------+--------+--------+---------+ | TBD | | x | - | | Minimum-Interval | int | 0-2 B | (none) | | TBD | | x | - | | Maximum-Interval | int | 0-2 B | (none) | +-----+---+---+---+---+-----------------+--------+--------+---------+ C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable Figure 2: Conditional Observe Options This draft defines two condition options for observe, Minimum- Interval and Maximum-Interval. Both options are elective, and Proxy Unsafe (similar to the Observe Option). The Minimum-Interval and Maximum-Interval options can only be present in a GET request message and its response message. They must be used together with the Observe Option, since they extend the meaning of the Observe Option. The Minimum-Interval/Maximum-Interval MUST be included in the first notification message if the conditional observation relationship is created successfully. If the server does not support the Minimum-Interval/Maximum-Interval option contained in the observe request, it will ignore the them. The Minimum-Interval Option indicates the minimum time interval between two notification responses sent from the server, even if the resource representation changes. After sending the previous notification response, the server has to wait for the minimum time interval to expire, before sending the subsequent notification response, if the resource representation changes within the specified minimum time interval. The Maximum-Interval Option indicates that the maximum time interval between two notification responses sent from the server, even if the resource representation does not change. After sending the previous notification response, if the resource representation does not change after the maximum time interval, the server needs to send the same resource representation immediately after timeout of the maximum time interval. This can be used to show the liveness of the server. Basically, a similar procedure as described in the observe draft [I-D.ietf-core-observe] is followed, but extended with additional Li, et al. Expires April 18, 2015 [Page 5] Internet-Draft Conditional observe in CoAP October 2014 behavior by taking the Minimum-Interval and Maximum-Interval Options into account. The exact semantics are described below. The values of the Minimum-Interval and Maximum-Interval Options are measured in seconds. The range is from 1 second to 2^16 seconds, that is, 65256 seconds, around 18 hours. There is no default value for the Minimum-Interval/Maximum-Interval option. The Minimum-Interval Option and Maximum-Interval Option are elective, and may be present separately or together. If both of the options are included in a request, their relationship is "AND", meaning that the server will only send a notification when both conditions are fulfilled. Note that if both options are present, Maximum-Interval option should be greater than or equal to Minimum-Interval option. If the Minimum-Interval Option and Maximum-Interval Option are both present and have the same value, then the server should send notifications periodically, regardless whether the resource representation has changed or not. 4. Using the Condition Option Whenever a client wants to initiate a Conditional Observation relationship, it sends a GET request with both an Observe option and at least one Conditional Observe Option. The Conditional Observe Options represent the minimum and maximum time interval conditions the client wants to apply to the observation relationship. When a server receives such a request, it first services the request in the same way as described in [I-D.ietf-core-observe]. Next, if the server supports the Minimum-Interval or Maximum-Interval option, it analyzes the options to find the condition requested by the client. If the Minimum-Interval/Maximum-Interval option is supported, the relationship is stored and the client is informed about the successful establishment of the conditional relationship. This is done by sending a response containing both the Observe and Minimum-Interval/Maximum-Interval option, which implies that the client has now been added to the list of observers and will only be informed about state changes or resource states satisfying the conditions described in the Minimum-Interval/ Maximum-Interval option. Since the Minimum-Interval/Maximum-Interval option is elective, an observe request that includes the option will automatically fall back to a basic observe request if the server does not support the Minimum-Interval/Maximum-Interval option. This implies that the client will now receive notifications as described in [I-D.ietf-core-observe] and that the client itself is responsible for Li, et al. Expires April 18, 2015 [Page 6] Internet-Draft Conditional observe in CoAP October 2014 processing the resource state in the notifications in order to identify whether the condition of interest is fulfilled or not. Whenever the state of a resource that supports conditional observations changes on the server, the server needs to check the established conditional relationships. Whenever the relationship condition(s) is(are) met, the server sends the notification response to the client that has established the relationship. In case the server is still waiting for a confirmable notification to be acknowledged or the 3 seconds on average for a non-confirmable notification to elapse, it MUST adhere to the behaviour specified in section 4.5 of [I-D.ietf-core-observe]. 5. Examples This section gives some short examples with message flows to illustrate the use of the Minimum-Interval and Maximum-Interval Options in an observe GET request. The following example shows that the client sets the Minimum-Interval Option to 10 seconds, This means that the server shall wait at least 10s between sending notification responses, indicating changes in the state of the resource, to the client. Li, et al. Expires April 18, 2015 [Page 7] Internet-Draft Conditional observe in CoAP October 2014 CLIENT SERVER | | | GET:/temperature,Observe:0,Minimum-Interval:10 ---> 22|0s | | | <------ 2.05 Content,Observe:0,payload:22 | | | | <------ 2.05 Content,Observe:10,payload:22.4 22.4|10s | | | 23|15s | | | <------ 2.05 Content,Observe:20,payload:23.5 23.5|20s | | | 24|25s | | | <------ 2.05 Content,Observe:30,payload:22 22|30s | | | 22|35s | | | 22|90s | | | <------ 2.05 Content,Observe:120,payload:22.2 22.2|120s | | Figure 3: Minimum-Interval Option Usage The next example shows that the client sets the Maximum-Interval Option to 60 seconds. The server will send notifications upon every state change, but will leave maximally 60s between subsequent notifications, even if they do not incur a state change. Li, et al. Expires April 18, 2015 [Page 8] Internet-Draft Conditional observe in CoAP October 2014 CLIENT SERVER | | | GET:/temperature,Observe:0,Maximum-Interval:60 ---> 22|0s | | | <------ 2.05 Content,Observe:0,payload:22 | | | | <------ 2.05 Content,Observe:10,payload:22.4 22.4|10s | | | <------ 2.05 Content,Observe:15,payload:23 23|15s | | | <------ 2.05 Content,Observe:20,payload:23.5 23.5|20s | | | <------ 2.05 Content,Observe:25,payload:24 24|25s | | | <------ 2.05 Content,Observe:30,payload:22 22|30s | | | 22|35s | | | <------ 2.05Content,observe:90,payload:22 22|90s | | | <------ 2.05Content,observe:120,payload:22.2 22.2|120s | | Figure 4: Maximum-Interval Option Usage The next example shows a client that sets both the Minimum-Interval Option and the Maximum-Interval Option to 30 seconds. As a result, the server sends notifications every 30 seconds, independent of whether the resource has changed or not. Li, et al. Expires April 18, 2015 [Page 9] Internet-Draft Conditional observe in CoAP October 2014 CLIENT SERVER | | | GET:/temperature,Observe:0,Minimum:30,Maximum:30 --> 22|0s | | | <------ 2.05 Content,Observe:0,payload:22 | | | | 22.4|10s | | | 23|15s | | | 23.5|20s | | | 24|25s | | | <------ 2.05 Content,Observe:30,payload:22 22|30s | | | <------ 2.05 Content,Observe:60,payload:22 22|60s | | | <------ 2.05 Content,Observe:90,payload:22 22|60s | | | <------ 2.05 Content,Observe:120,payload:22.2 22.2|120s | | Figure 5: Minimum-Interval and Maximum-Interval Options together Further, in [CPSCOM], an evaluation can be found regarding the feasibility of implementing conditional observations on real constrained devices, together with a basic performance comparison between conditional observe (server-filtering) and normal observe in combination with client-side filtering. 6. Security Considerations As the Minimum-Interval and Maximum-Interval options are used together with the Observe option, when it is used it must follow the security considerations as described in Observe draft [I-D.ietf-core-observe]. 7. IANA Considerations This draft adds the following option numbers to the CoAP Option Numbers registry of [RFC7252] Li, et al. Expires April 18, 2015 [Page 10] Internet-Draft Conditional observe in CoAP October 2014 +--------+------------------+----------------+ | Number | Name | Reference | +--------+------------------+----------------+ | TBD | Minimal-Interval | [RFCXXXX] | +--------+------------------+----------------+ | TBD | Maximum-Interval | [RFCXXXX] | +--------+------------------+----------------+ Table 3: Conditional Observe Option Numbers 8. Acknowledgements Thanks to the IoT6 European Project (STREP) of the 7th Framework Program (Grant 288445). Thanks to Zach Shelby, Bert Greevenbosch for the discussions. 9. References 9.1. Normative References [I-D.ietf-core-observe] Hartke, K., "Observing Resources in CoAP", draft-ietf- core-observe-14 (work in progress), June 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. 9.2. Informative References [CPSCOM] Ketema, G., Hoebeke, J., Moerman, I., Demeester, P., Li, Shi., and A. Jara, "Efficiently observing Internet of Things Resources", The 2012 IEEE International Conference on Cyber, Physical and Social Computing November 20-23, 2012, Besancon, France, Novemer 2012. [I-D.bormann-coap-misc] Bormann, C. and K. Hartke, "Miscellaneous additions to CoAP", draft-bormann-coap-misc-13 (work in progress), March 2012. [I-D.ietf-core-interfaces] Shelby, Z. and M. Vial, "CoRE Interfaces", draft-ietf- core-interfaces-01 (work in progress), December 2013. Li, et al. Expires April 18, 2015 [Page 11] Internet-Draft Conditional observe in CoAP October 2014 [I-D.ietf-core-link-format] Shelby, Z., "CoRE Link Format", draft-ietf-core-link- format-14 (work in progress), June 2012. [SENSORS] Castro, M., Jara, A., and A. Skarmeta, "Architecture for Improving Terrestrial Logistics Based on the Web of Things", Sensors 12, no. 5, 6538-6575, 2012, May 2012. Appendix A. Change log Changes in v05 o Simplified to contain only two options: * Minimal Interval * Maximum Interval Changes in v04 o Updated draft to be consistent with observe draft: * (Took request URI into consideration for Cancellation.) * (Explicitly stated that the draft diverts from a MUST NOT defined in the observe draft) * Stated that a server should follow the text from the observe draft for an unacknowledged notification in regards to the transmission of new notifications and the cancellation of existing relationships. * Removed obsolete Pledge and Keep-Alive options due to decoupling the freshness of a representation from whether or not the client is still on the list of observers in observe v08. Instead, rely on server-side initiated CONfirmable messages (as defined in the Observe) for checking the existence of a relationship. o (Switched Reliability flag with Logic flag.) o Updated source endpoint terminology. Changes in v03 o Examples for most condition types o Update the option number according to the new numbering scheme Li, et al. Expires April 18, 2015 [Page 12] Internet-Draft Conditional observe in CoAP October 2014 o Added reference to paper validating implementation on constrained device Changes in v02 o Restructured entire document o Detailed description of the Condition Option and updated format of the Condition Option value o Added more Condition Types o New section on cancellation, updating and existence of conditional relationships o New section on discovery Authors' Addresses Shitao Li Huawei Technologies Huawei Base 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Phone: +86-25-56624157 Email: lishitao@huawei.com Kepeng Li Huawei Technologies Huawei Base Bantian, Longgang Shenzhen, Guangdong 518129 China Phone: +86-755-28970231 Email: likepeng@huawei.com Li, et al. Expires April 18, 2015 [Page 13] Internet-Draft Conditional observe in CoAP October 2014 Jeroen Hoebeke iMinds-IBCN/UGent Department of Information Technology Internet Based Communication Networks and Services (IBCN) Ghent University - iMinds Gaston Crommenlaan 8 bus 201 Ghent B-9050 Belgium Phone: +32-9-3314954 Email: jeroen.hoebeke@intec.ugent.be Floris Van den Abeele iMinds-IBCN/UGent Department of Information Technology Internet Based Communication Networks and Services (IBCN) Ghent University - iMinds Gaston Crommenlaan 8 bus 201 Ghent B-9050 Belgium Phone: +32-9-3314946 Email: floris.vandenabeele@intec.ugent.be Antonio J. Jara University of Murcia Department of Information Technology and Communications Computer Science Faculty Campus de Espinardo Murcia ES-30100 Spain Phone: +34-868-88-8771 Email: jara@um.es Li, et al. Expires April 18, 2015 [Page 14]