summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7967.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7967.txt')
-rw-r--r--doc/rfc/rfc7967.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc7967.txt b/doc/rfc/rfc7967.txt
new file mode 100644
index 0000000..79d2422
--- /dev/null
+++ b/doc/rfc/rfc7967.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Independent Submission A. Bhattacharyya
+Request for Comments: 7967 S. Bandyopadhyay
+Category: Informational A. Pal
+ISSN: 2070-1721 T. Bose
+ Tata Consultancy Services Ltd.
+ August 2016
+
+
+ Constrained Application Protocol (CoAP) Option for No Server Response
+
+Abstract
+
+ There can be machine-to-machine (M2M) scenarios where server
+ responses to client requests are redundant. This kind of open-loop
+ exchange (with no response path from the server to the client) may be
+ desired to minimize resource consumption in constrained systems while
+ updating many resources simultaneously or performing high-frequency
+ updates. CoAP already provides Non-confirmable (NON) messages that
+ are not acknowledged by the recipient. However, the request/response
+ semantics still require the server to respond with a status code
+ indicating "the result of the attempt to understand and satisfy the
+ request", per RFC 7252.
+
+ This specification introduces a CoAP option called 'No-Response'.
+ Using this option, the client can explicitly express to the server
+ its disinterest in all responses against the particular request.
+ This option also provides granular control to enable expression of
+ disinterest to a particular response class or a combination of
+ response classes. The server MAY decide to suppress the response by
+ not transmitting it back to the client according to the value of the
+ No-Response option in the request. This option may be effective for
+ both unicast and multicast requests. This document also discusses a
+ few examples of applications that benefit from this option.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al. Informational [Page 1]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This is a contribution to the RFC Series, independently of any other
+ RFC stream. The RFC Editor has chosen to publish this document at
+ its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7967.
+
+Copyright Notice
+
+ Copyright (c) 2016 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al. Informational [Page 2]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Potential Benefits .........................................4
+ 1.2. Terminology ................................................4
+ 2. Option Definition ...............................................5
+ 2.1. Granular Control over Response Suppression .................5
+ 2.2. Method-Specific Applicability Considerations ...............8
+ 3. Miscellaneous Aspects ...........................................9
+ 3.1. Reusing Tokens .............................................9
+ 3.2. Taking Care of Congestion Control and Server-Side
+ Flow Control ..............................................10
+ 3.3. Considerations regarding Caching of Responses .............11
+ 3.4. Handling the No-Response Option for a HTTP-to-CoAP
+ Reverse Proxy .............................................11
+ 4. Application Scenarios ..........................................12
+ 4.1. Frequent Update of Geolocation from Vehicles to
+ Backend Server ............................................12
+ 4.1.1. Using No-Response with PUT .........................13
+ 4.1.2. Using No-Response with POST ........................14
+ 4.1.2.1. POST Updating a Fixed Target Resource .....14
+ 4.1.2.2. POST Updating through Query String ........15
+ 4.2. Multicasting Actuation Command from a Handheld Device
+ to a Group of Appliances ..................................15
+ 4.2.1. Using Granular Response Suppression ................16
+ 5. IANA Considerations ............................................16
+ 6. Security Considerations ........................................16
+ 7. References .....................................................16
+ 7.1. Normative References ......................................16
+ 7.2. Informative References ....................................17
+ Acknowledgments ...................................................18
+ Authors' Addresses ................................................18
+
+1. Introduction
+
+ This specification defines a new option for the Constrained
+ Application Protocol (CoAP) [RFC7252] called 'No-Response'. This
+ option enables clients to explicitly express their disinterest in
+ receiving responses back from the server. The disinterest can be
+ expressed at the granularity of response classes (e.g., 2.xx) or a
+ combination of classes (e.g., 2.xx and 5.xx). By default, this
+ option indicates interest in all response classes. The server MAY
+ decide to suppress the response by not transmitting it back to the
+ client according to the value of the No-Response option in the
+ request.
+
+
+
+
+
+
+Bhattacharyya, et al. Informational [Page 3]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+ Along with the technical details, this document presents some
+ practical application scenarios that highlight the usefulness of this
+ option. [ITS-LIGHT] and [CoAP-ADAPT] contain the background research
+ for this document.
+
+ In this document, when it is mentioned that a request from a client
+ is with No-Response, the intended meaning is that the client
+ expresses its disinterest for all or some selected classes of
+ responses.
+
+1.1. Potential Benefits
+
+ The use of the No-Response option should be driven by typical
+ application requirements and, particularly, characteristics of the
+ information to be updated. If this option is opportunistically used
+ in a fitting M2M application, then the concerned system may benefit
+ in the following aspects. (However, note that this option is
+ elective, and servers can simply ignore the preference expressed by
+ the client.)
+
+ * Reduction in network congestion due to effective reduction of
+ the overall traffic.
+
+ * Reduction in server-side load by relieving the server from
+ responding to requests for which responses are not necessary.
+
+ * Reduction in battery consumption at the constrained
+ endpoint(s).
+
+ * Reduction in overall communication cost.
+
+1.2. Terminology
+
+ The terms used in this document are in conformance with those defined
+ in [RFC7252].
+
+ 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].
+
+
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al. Informational [Page 4]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+2. Option Definition
+
+ The properties of the No-Response option are given in Table 1. In
+ this table, the C, U, N, and R columns indicate the properties
+ Critical, Unsafe, NoCacheKey, and Repeatable, respectively.
+
+ +--------+---+---+---+---+-------------+--------+--------+---------+
+ | Number | C | U | N | R | Name | Format | Length | Default |
+ +--------+---+---+---+---+-------------+--------+--------+---------+
+ | 258 | | X | - | | No-Response | uint | 0-1 | 0 |
+ +--------+---+---+---+---+-------------+--------+--------+---------+
+
+ Table 1: Option Properties
+
+ This option is a request option. It is elective and not repeatable.
+ This option is Unsafe-to-Forward, as the intermediary MUST know how
+ to interpret this option. Otherwise, the intermediary (without
+ knowledge about the special unidirectional nature of the request)
+ would wait for responses.
+
+ Note: Since CoAP maintains a clear separation between the
+ request/response and the message sub-layer, this option does not
+ have any dependency on the type of message
+ (Confirmable/Non-confirmable). So, even the absence of a message
+ sub-layer (e.g., CoAP over TCP [CoAP-TCP-TLS]) should have no
+ effect on the interpretation of this option. However, considering
+ the CoAP-over-UDP scenario [RFC7252], NON messages are best suited
+ to this option because of the expected benefits. Using
+ No-Response with NON messages gets rid of any kind of reverse
+ traffic, and the interaction becomes completely open loop.
+
+ Using this option with CON requests may not serve the desired
+ purpose if piggybacked responses are triggered. But, if the
+ server responds with a separate response (which, perhaps, the
+ client does not care about), then this option can be useful.
+ Suppressing the separate response reduces traffic by one
+ additional CoAP message in this case.
+
+ This option contains values to indicate disinterest in all or a
+ particular class or combination of classes of responses as described
+ in Section 2.1.
+
+2.1. Granular Control over Response Suppression
+
+ This option enables granular control over response suppression by
+ allowing the client to express its disinterest in a typical class or
+ combination of classes of responses. For example, a client may
+ explicitly tell the receiver that no response is required unless
+
+
+
+Bhattacharyya, et al. Informational [Page 5]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+ something 'bad' happens and a response of class 4.xx or 5.xx is to be
+ fed back to the client. No response of the class 2.xx is required in
+ such case.
+
+ Note: Section 2.7 of [RFC7390] describes a scheme where a server in
+ the multicast group may decide on its own to suppress responses
+ for group communication with granular control. The client does
+ not have any knowledge about that. However, on the other hand,
+ the No-Response option enables the client to explicitly inform the
+ servers about its disinterest in responses. Such explicit control
+ on the client side may be helpful for debugging network resources.
+ An example scenario is described in Section 4.2.1.
+
+ The server MUST send back responses of the classes for which the
+ client has not expressed any disinterest. There may be instances
+ where a server, on its own, decides to suppress responses. An
+ example is suppression of responses by multicast servers as described
+ in Section 2.7 of [RFC7390]. If such a server receives a request
+ with a No-Response option showing 'interest' in specific response
+ classes (i.e., not expressing disinterest for these options), then
+ any default behavior of suppressing responses, if present, MUST be
+ overridden to deliver those responses that are of interest to the
+ client.
+
+ So, for example, suppose a multicast server suppresses all responses
+ by default and receives a request with a No-Response option
+ expressing disinterest in 2.xx (success) responses only. Note that
+ the option value naturally expresses interest in error responses 4.xx
+ and 5.xx in this case. Thus, the server must send back a response if
+ the concerned request caused an error.
+
+ The option value is defined as a bit map (Table 2) to achieve
+ granular suppression. Its length can be 0 bytes (empty) or 1 byte.
+
+ +-------+-----------------------+-----------------------------------+
+ | Value | Binary Representation | Description |
+ +-------+-----------------------+-----------------------------------+
+ | 0 | <empty> | Interested in all responses. |
+ +-------+-----------------------+-----------------------------------+
+ | 2 | 00000010 | Not interested in 2.xx responses. |
+ +-------+-----------------------+-----------------------------------+
+ | 8 | 00001000 | Not interested in 4.xx responses. |
+ +-------+-----------------------+-----------------------------------+
+ | 16 | 00010000 | Not interested in 5.xx responses. |
+ +-------+-----------------------+-----------------------------------+
+
+ Table 2: Option Values
+
+
+
+
+Bhattacharyya, et al. Informational [Page 6]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+ The conventions used in deciding the option values are:
+
+ 1. To suppress an individual class: Set bit number (n-1) starting
+ from the least significant bit (bit number 0) to suppress all
+ responses belonging to class n.xx. So,
+
+ option value to suppress n.xx class = 2**(n-1)
+
+ 2. To suppress a combination of classes: Set each corresponding bit
+ according to point 1 above. Example: The option value will be 18
+ (binary: 00010010) to suppress both 2.xx and 5.xx responses.
+ This is essentially bitwise OR of the corresponding individual
+ values for suppressing 2.xx and 5.xx. The "CoAP Response Codes"
+ registry (see Section 12.1.2 of [RFC7252]) defines 2.xx, 4.xx,
+ and 5.xx responses. So, an option value of 26 (binary: 00011010)
+ will request to suppress all response codes defined in [RFC7252].
+
+ Note: When No-Response is used with value 26 in a request, the client
+ endpoint SHOULD cease listening to response(s) to the particular
+ request. On the other hand, showing interest in at least one
+ class of response means that the client endpoint can no longer
+ completely cease listening activity and must be configured to
+ listen during some application specific time-out period for the
+ particular request. The client endpoint never knows whether the
+ present request will be a success or a failure. Thus, for
+ example, if the client decides to open up the response for errors
+ (4.xx and 5.xx), then it has to wait for the entire time-out
+ period -- even for the instances where the request is successful
+ (and the server is not supposed to send back a response). Note
+ that in this context there may be situations when the response to
+ errors might get lost. In such a situation, the client would wait
+ during the time-out period but would not receive any response.
+ However, this should not give the client the impression that the
+ request was necessarily successful. In other words, in this case,
+ the client cannot distinguish between response suppression and
+ message loss. The application designer needs to tackle this
+ situation. For example, while performing frequent updates, the
+ client may strategically interweave requests without No-Response
+ option into a series of requests with No-Response to check
+ periodically that things are fine at the server end and the server
+ is actively responding.
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al. Informational [Page 7]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+2.2. Method-Specific Applicability Considerations
+
+ The following table provides a ready reference on the possible
+ applicability of this option with four REST methods. This table is
+ for the type of possible interactions foreseen at the time of
+ preparing this specification. The key words from RFC 2119 such as
+ "SHOULD NOT", etc., deliberately have not been used in this table
+ because it only contains suggestions.
+
+ +-------------+----------------------------------------------------+
+ | Method Name | Remarks on Applicability |
+ +-------------+----------------------------------------------------+
+ | | This should not be used with a conventional GET |
+ | | request when the client requests the contents |
+ | | of a resource. However, this option may be useful |
+ | | for exceptional cases where GET requests have side |
+ | GET | effects. For instance, the proactive cancellation |
+ | | procedure for observing a request [RFC7641] |
+ | | requires a client to issue a GET request with the |
+ | | Observe option set to 1 ('deregister'). If it is |
+ | | more efficient to use this deregistration instead |
+ | | of reactive cancellation (rejecting the next |
+ | | notification with RST), the client MAY express its |
+ | | disinterest in the response to such a GET request. |
+ +-------------+----------------------------------------------------+
+ | | Suitable for frequent updates (particularly in NON |
+ | | messages) on existing resources. Might not be |
+ | | useful when PUT is used to create a new resource, |
+ | | as it may be important for the client to know that |
+ | PUT | the resource creation was actually successful in |
+ | | order to carry out future actions. Also, it may be|
+ | | important to ensure that a resource was actually |
+ | | created rather than updating an existing resource. |
+ +-------------+----------------------------------------------------+
+ | | If POST is used to update a target resource, |
+ | | then No-Response can be used in the same manner as |
+ | | in PUT. This option may also be useful while |
+ | POST | updating through query strings rather than updating|
+ | | a fixed target resource (see Section 4.1.2.2 for an|
+ | | example). |
+ +-------------+----------------------------------------------------+
+ | | Deletion is usually a permanent action. If the |
+ | DELETE | client wants to ensure that the deletion request |
+ | | was properly executed, then this option should not |
+ | | be used with the request. |
+ +-------------+----------------------------------------------------+
+
+ Table 3: Suggested Applicability of No-Response with REST Methods
+
+
+
+Bhattacharyya, et al. Informational [Page 8]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+3. Miscellaneous Aspects
+
+ This section further describes important implementation aspects worth
+ considering while using the No-Response option. The following
+ discussion contains guidelines and requirements (derived by combining
+ [RFC7252], [RFC7390], and [RFC5405]) for the application developer.
+
+3.1. Reusing Tokens
+
+ Tokens provide a matching criteria between a request and the
+ corresponding response. The life of a Token starts when it is
+ assigned to a request and ends when the final matching response is
+ received. Then, the Token can again be reused. However, a request
+ with No-Response typically does not have any guaranteed response
+ path. So, the client has to decide on its own about when it can
+ retire a Token that has been used in an earlier request so that the
+ Token can be reused in a future request. Since the No-Response
+ option is 'elective', a server that has not implemented this option
+ will respond back. This leads to the following two scenarios:
+
+ The first scenario is when the client is never going to care about
+ any response coming back or about relating the response to the
+ original request. In that case, it MAY reuse the Token value at
+ liberty.
+
+ However, as a second scenario, let us consider that the client sends
+ two requests where the first request is with No-Response and the
+ second request (with the same Token) is without No-Response. In this
+ case, a delayed response to the first one can be interpreted as a
+ response to the second request (client needs a response in the second
+ case) if the time interval between using the same Token is not long
+ enough. This creates a problem in the request-response semantics.
+
+ The most ideal solution would be to always use a unique Token for
+ requests with No-Response. But if a client wants to reuse a Token,
+ then in most practical cases the client implementation SHOULD
+ implement an application-specific reuse time after which it can reuse
+ the Token. A minimum reuse time for Tokens with a similar expression
+ as in Section 2.5 of [RFC7390] SHOULD be used:
+
+ TOKEN_REUSE_TIME = NON_LIFETIME + MAX_SERVER_RESPONSE_DELAY +
+ MAX_LATENCY
+
+ NON_LIFETIME and MAX_LATENCY are defined in Section 4.8.2 of
+ [RFC7252]. MAX_SERVER_RESPONSE_DELAY has the same interpretation as
+ in Section 2.5 of [RFC7390] for a multicast request. For a unicast
+ request, since the message is sent to only one server,
+ MAX_SERVER_RESPONSE_DELAY means the expected maximum response delay
+
+
+
+Bhattacharyya, et al. Informational [Page 9]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+ from the particular server to that client that sent the request. For
+ multicast requests, MAX_SERVER_RESPONSE_DELAY has the same
+ interpretation as in Section 2.5 of [RFC7390]. So, for multicast it
+ is the expected maximum server response delay "over all servers that
+ the client can send a multicast request to", per [RFC7390]. This
+ response delay for a given server includes its specific Leisure
+ period; where Leisure is defined in Section 8.2 of [RFC7252]. In
+ general, the Leisure for a server may not be known to the client. A
+ lower bound for Leisure, lb_Leisure, is defined in [RFC7252], but not
+ an upper bound as is needed in this case. Therefore, the upper bound
+ can be estimated by taking N (N>>1) times the lower bound lb_Leisure:
+
+ lb_Leisure = S * G / R
+
+ where
+ S = estimated response size
+ G = group size estimate
+ R = data transfer rate
+
+ Any estimate of MAX_SERVER_RESPONSE_DELAY MUST be larger than
+ DEFAULT_LEISURE, as defined in [RFC7252].
+
+ Note: If it is not possible for the client to get a reasonable
+ estimate of the MAX_SERVER_RESPONSE_DELAY, then the client, to be
+ safe, SHOULD use a unique Token for each stream of messages.
+
+3.2. Taking Care of Congestion Control and Server-Side Flow Control
+
+ This section provides guidelines for basic congestion control.
+ Better congestion control mechanisms can be designed as future work.
+
+ If this option is used with NON messages, then the interaction
+ becomes completely open loop. The absence of any feedback from the
+ server-end affects congestion-control mechanisms. In this case, the
+ communication pattern maps to the scenario where the application
+ cannot maintain an RTT estimate as described in Section 3.1.2 of
+ [RFC5405]. Hence, per [RFC5405], a 3-second interval is suggested as
+ the minimum interval between successive updates, and it is suggested
+ to use an even less aggressive rate when possible. However, in case
+ of a higher rate of updates, the application MUST have some knowledge
+ about the channel, and an application developer MUST interweave
+ occasional closed-loop exchanges (e.g., NON messages without
+ No-Response, or CON messages) to get an RTT estimate between the
+ endpoints.
+
+ Interweaving requests without No-Response is a MUST in case of an
+ aggressive request rate for applications where server-side flow
+ control is necessary. For example, as proposed in [CoAP-PUBSUB], a
+
+
+
+Bhattacharyya, et al. Informational [Page 10]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+ broker MAY return 4.29 (Too Many Requests) in order to request a
+ client to slow down the request rate. Interweaving requests without
+ No-Response allows the client to listen to such a response.
+
+3.3. Considerations regarding Caching of Responses
+
+ The cacheability of CoAP responses does not depend on the request
+ method, but it depends on the Response Code. The No-Response option
+ does not lead to any impact on cacheability of responses. If a
+ request containing No-Response triggers a cacheable response, then
+ the response MUST be cached. However, the response MAY not be
+ transmitted considering the value of the No-Response option in the
+ request.
+
+ For example, if a request with No-Response triggers a cacheable
+ response of 4.xx class with Max-Age not equal to 0, then the response
+ must be cached. The cache will return the response to subsequent
+ similar requests without No-Response as long as the Max-Age has not
+ elapsed.
+
+3.4. Handling the No-Response Option for a HTTP-to-CoAP Reverse Proxy
+
+ A HTTP-to-CoAP reverse proxy MAY translate an incoming HTTP request
+ to a corresponding CoAP request indicating that no response is
+ required (showing disinterest in all classes of responses) based on
+ some application-specific requirement. In this case, it is
+ RECOMMENDED that the reverse proxy generate an HTTP response with
+ status code 204 (No Content) when such response is allowed. The
+ generated response is sent after the proxy has successfully sent out
+ the CoAP request.
+
+ If the reverse proxy applies No-Response for one or more classes of
+ responses, it will wait for responses up to an application-specific
+ maximum time (T_max) before responding to the HTTP side. If a
+ response of a desired class is received within T_max, then the
+ response gets translated to HTTP as defined in [HTTP-to-CoAP].
+ However, if the proxy does not receive any response within T_max, it
+ is RECOMMENDED that the reverse Proxy send an HTTP response with
+ status code 204 (No Content) when allowed for the specific HTTP
+ request method.
+
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al. Informational [Page 11]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+4. Application Scenarios
+
+ This section describes some examples of application scenarios that
+ may potentially benefit from the use of the No-Response option.
+
+4.1. Frequent Update of Geolocation from Vehicles to Backend Server
+
+ Let us consider an intelligent traffic system (ITS) consisting of
+ vehicles equipped with a sensor gateway comprising sensors like GPS
+ and accelerometer sensors. The sensor gateway acts as a CoAP client.
+ It connects to the Internet using a low-bandwidth cellular connection
+ (e.g., General Packet Radio Service (GPRS)). The GPS coordinates of
+ the vehicle are periodically updated to the backend server.
+
+ While performing frequent location updates, retransmitting (through
+ the CoAP CON mechanism) a location coordinate that the vehicle has
+ already left is not efficient as it adds redundant traffic to the
+ network. Therefore, the updates are done using NON messages.
+ However, given the huge number of vehicles updating frequently, the
+ NON exchange will also trigger a huge number of responses from the
+ backend. Thus, the cumulative load on the network will be quite
+ significant. Also, the client in this case may not be interested in
+ getting responses to location update requests for a location it has
+ already passed and when the next location update is imminent.
+
+ On the contrary, if the client endpoints on the vehicles explicitly
+ declare that they do not need any status response back from the
+ server, then load will be reduced significantly. The assumption is
+ that the high rate of updates will compensate for the stray losses in
+ geolocation reports.
+
+ Note: It may be argued that the above example application can also be
+ implemented using the Observe option [RFC7641] with NON
+ notifications. But, in practice, implementing with Observe would
+ require lot of bookkeeping at the data collection endpoint at the
+ backend (observer). The observer needs to maintain all the
+ observe relationships with each vehicle. The data collection
+ endpoint may be unable to know all its data sources beforehand.
+ The client endpoints at vehicles may go offline or come back
+ online randomly. In the case of Observe, the onus is always on
+ the data collection endpoint to establish an observe relationship
+ with each data source. On the other hand, implementation will be
+ much simpler if initiating is left to the data source to carry out
+ updates using the No-Response option. Another way of looking at
+ it is that the implementation choice depends on where there is
+ interest to initiate the update. In an Observe scenario, the
+ interest is expressed by the data consumer. In contrast, the
+
+
+
+
+Bhattacharyya, et al. Informational [Page 12]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+ classic update case applies when the interest is from the data
+ producer. The No-Response option makes classic updates consume
+ even less resources.
+
+ The following subsections illustrate some sample exchanges based on
+ the application described above.
+
+4.1.1. Using No-Response with PUT
+
+ Each vehicle is assigned a dedicated resource "vehicle-stat-<n>",
+ where <n> can be any string uniquely identifying the vehicle. The
+ update requests are sent using NON messages. The No-Response option
+ causes the server not to respond back.
+
+ Client Server
+ | |
+ | |
+ +----->| Header: PUT (T=NON, Code=0.03, MID=0x7d38)
+ | PUT | Token: 0x53
+ | | Uri-Path: "vehicle-stat-00"
+ | | Content Type: text/plain
+ | | No-Response: 26
+ | | Payload:
+ | | "VehID=00&RouteID=DN47&Lat=22.5658745&Long=88.4107966667&
+ | | Time=2013-01-13T11:24:31"
+ | |
+ [No response from the server. Next update in 20 s.]
+ | |
+ +----->| Header: PUT (T=NON, Code=0.03, MID=0x7d39)
+ | PUT | Token: 0x54
+ | | Uri-Path: "vehicle-stat-00"
+ | | Content Type: text/plain
+ | | No-Response: 26
+ | | Payload:
+ | | "VehID=00&RouteID=DN47&Lat=22.5649015&Long=88.4103511667&
+ | | Time=2013-01-13T11:24:51"
+
+ Figure 1: Example of Unreliable Update with No-Response Option
+ Using PUT
+
+
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al. Informational [Page 13]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+4.1.2. Using No-Response with POST
+
+4.1.2.1. POST Updating a Fixed Target Resource
+
+ In this case, POST acts the same way as PUT. The exchanges are the
+ same as above. The updated values are carried as payload of POST as
+ shown in Figure 2.
+
+ Client Server
+ | |
+ | |
+ +----->| Header: POST (T=NON, Code=0.02, MID=0x7d38)
+ | POST | Token: 0x53
+ | | Uri-Path: "vehicle-stat-00"
+ | | Content Type: text/plain
+ | | No-Response: 26
+ | | Payload:
+ | | "VehID=00&RouteID=DN47&Lat=22.5658745&Long=88.4107966667&
+ | | Time=2013-01-13T11:24:31"
+ | |
+ [No response from the server. Next update in 20 s.]
+ | |
+ +----->| Header: POST (T=NON, Code=0.02, MID=0x7d39)
+ | POST | Token: 0x54
+ | | Uri-Path: "vehicle-stat-00"
+ | | Content Type: text/plain
+ | | No-Response: 26
+ | | Payload:
+ | | "VehID=00&RouteID=DN47&Lat=22.5649015&Long=88.4103511667&
+ | | Time=2013-01-13T11:24:51"
+
+ Figure 2: Example of Unreliable Update with No-Response Option
+ Using POST as the Update Method
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al. Informational [Page 14]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+4.1.2.2. POST Updating through Query String
+
+ It may be possible that the backend infrastructure deploys a
+ dedicated database to store the location updates. In such a case,
+ the client can update through a POST by sending a query string in the
+ URI. The query string contains the name/value pairs for each update.
+ No-Response can be used in the same manner as for updating fixed
+ resources. The scenario is depicted in Figure 3.
+
+ Client Server
+ | |
+ | |
+ +----->| Header: POST (T=NON, Code=0.02, MID=0x7d38)
+ | POST | Token: 0x53
+ | | Uri-Path: "updateOrInsertInfo"
+ | | Uri-Query: "VehID=00"
+ | | Uri-Query: "RouteID=DN47"
+ | | Uri-Query: "Lat=22.5658745"
+ | | Uri-Query: "Long=88.4107966667"
+ | | Uri-Query: "Time=2013-01-13T11:24:31"
+ | | No-Response: 26
+ | |
+ [No response from the server. Next update in 20 s.]
+ | |
+ +----->| Header: POST (T=NON, Code=0.02, MID=0x7d39)
+ | POST | Token: 0x54
+ | | Uri-Path: "updateOrInsertInfo"
+ | | Uri-Query: "VehID=00"
+ | | Uri-Query: "RouteID=DN47"
+ | | Uri-Query: "Lat=22.5649015"
+ | | Uri-Query: "Long=88.4103511667"
+ | | Uri-Query: "Time=2013-01-13T11:24:51"
+ | | No-Response: 26
+ | |
+
+ Figure 3: Example of Unreliable Update with No-Response Option
+ Using POST with a Query String to Insert Update Information
+ into the Backend Database
+
+4.2. Multicasting Actuation Command from a Handheld Device to a Group
+ of Appliances
+
+ A handheld device (e.g., a smart phone) may be programmed to act as
+ an IP-enabled switch to remotely operate on one or more IP-enabled
+ appliances. For example, a multicast request to switch on/off all
+ the lights of a building can be sent. In this case, the IP switch
+
+
+
+
+
+Bhattacharyya, et al. Informational [Page 15]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+ application can use the No-Response option in a NON request message
+ to reduce the traffic generated due to simultaneous CoAP responses
+ from all the lights.
+
+ Thus, No-Response helps in reducing overall communication cost and
+ the probability of network congestion in this case.
+
+4.2.1. Using Granular Response Suppression
+
+ The IP switch application may optionally use granular response
+ suppression such that the error responses are not suppressed. In
+ that case, the lights that could not execute the request would
+ respond back and be readily identified. Thus, explicit suppression
+ of option classes by the multicast client may be useful to debug the
+ network and the application.
+
+5. IANA Considerations
+
+ The IANA had previously assigned number 284 to this option in the
+ "CoAP Option Numbers" registry. IANA has updated this as shown
+ below:
+
+ +--------+--------------+-------------+
+ | Number | Name | Reference |
+ +--------+--------------+-------------+
+ | 258 | No-Response | RFC 7967 |
+ +--------+--------------+-------------+
+
+6. Security Considerations
+
+ The No-Response option defined in this document presents no security
+ considerations beyond those in Section 11 of the base CoAP
+ specification [RFC7252].
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
+ Application Protocol (CoAP)", RFC 7252,
+ DOI 10.17487/RFC7252, June 2014,
+ <http://www.rfc-editor.org/info/rfc7252>.
+
+
+
+
+Bhattacharyya, et al. Informational [Page 16]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+7.2. Informative References
+
+ [CoAP-ADAPT]
+ Bandyopadhyay, S., Bhattacharyya, A., and A. Pal,
+ "Adapting protocol characteristics of CoAP using sensed
+ indication for vehicular analytics", 11th ACM Conference
+ on Embedded Networked Sensor Systems (SenSys '13),
+ DOI 10.1145/2517351.2517422, November 2013.
+
+ [CoAP-PUBSUB]
+ Koster, M., Keranen, A., and J. Jimenez, "Publish-
+ Subscribe Broker for the Constrained Application Protocol
+ (CoAP)", Work in Progress, draft-koster-core-coap-
+ pubsub-05, July 2016.
+
+ [CoAP-TCP-TLS]
+ Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
+ Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
+ Application Protocol) over TCP, TLS, and WebSockets", Work
+ in Progress, draft-ietf-core-coap-tcp-tls-04, August 2016.
+
+ [HTTP-to-CoAP]
+ Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
+ E. Dijk, "Guidelines for HTTP-to-CoAP Mapping
+ Implementations", Work in Progress, draft-ietf-core-http-
+ mapping-13, July 2016.
+
+ [ITS-LIGHT]
+ Bhattacharyya, A., Bandyopadhyay, S., and A. Pal,
+ "ITS-light: Adaptive lightweight scheme to resource
+ optimize intelligent transportation tracking system (ITS)
+ - Customizing CoAP for opportunistic optimization", 10th
+ International Conference on Mobile and Ubiquitous Systems:
+ Computing, Networking and Services (MobiQuitous 2013),
+ DOI 10.1007/978-3-319-11569-6_58, December 2013.
+
+ [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
+ for Application Designers", BCP 145, RFC 5405,
+ DOI 10.17487/RFC5405, November 2008,
+ <http://www.rfc-editor.org/info/rfc5405>.
+
+ [RFC7390] Rahman, A., Ed., and E. Dijk, Ed., "Group Communication
+ for the Constrained Application Protocol (CoAP)", RFC
+ 7390, DOI 10.17487/RFC7390, October 2014,
+ <http://www.rfc-editor.org/info/rfc7390>.
+
+
+
+
+
+
+Bhattacharyya, et al. Informational [Page 17]
+
+RFC 7967 CoAP No-Response Option August 2016
+
+
+ [RFC7641] Hartke, K., "Observing Resources in the Constrained
+ Application Protocol (CoAP)", RFC 7641,
+ DOI 10.17487/RFC7641, September 2015,
+ <http://www.rfc-editor.org/info/rfc7641>.
+
+Acknowledgments
+
+ Thanks to Carsten Bormann, Matthias Kovatsch, Esko Dijk, Bert
+ Greevenbosch, Akbar Rahman, and Klaus Hartke for their valuable
+ input.
+
+Authors' Addresses
+
+ Abhijan Bhattacharyya
+ Tata Consultancy Services Ltd.
+ Kolkata, India
+
+ Email: abhijan.bhattacharyya@tcs.com
+
+
+ Soma Bandyopadhyay
+ Tata Consultancy Services Ltd.
+ Kolkata, India
+
+ Email: soma.bandyopadhyay@tcs.com
+
+
+ Arpan Pal
+ Tata Consultancy Services Ltd.
+ Kolkata, India
+
+ Email: arpan.pal@tcs.com
+
+
+ Tulika Bose
+ Tata Consultancy Services Ltd.
+ Kolkata, India
+
+ Email: tulika.bose@tcs.com
+
+
+
+
+
+
+
+
+
+
+
+
+Bhattacharyya, et al. Informational [Page 18]
+