One document matched: draft-li-core-conditional-observe-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC7252 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml'>
<!ENTITY OBSERVE PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-observe.xml'>
<!ENTITY LINK-FORMAT PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-link-format.xml'>
<!ENTITY CORE-INTERFACES PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-interfaces.xml'>
<!ENTITY COAP-MISC PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-bormann-coap-misc-13.xml'>
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc
category="std"
ipr="trust200902"
docName="draft-li-core-conditional-observe-05">
<front>
<title abbrev="Conditional observe in CoAP">
Conditional observe in CoAP
</title>
<author initials="S." surname="Li" fullname="Shitao Li">
<organization abbrev="Huawei Technologies">Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Base</street>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<phone>+86-25-56624157</phone>
<email>lishitao@huawei.com</email>
</address>
</author>
<author initials="K." surname="Li" fullname="Kepeng Li">
<organization abbrev="Huawei Technologies">Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Base</street>
<street>Bantian, Longgang</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>China</country>
</postal>
<phone>+86-755-28970231</phone>
<email>likepeng@huawei.com</email>
</address>
</author>
<author initials="J." surname="Hoebeke" fullname="Jeroen Hoebeke">
<organization abbrev="iMinds-IBCN/UGent">iMinds-IBCN/UGent</organization>
<address>
<postal>
<street>Department of Information Technology</street>
<street>Internet Based Communication Networks and Services (IBCN)</street>
<street>Ghent University - iMinds</street>
<street>Gaston Crommenlaan 8 bus 201</street>
<city>Ghent</city>
<code>B-9050</code>
<country>Belgium</country>
</postal>
<phone>+32-9-3314954</phone>
<email>jeroen.hoebeke@intec.ugent.be</email>
</address>
</author>
<author initials="F V.D.A." surname="Van den Abeele" fullname="Floris Van den Abeele">
<organization abbrev="iMinds-IBCN/UGent">iMinds-IBCN/UGent</organization>
<address>
<postal>
<street>Department of Information Technology</street>
<street>Internet Based Communication Networks and Services (IBCN)</street>
<street>Ghent University - iMinds</street>
<street>Gaston Crommenlaan 8 bus 201</street>
<city>Ghent</city>
<code>B-9050</code>
<country>Belgium</country>
</postal>
<phone>+32-9-3314946</phone>
<email>floris.vandenabeele@intec.ugent.be</email>
</address>
</author>
<author initials="A J." surname="Jara" fullname="Antonio J. Jara">
<organization abbrev="University of Murcia">University of Murcia</organization>
<address>
<postal>
<street>Department of Information Technology and Communications</street>
<street>Computer Science Faculty</street>
<street>Campus de Espinardo</street>
<city>Murcia</city>
<code>ES-30100</code>
<country>Spain</country>
</postal>
<phone>+34-868-88-8771</phone>
<email>jara@um.es</email>
</address>
</author>
<date year="2014" />
<area>Applications</area>
<workgroup>core</workgroup>
<abstract>
<t>
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.
</t>
</abstract>
<note title="Note">
<t>
Discussion and suggestions for improvement are requested, and should
be sent to core@ietf.org.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
CoAP <xref target='RFC7252'/> is an Application Protocol for
Constrained Nodes/Networks. The observe <xref target='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 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.
</t>
<section anchor="Justification" title="Justification">
<t>
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.
</t>
<t>
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. <!-- Strictly, a client might want to detect when one of its observe relationships has been lost (e.g. server reboot => no notification for Max-Interval => re-register) -->
</t>
<t>
Consider the following example.
</t>
<figure anchor="Observe_Example" title="GET request with observe">
<artwork> <![CDATA[
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 ------- |
| |
]]> </artwork>
</figure>
<t>
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 simple
constrained device not too sensitive to the resource state change, so it may not want to <!-- Use terminology from LWIG -->
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.
</t>
</section>
<section anchor="termi" title="Terminology">
<t>
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 <xref target='RFC2119' />.
</t>
</section>
</section>
<section anchor="motivation" title="Motivation">
<t>
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.
</t>
<t>
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.
</t>
<t>
In <xref target='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 can be used to complement the Minimum-Interval and Maximum-Interval Options.
</t>
</section>
<section anchor="option" title="Conditional Observe Options">
<t>
<figure anchor="Options" title="Conditional Observe Options">
<artwork><![CDATA[
+-----+---+---+---+---+-----------------+--------+--------+---------+
| 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
]]></artwork>
</figure>
</t>
<t>
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).
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Basically, a similar procedure as described in the observe draft
<xref target='I-D.ietf-core-observe'/> is followed, but extended with additional behavior
by taking the Minimum-Interval and Maximum-Interval Options into account.
The exact semantics are described below.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="using" title="Using the Condition Option">
<t>
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.
</t>
<t>
When a server receives such a request, it first services the request in the same way as
described in <xref target='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.
</t>
<t>
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 <xref target='I-D.ietf-core-observe'/> and that the client itself is responsible
for processing the resource state in the notifications in order to identify whether the
condition of interest is fulfilled or not.
</t>
<t>
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 <xref target='I-D.ietf-core-observe'/>.
</t>
</section>
<section anchor="example" title="Examples">
<t>
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.
</t>
<t>
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.
</t>
<figure anchor="Minimum_Example" title="Minimum-Interval Option Usage">
<artwork> <![CDATA[
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
| |
]]> </artwork>
</figure>
<t>
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.
</t>
<figure anchor="Maximum_Example" title="Maximum-Interval Option Usage">
<artwork> <![CDATA[
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
| |
]]> </artwork>
</figure>
<t>
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.
</t>
<figure anchor="together" title="Minimum-Interval and Maximum-Interval Options together">
<artwork> <![CDATA[
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
| |
]]> </artwork>
</figure>
<t>
Further, in <xref target='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.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
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
<xref target='I-D.ietf-core-observe'/>.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
This draft adds the following option numbers to the CoAP Option
Numbers registry of <xref target='RFC7252'/>
</t>
<t>
<figure>
<artwork><![CDATA[
+--------+------------------+----------------+
| Number | Name | Reference |
+--------+------------------+----------------+
| TBD | Minimal-Interval | [RFCXXXX] |
+--------+------------------+----------------+
| TBD | Maximum-Interval | [RFCXXXX] |
+--------+------------------+----------------+
Table 3: Conditional Observe Option Numbers
]]></artwork>
</figure>
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Thanks to the IoT6 European Project (STREP) of the 7th Framework Program (Grant 288445).
</t>
<t>
Thanks to Zach Shelby, Bert Greevenbosch for the discussions.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC7252;
&OBSERVE;
</references>
<references title="Informative References">
&LINK-FORMAT;
&CORE-INTERFACES;
&COAP-MISC;
<reference anchor="SENSORS">
<front>
<title>Architecture for Improving Terrestrial Logistics Based on the Web of Things</title>
<author initials="M" surname="Castro" fullname="Miguel Castro"><organization/>
</author>
<author initials="A" surname="Jara" fullname="Antonio J. Jara"><organization/>
</author>
<author initials="A" surname="Skarmeta" fullname="Antonio Skarmeta"><organization/>
</author>
<date month="May" day="20" year="2012"/>
<abstract>
<t>
</t>
</abstract>
</front>
<seriesInfo name="Sensors" value="12, no. 5, 6538-6575, 2012"/>
<format type="PDF" target="http://www.mdpi.com/1424-8220/12/5/6538/pdf"/>
</reference>
<reference anchor="CPSCOM">
<front>
<title>Efficiently observing Internet of Things Resources</title>
<author initials="G" surname="Ketema" fullname="Girum Ketema"><organization/>
</author>
<author initials="J" surname="Hoebeke" fullname="Jeroen Hoebeke"><organization/>
</author>
<author initials="I" surname="Moerman" fullname="Ingrid Moerman"><organization/>
</author>
<author initials="P" surname="Demeester" fullname="Piet Demeester"><organization/>
</author>
<author initials="Shi Tao." surname="Li" fullname="Shitao Li"><organization/>
</author>
<author initials="A" surname="Jara" fullname="Antonio J. Jara"><organization/>
</author>
<date month="Novemer" day="20" year="2012"/>
<abstract>
<t>
</t>
</abstract>
</front>
<seriesInfo name="The 2012 IEEE International Conference on Cyber, Physical and Social Computing " value="November 20-23, 2012, Besançon, France"/>
</reference>
</references>
<section title="Change log">
<t>Changes in v05
<list style="symbols">
<t>Simplified to contain only two options:
<list style="symbols">
<t>Minimal Interval</t>
<t>Maximum Interval</t>
</list>
</t>
</list>
</t>
<t>Changes in v04
<list style="symbols">
<t>Updated draft to be consistent with observe draft:
<list style="symbols">
<t>(Took request URI into consideration for Cancellation.)</t>
<t>(Explicitly stated that the draft diverts from a MUST NOT
defined in the observe draft)</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
<t>(Switched Reliability flag with Logic flag.)</t>
<t>Updated source endpoint terminology.</t>
</list>
</t>
<t>Changes in v03
<list style="symbols">
<t>Examples for most condition types</t>
<t>Update the option number according to the new numbering scheme</t>
<t>Added reference to paper validating implementation on constrained device</t>
</list>
</t>
<t>Changes in v02
<list style="symbols">
<t>Restructured entire document</t>
<t>Detailed description of the Condition Option and updated format of the Condition Option value</t>
<t>Added more Condition Types</t>
<t>New section on cancellation, updating and existence of conditional relationships</t>
<t>New section on discovery</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 18:32:02 |