One document matched: draft-tcs-coap-no-response-option-08.txt
Differences from draft-tcs-coap-no-response-option-07.txt
CoRE A. Bhattacharyya
Internet Draft S. Bandyopadhyay
Intended status: Standards track A. Pal
Expires: July 2015 Tata Consultancy Services Ltd.
January 21, 2015
CoAP option for no server-response
draft-tcs-coap-no-response-option-08
Abstract
There can be typical M2M scenarios where responses from server
against request from client might be considered redundant. This kind
of open-loop exchange (with no reverse path from the server to the
client) may be typically desired to minimize resource consumption in
constrained systems while simultaneously updating a bulk of
resources or updating a resource with a very high frequency. CoAP
already provides a non-confirmable (NON) mode of exchange where the
server end-point does not respond with ACK. However, the server end-
point responds back with a status code indicating "the result of the
attempt to understand and satisfy the request".
This draft introduces a header option for CoAP called 'No-Response'.
The option explicitly tells the server to suppress responses about
the state of the resource against the request from the client. This
option also provides granular control by allowing suppression of a
typical class or a combination of classes of responses. This option
may be effective for both unicast and multicast requests. This draft
discusses few exemplary applications which might benefit from this
option.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
Bhattacharyya, et al. Expires July 21, 2015 [Page 1]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 21, 2015.
Copyright Notice
Copyright (c) 2015 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...................................................3
1.1. Granular suppression of responses.........................3
1.2. Potential benefits........................................3
1.3. Terminology...............................................4
2. Option Definition..............................................4
2.1. Granularity in response suppression.......................5
3. Exemplary application scenarios................................7
3.1. Frequent update of geo-location from vehicles to backend..7
3.2. Multicasting actuation command from a handheld device to a
group of appliances............................................7
3.2.1. Using granular response suppression..................8
4. Miscellaneous aspects..........................................8
4.1. Re-use interval for message IDs...........................8
4.2. Re-using Tokens...........................................8
4.3. Taking care of congestion.................................9
4.4. Duality with the 'Observe' option.........................9
5. Example.......................................................10
5.1. Request/response Scenario................................10
5.1.1. Using No-Response with PUT..........................10
5.1.2. Using No-Response with POST.........................11
5.1.2.1. POST updating a target resource................11
Bhattacharyya, et al. Expires July 21, 2015 [Page 2]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
5.1.2.2. POST updating through resource creation........12
5.2. An end-to-end system combining No-Response and Observe...13
6. IANA Considerations...........................................15
7. Security Considerations.......................................15
8. Acknowledgments...............................................15
9. References....................................................15
9.1. Normative References.....................................15
9.2. Informative References...................................16
1. Introduction
This draft proposes a new header option for Constrained Application
Protocol (CoAP) [RFC7252] called 'No-Response'. This option enables
the client end-point to explicitly express its disinterest in
getting responses back from the server end-point. By default this
option expresses disinterest in all kinds of response. But fine
grain control over responses of a particular class is also possible.
This option should be applicable along with non-confirmable (NON)
requests. At present this option will have no effect if used with
confirmable (CON) mode.
Along with the technical details this draft presents some practical
application scenarios which should bring out the usefulness of this
option.
1.1. Granular suppression of responses
This option enables granularity 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 something 'bad' happens and a
response of class 4.xx or 5.xx is to be fed back to the client. No
response is required in case of 2.xx responses. A similar scheme is
described in Section 3.7 of [RFC7390] on the server side where the
server may decide to suppress responses for group communication at a
granular level. But in that case the server itself decides about
response suppression and client does not have any knowledge about
that. On the other hand, the 'No-Response' option enables the
clients to explicitly inform the server about its disinterest in
responses.
1.2. Potential benefits
Use of No-Response option is driven by typical application scenario
and the characteristics of the information to be updated. If this
option is opportunistically used in a fitting M2M application then
the concerned systems may benefit in the following aspects:
Bhattacharyya, et al. Expires July 21, 2015 [Page 3]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
* Reduction in network clogging due to effective reduction of
the overall traffic.
* Reduction in server-side loading by relieving the server from
responding to each request when not necessary.
* Reduction in battery consumption at the constrained end-point.
* Reduction in overall communication cost.
* Help satisfy hard real-time requirements since waiting due to
closed loop latency can be completely avoided.
1.3. Terminology
The terms used in this draft 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 RFC-2119.
2. Option Definition
The properties of this option are given in Table 1.
+--------+---+---+---+---+-------------+--------+--------+---------+
| Number | C | U | N | R | Name | Format | Length | Default |
+--------+---+---+---+---+-------------+--------+--------+---------+
| TBD | | | X | | No-Response | uint | 1 | 0 |
+--------+---+---+---+---+-------------+--------+--------+---------+
Table 1: Option Properties
This option is Elective and Non-Repeatable. This is a request option
and primarily intended to be used with non-confirmable update
requests (e.g., PUT) and should have no effect if used with a CON
request. This option is not applicable and should have no effect for
usual GET requests asking for resource representation. However, this
option MAY be used with special GET request for 'cancellation' of an
observe session (Section 3.6 of [I-D.ietf-core-observe]). This
option contains values to optionally indicate disinterest in all or
a particular class or combination of classes of responses as
described in the next sub-section. The following table provides a
'ready-reference' on possible applicability of this option for all
Bhattacharyya, et al. Expires July 21, 2015 [Page 4]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
the four REST methods. This table is prepared in view of the type of
application scenarios foreseen so far.
+-------------+----------------------------------------------------+
| Method Name | Remarks on applicability |
+-------------+----------------------------------------------------+
| | This option does not apply to GET under usual |
| | circumstances when the client requests the contents|
| | of a resource. However, this option may be useful |
| | for special GET requests. At present only one such|
| | application is identified which is the |
| | 'cancellation' procedure for 'Observe'. Observe- |
| GET | cancellation requires a client to issue a GET |
| | request with Observe option set to 'deregister' |
| | (1). Since, in this case the server response does |
| | not contain any payload, the client MAY express its|
| | disinterest in server responses. |
+-------------+----------------------------------------------------+
| | Suitable for frequent updates in NON mode on |
| PUT | existing resources. Might not be useful when |
| | PUT creates a new resource. |
+-------------+----------------------------------------------------+
| | If POST is used just to update a target resource |
| | then No-Response can be used in the same manner as |
| | in NON-PUT. May also be applicable when POST |
| POST | creates 'transient' resources as part of name/value|
| | pair in a query string for frequent updates (may be|
| | to update some database; see Section 5.1.2.2). |
+-------------+----------------------------------------------------+
| | Deletion is usually a permanent action and the |
| DELETE | client SHOULD make sure that the deletion actually |
| | happened. SHOULD NOT be applicable. |
+-------------+----------------------------------------------------+
Table 2: Suggested applicability of No-Response
2.1. Granularity in response suppression
This option is defined as a bit-map (Table 3) to achieve granular
suppression.
Bhattacharyya, et al. Expires July 21, 2015 [Page 5]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
+-------+-----------------------+---------------------------------+
| Value | Binary Representation | Description |
+-------+-----------------------+---------------------------------+
| 0 | 00000000 | Suppress all responses. |
+-------+-----------------------+---------------------------------+
| 2 | 00000010 | Allow 2.xx success responses. |
+-------+-----------------------+---------------------------------+
| 8 | 00001000 | Allow 4.xx client errors. |
+-------+-----------------------+---------------------------------+
| 16 | 00010000 | Allow 5.xx server errors. |
+-------+-----------------------+---------------------------------+
Table 3: Option values
XORing the values defined for allowing particular classes will
result in allowing a combination of classes of responses. So, a
value of 18 (binary: 00010010) will result in allowing all 2.xx and
5.xx classes of responses. It is to be noted that a value of 26 will
indicate that all types of responses are to be allowed (which is as
good as not using No-Response at all).
Implementation Note: When No-Response is used with empty or 0 value
in a request, the client end-point SHOULD cease listening to
response against the particular request. On the other hand,
opening up at least one class of response means that the client
end-point can no longer completely cease listening activity and
must be configured to listen up to some application specific
time-out period for the particular request. The client end-point
never knows whether the present update will be a success or a
failure. Thus, for example, if the client decides to open up the
response for errors (4.xx & 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). A point to be noted in this context is that there may
be situations when the response on errors might get lost. In such
a situation the client would wait up to the time-out period but
will not receive any response. But this should not lead to the
impression to the client that the request was successful. The
application designer needs to tackle such situation. For example,
while performing frequent updates, the client may strategically
interweave requests without No-Response into a series of requests
with No-Response to check time to time if things are fine at the
server end the server is actively responding.
Bhattacharyya, et al. Expires July 21, 2015 [Page 6]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
3. Exemplary application scenarios
This section describes some exemplary user stories which may
potentially get benefitted through the use of No-Response option.
3.1. Frequent update of geo-location from vehicles to backend
Let us consider an intelligent traffic system (ITS) consisting of
vehicles equipped with a sensor-gateway comprising sensors like GPS
and Accelerometer. The sensor-gateway connects to the Internet using
a low-bandwidth cellular (e.g. GPRS) connection. The GPS co-
ordinates are periodically updated to the backend server by the
gateway. The update rate in case of ITS is adaptive to the motional-
state of the vehicle. If the vehicle moves fast the update rate is
high as the position of the vehicle changes rapidly. If the vehicle
is static or moves slowly then the update rate is low. This ensures
that bandwidth and energy is not consumed unnecessarily. The
motional-state of the vehicle is inferred by a local analytics
running on the sensor-gateway which uses the accelerometer data and
the rate of change in GPS co-ordinates. The back-end server hosts
applications which use the updates for each vehicle and produce
necessary information for remote users.
Retransmitting a location co-ordinate which the vehicle has already
crossed is not efficient as it adds redundant traffic to the
network. So, the updates are done in NON mode. However, given the
thousands of vehicles updating frequently, the NON exchange will
also trigger huge number of status responses from the backend. Thus
the cumulative load on the network will be quite significant.
On the contrary, if the sensor-gateways on the vehicles explicitly
declare that they do not need any status response back from the
server then significant load will be reduced. The assumption is
that, since the update rate is high, stray losses in geo-locations
will be compensated with the large update rate and thereby not
affecting the end applications.
3.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 a single or group of IP
enabled appliances. For example the smart phone can be programmed to
send a multicast request to switch on/ off all the lights of a
building. In this case the IP switch application can use No-Response
option along with NON request to reduce the traffic generated due to
simultaneous status responses from hundreds of lights.
Bhattacharyya, et al. Expires July 21, 2015 [Page 7]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
Thus No-Response helps in reducing overall communication cost and
the probability of network clogging in this case.
3.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 which could not execute the request would
respond back and be readily identified.
4. Miscellaneous aspects
This section further describes few important implementation aspects
worth considering while using No-Response. The following discussion
does not mandate anything, rather suggests some guidelines for the
application developer.
4.1. Re-use interval for message IDs
Since No-Response is used along with NON requests, 'NON-LIFETIME'
(as defined in Section 4.8.2 of [RFC7252]) is suggested as the time
interval over which a message ID can be safely re-used.
4.2. Re-using 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 re-used. However, a NON
request with No-Response does not have any response path. So, the
client has to decide on its own about when it can retire a token
which 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 which has not implemented this option MAY
emanate a response. This leads to the following two scenarios:
The first scenario is, 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 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 gap between using the same tokens is not enough.
This creates a problem in the request-response semantics.
Bhattacharyya, et al. Expires July 21, 2015 [Page 8]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
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 'patience' time after which it can
re-use the token. Appendix-B.4.1 of [I-D.draft-bormann-coap-misc]
refers to the 'patience' option defined in [I-D.draft-li-coap-
patience]. 'Patience' option effectively puts a deadline to the
server to respond back. However, 'patience' is not exposed to the
protocol level at present. This draft suggests a reuse time for
tokens with similar expression as in Section 2.5 of [RFC7390]:
TOKEN_REUSE_TIME = NON_LIFETIME + MAX_SERVER_RESPONSE_DELAY +
MAX_LATENCY.
NON_LIFETIME and MAX_LATENCY are defined in 4.8.2 of [RFC7252].
MAX_SERVER_RESPONSE_DELAY has same interpretation as in Section 2.5
of [RFC7390] for multicast request. But for unicast request
MAX_SERVER_RESPONSE_DELAY is simply the expected maximum response
delay from the particular server to which client sent the request.
This delay includes the maximum Leisure time period as defined in
Section 8.2 of [RFC7252] and Appendix-B.4.2 of [I-D.draft-bormann-
coap-misc]with group size (G) = 1 for unicast request.
Note that 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 request with No-Response.
4.3. Taking care of congestion
The possible communication scenarios leveraging the benefits of 'No-
Response' should primarily fall into the class of low-data volume
applications as described in Section 3.1.2 of [RFC5405]. Precisely,
they should map to the scenario where the application cannot
maintain an RTT estimate. Hence, following [RFC5405], a 3s interval
is suggested as the minimum interval between successive updates.
However, an application developer MAY interweave occasional closed-
loop exchanges (e.g. CoAP-NON without No-Response or CoAP-CON) to
get an RTT estimate between the end-points and adjust the interval
between updates time-to-time.
4.4. Duality with the 'Observe' option
Unlike the multicast actuation scenarios (example in Section 3.2),
scenarios like frequent update using No-Response (example in Section
3.1) leads to an interesting observation. The 'No-Response' option
can be seen to complement the 'Observe' option with NON-
notifications ([I-D.ietf-core-observe]). In case of the later the
Bhattacharyya, et al. Expires July 21, 2015 [Page 9]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
update notifications from the server reach the observer client
without triggering any response from the observer. However, there is
a difference in the point of interest. In the 'Observe' scenario the
interest is expressed by the 'consumer' to get the data. On the
contrary, the updates using 'No-Response' applies to the scenario
when it is the interest of the 'producer' to update the data. It is
up to the application designer to choose between No-Response and
'Observe' with notifications in NON mode. However, 'No-Response' and
'Observe' using NON-notification may be combined together, under
permitting condition, to achieve high performance gain in an end-to-
end publish/subscribe kind of application. A typical example is
illustrated in Section 5.2.
5. Example
This section illustrates few examples of exchanges based on the
scenario narrated in Section 3.1. Examples for other scenarios can
be easily conceived based on these illustrations.
5.1. Request/response Scenario
5.1.1. Using No-Response with PUT
Figure 1 shows a typical request with this option. The depicted
scenario occurs when the vehicle#n moves very fast and update rate
is high. The vehicle is assigned a dedicated resource: vehicle-stat-
<n>, where <n> can be any string uniquely identifying the vehicle.
The update requests are in NON mode. The No-Response option causes
the server not to respond back.
Bhattacharyya, et al. Expires July 21, 2015 [Page 10]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
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: 0
| | 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 secs.]
| |
+----->| Header: PUT (T=NON, Code=0.03, MID=0x7d39)
| PUT | Token: 0x54
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 0
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5649015&Long=88.4103511667&
| | Time=2013-01-13T11:24:51"
Figure 1: Exemplary unreliable update with No-Response option using
PUT.
5.1.2. Using No-Response with POST
POST "usually results in a new resource being created or the target
resource being updated". Exemplary uses of 'No-Response' for both
these usual actions of POST are given below.
5.1.2.1. POST updating a target resource
In this case POST acts the same way as PUT. The exchanges are same
as above. The updated values are carried as payload of POST as shown
in Figure 2.
Bhattacharyya, et al. Expires July 21, 2015 [Page 11]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
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: 0
| | 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 secs.]
| |
+----->| Header: PUT (T=NON, Code=0.02, MID=0x7d39)
| POST | Token: 0x54
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 0
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5649015&Long=88.4103511667&
| | Time=2013-01-13T11:24:51"
Figure 2: Exemplary unreliable update with No-Response option using
POST as the update-method.
5.1.2.2. POST updating through resource creation
In most practical implementations the backend infrastructure (as
described in Section 3.1) will have a dedicated database to store
the location updates. In such a case the client would send an update
string as the POST URI which contains the name/value pairs for each
update. Thus frequent updates may be performed through POST by
creating such 'short-lived' resources comprising of query strings.
Hence 'No-Response' can be used in same manner as for updating fixed
resources. The scenario is depicted in Figure 3.
Bhattacharyya, et al. Expires July 21, 2015 [Page 12]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
Client Server
| |
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d38)
| POST | Token: 0x53
| | Uri-Path: "insertInfo"
| | 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: 0
| |
[No response from the server. Next update in 20 secs.]
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d39)
| POST | Token: 0x54
| | Uri-Path: "insertInfo"
| | 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: 0
| |
Figure 3: Exemplary unreliable update with No-Response option using
POST with a query-string to insert update information to backend
database.
5.2. An end-to-end system combining No-Response and Observe
This example illustrates the publish/subscribe scenario pointed out
in Section 4.4 above. The 'No-Response' option can be combined with
the 'Observe' option with NON-notifications to create a lightweight
end-to-end publish/subscribe system. For example, the updates from a
remote vehicle may be observed by a remote observer in a handheld as
shown in figure 4.
Bhattacharyya, et al. Expires July 21, 2015 [Page 13]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
Pub Server Sub
(Client) (Client)
| | |
| | <-----+
| | GET |
+-----> | (Observe: empty, Token: 30)|
| POST | |
| Header: POST (T=NON, Code=0.02, MID=0x7d38) |
| Token: 0x53 |
| Uri-Path: "insertInfo" |
| 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: 0 |
| | |
| +-----> |
| | 2.05 (T=NON, MID=0x5d40, Token: 30) |
| | 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 secs.] |
| | |
+-----> | |
| POST | |
| Header: POST (T=NON, Code=0.02, MID=0x7d39) |
| Token: 0x54 |
| Uri-Path: "insertInfo" |
| 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: 0 |
| | |
| +-----> |
| | 2.05 (T=NON, MID=0x5d41, Token: 30) |
| | Payload: |
| | "VehID=00&RouteID=DN47&Lat=22.5649015& |
| | Long=88.4103511667& Time=2013-01-13T11:24:51"|
Figure 4: Exemplary end-to-end update and observe scenario using
'No-Response' for NON-updates from 'publisher' and 'Observe' with
NON-notifications by the 'subscriber'.
Bhattacharyya, et al. Expires July 21, 2015 [Page 14]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
6. IANA Considerations
The IANA is requested to add the following option number entries:
+--------+--------------+----------------------------+
| Number | Name | Reference |
+--------+--------------+----------------------------+
| 92 | No-Response | Section 4 of this document |
+--------+--------------+----------------------------+
7. 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].
8. Acknowledgments
Thanks to Carsten Bormann, Esko Dijk, Bert Greevenbosch, Akbar
Rahman and Claus Hartke for their valuable inputs.
9. References
9.1. Normative References
[RFC7252]
Shelby, Z., Hartke, K. and Bormann, C.,"Constrained Application
Protocol (CoAP)", RFC 7252, June, 2014
[I-D.ietf-core-observe]
Hartke, K.,"Observing Resources in CoAP", draft-ietf-core-observe-
16, December 30, 2014
[RFC7390]
Rahman, A. and Dijk, E.,"Group Communication for CoAP", RFC 7390,
October, 2014
[I-D.draft-bormann-coap-misc]
Bormann, C. and Hartke, K., "Miscelleneous additions to CoAP",
draft-bormann-coap-misc-26, December 19, 2013
[I-D.draft-kovatsch-lwig-coap]
Bhattacharyya, et al. Expires July 21, 2015 [Page 15]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
Kovatsch, M., Bergmann, O., Dijk, E., He, X. and Bormann, C., "CoAP
Implementation Guidance", draft-kovatsch-lwig-coap-03, February 28,
2014
[RFC5405]
Eggert, L. and Fairhurst, G.," Unicast UDP Usage Guidelines for
Application Designers", RFC 5405, November, 2008
[I-D.draft-li-coap-patience]
Li, K., Greevenbosch, B., Dijk, E. and Loreto, S.," CoAP Option
Extension: Patience", draft-li-core-coap-patience-option-04, July
04, 2014
9.2. Informative References
[MOBIQUITOUS 2013]
Bhattacharyya, A., Bandyopadhyay, S. and Pal, A., "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), December, 2013.
[Sensys 2013]
Bandyopadhyay, S., Bhattacharyya, A. and Pal, A., "Adapting protocol
characteristics of CoAP using sensed indication for vehicular
analytics", 11th ACM Conference on Embedded Networked Sensor Systems
(Sensys 2013), November, 2013.
Bhattacharyya, et al. Expires July 21, 2015 [Page 16]
Internet-Draft draft-tcs-coap-no-response-option-08 January 2015
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
Bhattacharyya, et al. Expires July 21, 2015 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 13:57:45 |