core K. Li Internet-Draft B. Greevenbosch Intended status: Standards Track Huawei Technologies Expires: April 27, 2015 E. Dijk Philips Research S. Loreto Ericsson October 24, 2014 CoAP Option Extension: Patience draft-li-core-coap-patience-option-05 Abstract CoAP is a RESTful application protocol for constrained nodes and networks. This specification provides a simple extension for CoAP, the Patience option. This option is used by a CoAP client to indicate the maximum time a client is prepared to wait for a response. The CoAP server should try to return the response within the specified time frame. 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." This Internet-Draft will expire on April 27, 2015. Li, et al. Expires April 27, 2015 [Page 1] Internet-Draft CoAP Patience Option October 2014 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 . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Patience Option Extension . . . . . . . . . . . . . . . . . . 3 2.1. Patience Option Definition . . . . . . . . . . . . . . . 3 2.2. Using the Patience Option . . . . . . . . . . . . . . . . 3 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction This specification adds a new Patience option to CoAP [RFC7252]. The main purpose is for the client to inform the server of the preferred time frame for a response. It is used in a request to indicate the client patience in waiting for a response. It then indicates "a response is most useful within the specified time frame". 1.1. Justification It can be useful for the client to indicate that the response is required to be returned within a certain amount of time. For example, the client could require a response within 2 seconds, otherwise the response is not of interest anymore. With this indication of the patience for a response, the client knows how long it should wait for the response, and it needs to keep the state of the request only for the indicated time. After this period, the request will be given up. It can avoid that the server wastes Li, et al. Expires April 27, 2015 [Page 2] Internet-Draft CoAP Patience Option October 2014 resources by sending a response which already exceeds the set patience timeout of the client. If the Patience option is combined with Observe option in a request, it indicates the maximum time an observer is prepared to wait for an initial notification. 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. Patience Option Extension 2.1. Patience Option Definition +-----+---+---+---+---+----------+---------+--------+---------+ | No. | C | U | N | R | Name | Format | Length | Default | +-----+---+---+---+---+----------+---------+--------+---------+ | 28 | | | x | | Patience | integer | 1-2 B | none | +-----+---+---+---+---+----------+---------+--------+---------+ The value of the Patience option is measured in seconds. The range is from 1 second to 2^16 seconds, that is, 65535 seconds, around 18 hours. There is no default value for the Patience option. The Patience option is "elective". It MUST NOT occur more than once. 2.2. Using the Patience Option In the unicast case, this option is used by a CoAP client to indicate the maximum time a client is prepared to wait for a response. The client adds the Patience option to any request for which it is prepared to wait for a response. The client sets the option to the maximum time that it is prepared to wait. The Patience option applies to both a piggy-backed response and a separate response. For a separate response, the patience applies to the actual response, not to the ACK. The ACK should be sent immediately upon receipt of the CON message. TBD: In case a client retransmits a request, the Patience Option value MAY be decreased by an amount of time equivalent to the time since the previous transmission attempt. In case a client did not receive an ACK to a confirmable request and a time interval of at Li, et al. Expires April 27, 2015 [Page 3] Internet-Draft CoAP Patience Option October 2014 least the interval indicated in the Patience Option of the request has passed, the client SHOULD give up the request. The server interprets this option as the maximum time between receipt of the complete request and the time that it begins sending the response. The client will observe a longer time interval between request and response, as network transit and processing by proxies add delays. If timing is critical, the client SHOULD consider the possible delays and choose the value for the option accordingly. The server MAY apply a lower value to the patience timeout based on local policy. A server MAY choose to take longer to produce a response, at the risk that the client is no longer able to use the response. In case that the CoAP message is transmitted through a proxy, the Proxy MAY reduce the value of a Patience option based on a local policy (e.g. to consider the maximum time that an idle connection is kept open by a local NAT or Firewall). A Proxy MAY add a Patience option if none is present. The value in the Patience option MUST NOT be increased or removed. If the client does not receive a response within the indicated response time, the client SHOULD consider the request as failed. If the server can't provide a response within the required time, the server SHOULD discard the request. 3. Example This section gives a short example with a message flow that illustrates the use of the Patience option in a GET request. This example (Figure 1) shows that the client wants to get a response within 60 seconds. Li, et al. Expires April 27, 2015 [Page 4] Internet-Draft CoAP Patience Option October 2014 client server | | | | +-------->| Header: GET (T=CON, Code=1, MID=0x7d38) | GET | Token: 0x53 | | Patience: 60 | | Uri-Path: "temperature" | | |<--------+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38) | 2.05 | Token: 0x53 | | Payload: "22.3 C" | | Figure 1: Patience Option in a unicast request 4. Security Considerations This presents no security considerations beyond those in section 10 of the base CoAP specification [RFC7252]. 5. IANA Considerations The IANA is requested to add the following "CoAP Option Numbers" entry as per Section 12.2 of [RFC7252]. +-----+---+---+---+---+----------+---------------+--------+---------+ | No. | C | U | N | R | Name | Format | Length | Default | +-----+---+---+---+---+----------+---------------+--------+---------+ | 28 | | | x | | Patience | (ref to this | 1-2 B | (none) | | | | | | | | document) | | | +-----+---+---+---+---+----------+---------------+--------+---------+ 6. Acknowledgements The authors of this draft would like to thank the participants of the email discussion on this issue. Thanks to Carsten Bormann, Peter Bigot, Barry Leiba, Linyi Tian, Gengyu Wei for the reviews and discussions. 7. Normative References [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. Li, et al. Expires April 27, 2015 [Page 5] Internet-Draft CoAP Patience Option October 2014 Authors' Addresses Kepeng Li Huawei Technologies Huawei Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P. R. China Email: likepeng@huawei.com Bert Greevenbosch Huawei Technologies Huawei Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P. R. China Email: bert.greevenbosch@huawei.com Esko Dijk Philips Research High Tech Campus 34 Eindhoven The Netherlands Email: esko.dijk@philips.com Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: salvatore.loreto@ericsson.com Li, et al. Expires April 27, 2015 [Page 6]