core K. Li Internet-Draft B. Greevenbosch Intended status: Standards Track Huawei Technologies Expires: September 27, 2011 March 26, 2011 CoAP Option Extension : Response-Mode draft-li-core-coap-response-mode-option-00 Abstract CoAP is a RESTful application protocol for constrained nodes and networks. Two response modes are defined: Piggy-backed Response and Separate Response. This specification provides a simple extension for CoAP, to indicate in the request the required response mode, and also the required response time. 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 September 27, 2011. Copyright Notice Copyright (c) 2011 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 Li & Greevenbosch Expires September 27, 2011 [Page 1] Internet-Draft CoAP-Response-Mode-Option March 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Justification . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Response-Mode Option Extension . . . . . . . . . . . . . . . . 4 2.1. Response-Mode Option Definition . . . . . . . . . . . . . . 4 2.2. Using the Response-Mode Option . . . . . . . . . . . . . . 5 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Li & Greevenbosch Expires September 27, 2011 [Page 2] Internet-Draft CoAP-Response-Mode-Option March 2011 1. Introduction This specification adds a new option Response-Mode to the CoAP. The main purpose is for the requester to indicate the required response mode: Piggy-backed Response or Separate Response, and also indicate the required response time. 1.1. Justification Currently in the CoAP specification [I-D.ietf-core-coap] , two response modes are defined: o A Piggy-backed Response is included right in a CoAP Acknowledgement (ACK) message that is sent to acknowledge receipt of the Request for this Response. o A Separate Response is sent later in a separate message exchange, when a Confirmable message carrying a Request is acknowledged with an empty message (e.g., because the server doesn't have the answer right away). Currently, it is the server's decision to choose a Piggy-backed Response or Separate Response for a request, also server does not know how long the requester will wait for the response. It is possible that the server returns a Separate Response for a request, but the requester does not want to receive it because the requester has to send another acknowledgement if the Separate Response is a confirmable message. The requester does not know how long it will take to get the response. If the requester does not receive a response within an estimated time, retransmission mechanism will be used as indicated in section 4.1 of CoAP specification [I-D.ietf-core-coap]. This will waste the transmission resource for the requester to repeat sending the requests. Also it is possible that the response exceeds the timeout set by the requester, in this case, the response will be rejected by the requester and the transmission resource and server's processing resource are wasted. A possible use case is that a sensor might send information and then quickly power down, and it can only receive the response during the time before it powers down. The requester should control whether the server is allowed to send a Separate (not Piggy-backed) response. The impact is whether a requester must include the capability of responding to requests (rather than just accepting a response to a request it sent): if so, the requester may need more code/memory to support multiple active transactions and processing incoming requests, and has to stay awake for longer periods. It is useful for the requester to indicate that it is willing to accept a Separate Response or only a Piggy-backed Response can be accepted. With this, the server can generate response according to Li & Greevenbosch Expires September 27, 2011 [Page 3] Internet-Draft CoAP-Response-Mode-Option March 2011 the indication in the request, and avoid the situation that the server may waste resources preparing and sending a response the requester will not be able to process. It is also useful for the requester to indicate that the response is required to be returned within a certain amount of time, for example, please respond within 2 seconds. This applies to both Piggy-backed Response and Separate Response. With this, the requester can keep the state of the request only for the indicate time. After this period, the request will be given up. In this way, the transmission resource can be saved to avoid the retransmission of requests. does not know how long should wait for the response Also it can avoid the situation that a server may waste resources sending a response which already exceeds the set timeout of the requester. 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. Response-Mode Option Extension 2.1. Response-Mode Option Definition +------+-----+----------------+-----------+--------+----------+ | Type | C/E | Name | Data type | Length | Default | +------+-----+----------------+-----------+--------+----------+ | 16 | E | Response-Mode | uint | 0-1 B | | +------+-----+----------------+-----------+--------+----------+ 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |P| T | +-+-+-+-+-+-+-+-+ Piggy-backed. If unset, indicates that a Separate Response MAY be accepted. If set to "1", indicates that a Piggy-backed Response MUST be returned. Time. Indicates the required response time is 2^T milliseconds. The server MUST return the response within the indicated response time. Otherwise, the response will be considered as timeout. As there are seven bits available for T, the minimum response time is 2^0 = 1 Li & Greevenbosch Expires September 27, 2011 [Page 4] Internet-Draft CoAP-Response-Mode-Option March 2011 millisecond and the maximum is 2^(2^7-1) = 2^127 milliseconds. 2.2. Using the Response-Mode Option This option is used for the requester to indicate the required response mode and the required response time. If a Separate Response is desired by the requester, the Token option SHOULD be included in the request. If this option is present in the request, and the length is 0 bytes, that is, no option value, that means, a Separate Response MAY be accepted, and the default SEPARATE_RESPONSE_TIME (2^16=65536 milliseconds are defined in this document) is required. If this option is absent in the request, it is the server's decision to choose a Piggy-backed Response or a Separate Response. The requester and the server will act according to section 4.1 in CoAP specification [I-D.ietf-core-coap]. If the requester does not receive a response within the indicated response time, the requester can consider the request as failed. If the server can't provide response within the required time, a 5.00 (Internal Server Error) [TBD] MUST be returned. This option is not used in the response. This option is "elective". It MUST NOT occur more than once. 3. Examples This section gives a number of short examples with message flows to illustrate the use of Response-Mode option in GET request. The first example (Figure 1) shows that the requester wants to get a Piggy-backed Response within 2048 milliseconds. Li & Greevenbosch Expires September 27, 2011 [Page 5] Internet-Draft CoAP-Response-Mode-Option March 2011 Client Server | | | | +----->| Header: GET (T=CON, Code=1, MID=0x7d38) | GET | Token: 0x53 | | Response-Mode: 10001011 | | Uri-Path: "temperature" | | |<-----+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38) | 2.05 | Token: 0x53 | | Payload: "22.3 C" | | Figure 1: Response-Mode Option for a Piggy-backed Response The first example (Figure 2) shows that the requester is willing to get a Separate Response within 4096 milliseconds. Client Server | | | | +----->| Header: GET (T=CON, Code=1, MID=0x7d38) | GET | Token: 0x53 | | Response-Mode: 00001100 | | Uri-Path: "temperature" | | |<- - -+ Header: (T=ACK, Code=0, MID=0x7d38) | | | | |<-----+ Header: 2.05 Content (T=CON, Code=69, MID=0xad7b) | 2.05 | Token: 0x53 | | Payload: "22.3 C" | | | | +- - ->| Header: (T=ACK, Code=0, MID=0xad7b) | | Figure 2: Response-Mode Option for a Separate Response 4. Protocol Constants This section defines the relevant protocol constants defined in this document: SEPARATE_RESPONSE_TIME 65536 milliseconds Li & Greevenbosch Expires September 27, 2011 [Page 6] Internet-Draft CoAP-Response-Mode-Option March 2011 5. Security Considerations This presents no security considerations beyond those in section 10 of the base CoAP specification [I-D.ietf-core-coap]. 6. IANA Considerations The IANA is requested to add the following Option Number entry. +--------+----------------+----------------+ | Number | Name | Reference | +--------+----------------+----------------+ | 16 | Response-Mode | Section 2 | +--------+----------------+----------------+ 7. Acknowledgements The authors of this draft would like to thank the participants of the email discussion on this issue. Thanks to Peter Bigot, Barry Leiba, Linyi Tian for the initial reviews and discussions. 8. Normative References [I-D.ietf-core-block] Shelby, Z. and C. Bormann, "Blockwise transfers in CoAP", draft-ietf-core-block-02 (work in progress), March 2011. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-05 (work in progress), March 2011. [I-D.ietf-core-link-format] Shelby, Z., "CoRE Link Format", draft-ietf-core-link-format-03 (work in progress), March 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Li & Greevenbosch Expires September 27, 2011 [Page 7] Internet-Draft CoAP-Response-Mode-Option March 2011 Authors' Addresses Kepeng Li Huawei Technologies Huawei Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P. R. China Phone: +86-755-28974289 Email: likepeng@huawei.com Bert Greevenbosch Huawei Technologies Huawei Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P. R. China Phone: +86-755-28978088 Email: bgreeven@huawei.com Li & Greevenbosch Expires September 27, 2011 [Page 8]