One document matched: draft-li-core-conditional-observe-01.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 COAP PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.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.draft-shelby-core-interfaces-01.xml'>
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<rfc
category="std"
ipr="trust200902"
docName="draft-li-core-conditional-observe-01">
<front>
<title abbrev="Conditional observe in CoAP">
Conditional observe in CoAP
</title>
<author initials="Shi Tao." 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="J." surname="Hoebeke" fullname="Jeroen Hoebeke">
<organization abbrev="IBBT-IBCN/UGent">IBBT-IBCN/UGent</organization>
<address>
<postal>
<street>Department of Information Technology</street>
<street>Internet Based Communication Networks and Services (IBCN)</street>
<street>Ghent University - IBBT</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>
<date year="2012" />
<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. This document defines a new mechanism
in CoAP Observe so that a CoAP client can conditionally observe a
resource on a CoAP server, only being informed about state changes
meeting a specific condition.
</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='I-D.ietf-core-coap'/> 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 can get a notification response
whenever the state of the observed resource changed. However, in some scenarios,
the CoAP client may only care parts of the state change of the resource, other
state changes might be meaningless. This inability to suppress additional
notification results in superfluous traffic. This memo defines a new CoAP option
"Condition" that can be used to allow the CoAP client to condition the observe
request, and only when such condition is met, the CoAP server shall 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 services 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.
But different sensor equipments have different properties, e.g. different data unit,
different response time. When a client wants to collect information from a
sensor, it does not want to receive useless information, it hopes that the sensor only
responses with what the client wants.
</t>
<t>
Consider the following example.
</t>
<figure>
<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 |
| |
Figure 1: GET request with observe
]]> </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 quite
simple equipment not too sensitive to the resource state change, so it may not want to
receive the notification that often. One possible solution could be to change the
sensor's parameter, 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. A notification relationship is established and whenever the state of the
resource changes, the new representation is pushed to the observer. In many cases, an
observer will typically be interested in state changes that satisfy a specific condition.
In addition, similar conditional observations will prove useful for many different
resources. For example, being informed when the state of a resource exceeds a specific
value.
</t>
<t>
Defining an agreed 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, intermediate machines such
as a smart proxy, can process multiple conditional observations, having as 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.shelby-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. To alleviate
this problem, this draft proposes to implement frequently occurring conditional
observations through the use of a new CoAP Condtion Option, having a compact
representation and well-defined meaning. For other specific conditional observations,
another mechanism such as query parameters can be used to complement the Condition
Option.
</t>
</section>
<section title="Condition types">
<t>
This section lists some possible conditions that can be used to extend the
observe request.
</t>
<t>
Minimum/Maximum Period: the minimum/maximum time in seconds between notifications
</t>
<t>
Step: how much the value of a resource should change before sending a new
notification
</t>
<t>
Periodic: periodic interval with which new notification should be sent
</t>
<t>
Range: a notification is sent when the value of the resource lies under
a specific range.
</t>
</section>
<section anchor="overview" title="Overview of Operation">
<t>
Whenever a client wants to initiate a Conditional Observation relationship, it sends
a GET request with a Observe and Condition Option (see section 5 for the Condition
Option definition). The Condition Option includes the condition required by the client
such as the minimum response time or the minimum step change (see section 6 for
the definition of condition type). When a server receives such a request, it first
services the request the same way as described in <xref target='I-D.ietf-core-observe'/>.
Next, if the server supports the Condition Option, it needs to analyze the Condition
Option to find the condition requested by the client. If the condition is supported, the
client is informed about the successful establishment of the conditional relationship.
</t>
<t>
Whenever the resource state changes on the server, it needs to check the established
conditional relationships. Whenever the condition is met, the server shall send the
notification response to the client that has established the relationship. If not met,
the server does not need to send any response to the client.
</t>
</section>
<section anchor="Definition" title="Definition of Condition Option">
<t>
<figure>
<artwork>
+------+-----+-----------+-----------+--------+---------------+
| Type | C/E | Name | Data type | Length | Default |
+------+-----+-----------+-----------+--------+---------------+
| 22 | E | Condition | uint | 1-3 B | |
+------+-----+-----------+-----------+--------+---------------+
table 1: Condition Option number
</artwork>
</figure>
</t>
</section>
<section anchor="using" title="Using the Condition option">
<t>
The Condition Option is used to indicate the condition requirement requested by a CoAP
client. It must be used together with the Observe Option and represents the
condition the client wants to apply to the observation relationship. The server needs
to follow the general procedure as described in observe draft
<xref target='I-D.ietf-core-observe'/>, but takes the Condition Option into account.
</t>
<t>
Since the condition Option is elective, an observe request that includes the Condition
Option will automatically fall back to a basic observe request if the server does not
support the Condition Option. There is no default value for the Condition Option.
</t>
<t>
The Condition option may occur more than once, when multiple Condition Options are present in an
observe GET request, it means that the initiator has multiple condition requirements, and the
first condition option in the request has the highest priority.
</t>
<t>
If multiple Condition Options with the same condition type are present in a request, their priority
is the same, and the relationship is "AND".
</t>
<t>
The size of the Condition Option is not fixed and can range from 1 to 3 bytes. The value
carried is in a specific format consisting of three fields: condition type, method and condition value.
</t>
<t>
<figure>
<artwork>
0
0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+
| TYPE | M | VAL |
+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | M | VAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | M | VAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
table 2: Condition Option value
</artwork>
</figure>
</t>
<t>
TYPE: condition type. The condition type is a 4 bit integer indicating the type of
the condition used in the observe request. Every value of TYPE represents the
type ID of a specific condition type. For example, "1" represents the minium response time,
"2" represent the step. Below is the definition of identified condition types.
</t>
<t>
M: method. The method is a 2 bit integer indicating the method used in the condition.
Below is the further definition of the method attribute.
</t>
<t>
VAL: condition value. The condition value is a variable-size (4,12, or 20 bit) unsigned
integer indicating the value of the condition. The value can range from 0 to 2^4 (16),
from 0 to 2^12 (4096) or from 0 to 2^20 (1048576).
</t>
<t>
<figure>
<artwork>
+-----------------------+-----+
|Condition type | Id. |
+-----------------------+-----+
| minimum response time | 1 |
+-----------------------+-----+
| maximum response time | 2 |
+-----------------------+-----+
| step | 3 |
+-----------------------+-----+
| range | 4 |
+-----------------------+-----+
| periodic | 5 |
+-----------------------+-----+
table 3: Condition type
</artwork>
</figure>
</t>
<t>
Minimum response time: When present, it indicates that the condition required by the
initiator is the minimum response time. This condition indicates the minimum time the server
should wait between sending notification responses.
</t>
<t>
Maximum response time: When present, it indicates that the condition required by the
initiator is the maximum response time. This condition indicates the maximum time the server
should wait between sending notification responses.
</t>
<t>
Step: When present, it indicates that the condition required by the initiator is the
change step. This condition indicates the minium state change of a resource before the server
can send a new notification response.
</t>
<t>
Range: When present, it indicates that the condition required by the initiator is the
state change range. This condition indicates that only when the state value is
under the range of this condition, the server shall send a new notification response.
The value and the method attributes decide the range of the condition, e.g, set the method
to ">", and value to "20", means that the range is bigger than 20, so only the state value
bigger than 20, that the server shall send a new notification response to the client.
</t>
<t>
Periodic: When present, it indicates that the condition required by the initiator is the
periodic response time . This condition indicates the periodic interval with which new notifications
should be sent.
</t>
<t>
<figure>
<artwork>
+-----------------------+-----+
|Method | Id. |
+-----------------------+-----+
| = | 0 |
+-----------------------+-----+
| > | 1 |
+-----------------------+-----+
| < | 2 |
+-----------------------+-----+
table 4: Condition method
</artwork>
</figure>
</t>
</section>
<section anchor="example" title="Examples">
<t>
This section gives a number of short examples with message flows to illustrate the use
of Condition Option in a observe GET request.
</t>
<t>
The first example (Figure 2) shows that the client set the Conditon Option to 1/0/10,
it means that the server shill wait at least 10s between sending
notification responses to the client .
</t>
<figure>
<artwork> <![CDATA[
CLIENT SERVER
| |
| GET/temperature, observe:0,Condition:1/0/10-----> |0s
| |
| |
| <------ 2.05Content,observe:5,payload:22 22|5s
| |
| 22.4|10s
| |
| <------ 2.05Content,observe:15,payload:22.5 22.5|15s
| |
| 23 |20s
| |
| <------ 2.05Content,observe:25,payload:22.8 22.8|25s
| |
Figure 2: Condition Option with value 1/0/10
]]> </artwork>
</figure>
<t>
This example (Figure 3) shows the client set the Conditon Option value to 3/0/1,
it means that the server will send the notification response to the client if the resource
state change bigger than 1.
</t>
<figure>
<artwork> <![CDATA[
CLIENT SERVER
| |
| GET/temperature, observe:0,Condition:3/0/1 -----> |
| |
| |
| <------ 2.05Content,observe:5,payload:22 |22
| |
| |22.5
| |
| <------ 2.05Content,observe:20,payload:23.2 |23.2
| |
| |23.6
| |
| <------ 2.05Content,observe:35,payload:24.3 |24.3
Figure 3: Condition Option with value 3/0/1
]]> </artwork>
</figure>
<t>
This example (Figure 4) shows the client set the Conditon Option value to 4/1/5,
it means that the server will send the notification response to the client only if the
resource value bigger than 5.
</t>
<figure>
<artwork> <![CDATA[
CLIENT SERVER
| |
| GET/temperature, observe:0,Condition:4/1/5 -----> |
| |
| |
| <------ 2.05Content,observe:5,payload:4 |4
| |
| |3
| |
| <------ 2.05Content,observe:25,payload:6 |6
| |
| |4.5
| |
| <------ 2.05Content,observe:25,payload:7 |7
Figure 4: Condition Option with value 4/1/5
]]> </artwork>
</figure>
<t>
This example (Figure 5) shows the client adds two range Conditon Options in the request ,
one sets to 4/1/5, another one sets to 4/2/15 it means that the range is within 5 and 15.
</t>
<figure>
<artwork> <![CDATA[
CLIENT SERVER
| |
| GET/temperature, observe:0,Condition:4/1/5, |
Condition:4/2/15 ----->|
| |
| |
| <------ 2.05Content,observe:5,payload:4 |4
| |
| |3
| |
| <------ 2.05Content,observe:25,payload:12 |12
| |
| |16
| |
| <------ 2.05Content,observe:25,payload:14 |14
Figure 5: Two Condition Option with the same condition type
]]> </artwork>
</figure>
</section>
<section anchor="security" title="Security Considerations">
<t>
As the Condition Option is 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">
<section title="Condition option registry">
<t>
This draft adds the following option number to the CoAP Option
Numbers registry of <xref target='I-D.ietf-core-coap'/>
</t>
<figure>
<artwork>
+--------+---------------+----------------+
| Number | Name | Reference |
+--------+---------------+----------------+
| 22 | Condition | [RFCXXXX] |
+--------+---------------+----------------+
table 5: Condition Option number
</artwork>
</figure>
</section>
<section title="Condition type registry">
<t>
The Condition types defined in this draft are identifed by a string, such as "step".
In order to minimze the overhead of using these condition type, this document defines
a registry for the condition types to be used in CoAP and assigns each a numeric
identifier.
</t>
<t>
Each entry in the registry must include the condition type registered with IANA, the
numeric identifier in the range 0-15 to be used for that condition type in CoAP, and
a reference to a document defining the usage of that condition type.
</t>
<t>
Initial entries in this registry are as follows:
</t>
<t>
<figure>
<artwork>
+-----------------------+-----+-------------+
|Condition type | Id. | Reference |
+-----------------------+-----+-------------+
| minimum response time | 1 |[RFCXXXX] |
+-----------------------+-----+-------------+
| maximum response time | 2 |[RFCXXXX] |
+-----------------------+-----+-------------+
| step | 3 |[RFCXXXX] |
+-----------------------+-----+-------------+
| range | 4 |[RFCXXXX] |
+-----------------------+-----+-------------+
| periodic | 5 |[RFCXXXX] |
+-----------------------+-----+-------------+
table 6: Condition Option type
</artwork>
</figure>
</t>
</section>
<section title="Condition method registry">
<t>
The condition method used in this draft are as follow:
</t>
<t>
<figure>
<artwork>
+-----------------------+-----+-------------+
|Method | Id. | Reference |
+-----------------------+-----+-------------+
| = | 0 |[RFCXXXX] |
+-----------------------+-----+-------------+
| > | 1 |[RFCXXXX] |
+-----------------------+-----+-------------+
| < | 2 |[RFCXXXX] |
+-----------------------+-----+-------------+
table 7: Condition method
</artwork>
</figure>
</t>
</section>
</section>
<section anchor="further" title="Further Considerations">
<section anchor="Resource" title="Resource Discovery">
<t>
The Condition Option enables the establishment of well-defined set of conditional
observations. It is equally important for a resource to be able to announce in a
well-defined way which conditional observations it supports. Clients can then
discover these capabilities and process them automatically.
</t>
<t>
By providing a value to the "obs" attribute defined in
<xref target='I-D.ietf-core-observe'/>, the conditional capabilities of a resource
can be described and discovered.
In order to describe which of the 2^4 possible condition types a resource supports,
a 16-bit value can be used where a bit-value of 1 at position X (from right to left)
indicates that the condition type X is supported.
</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&COAP;
&OBSERVE;
&LINK-FORMAT;
&CORE-INTERFACES;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 18:32:10 |