One document matched: draft-li-core-conditional-observe-00.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'>
]>
<?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-00">
<front>
<title abbrev="Conditioanal observe in CoAP">
Conditioanal 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>
<date year="2012" />
<area>Applications</area>
<workgroup>core</workgroup>
<abstract>
<t>
CoAP is a RESTful application protocol for constrained nodes and
networks. This document defines a new mechanism in CoAP Observe so that a CoAP
client can conditional observe a resource on a CoAP server.
</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 using the subject/observer design pattern to establish the observation
relationship. When observe used, the CoAP client can get the notification response
whenever the state changed of the observed resource, however, in some scenarios,
the CoAP client may only care parts of the state change of the resource, other
state change 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 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>
<section anchor="over" title="overview">
<t>
A GET request that includes an Observe Option creates an observation relationship.
When a server receives such a request, it firt 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 senor only
responses with what the client wants.
</t>
<t>
Let's see an example here,
</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 worked as a server, and it collect the resource data every
5 seconds, when the client observe a resource on the server, it will receive the
response whenever the server update the resource, that is to say, mostly every 5 seconds
the clients 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 such often. One possible solution we can do is to change the
sensor's parameter, for example, shorten the collecting frequency, but the sensor could
provide services for many other clients, it is hard to fine the best configuration so it
can fit all the requirements.
</t>
<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="requ" title="Requirements">
<t>
As a summary, here is the required functionality to solve the presented issues:
</t>
<t>
REQ 1: It must be possible to include the client's requirements into an observe
request
</t>
</section>
<section anchor="overview" title="Overview of Operation">
<t>
Whenever a client initiates an Observation relationship, it sends a GET request with a
Condition Option (see section 5 for the option definition). The Condition option includes
the condition required by the client, it can be the desired minimum response time, or the
minimum step change(see section 6 for the definition of condition type) . When a server
receive such a request, it first services the request the same way as described in observe
draft<xref target='I-D.ietf-core-observe'/> that established an observation relationship
between the client and the target resource.Then if the server supports the Condition option,
it needs to analyze the Condition option to find the requirements by the client.
</t>
<t>
For example,
</t>
<t>
condition: 1/0/10
</t>
<t>
Whenever the resource state changed on the server, it needs to check the condition, only
when it meet, the server shall send the notification response to the
client, otherwise, 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 Observe option.
</t>
<t>
The condition Option, when present together with the observe request, it represent the
condition required by the client. The server needs to follow the general procedure as
described in observe draft<xref target='I-D.ietf-core-observe'/> but take 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 type defined in this documents are as follows:
</t>
<t>
The size of the condition option is not fixed by the protocol.The value of the defined
condition type can be ranged from 0 to 2^4 (16), and from 0 to 2^12(4096), and from 0
to 2^20(1048576), it all depends on the implementation to choose.
</t>
<t>
The Condition option may occur more than once, when multiple Condition options present in an
observe GET request, it means that the initiator has multiple condition requirements, and the
first condition option shows in the request has the highist proiority.
</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 indicate the type of
the condition that used in the observe request. Each number of TYPE represent the
type ID of a specific condition type, for example, "1" represents the minium response time,
"2" represent the step.Blow has the further definition of the condition type.
</t>
<t>
M: method. the method is a 2 bit intrger indicate the method used in the condition.
Blow has the further definition of the method attribute.
</t>
<t>
VAL: condition value. is a variable-size(4,12, or 20 bit) unsigned integer indicate the value of the
condition.
</t>
<t>
<figure>
<artwork>
+-----------------------+-----+
|Condition type | Id. |
+-----------------------+-----+
| minium response time | 1 |
+-----------------------+-----+
| step | 2 |
+-----------------------+-----+
| range | 3 |
+-----------------------+-----+
table 3: Condition Option type
</artwork>
</figure>
</t>
<t>
minium response time: When present, it indicates that the condition required by the
initiator is the minium response time. The value of the minium response time is
set in the payload of the request.This condition indicates the minimum 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. Its value is set in the payload of the request.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>
If multiple conditions with the same condition type present in a request, the priority is the same, and
the relationship is "AND".
</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>
The second example (Figure 3) shows the client set the Conditon option value to 2/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:2/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 2/0/1
]]> </artwork>
</figure>
<t>
The third example (Figure 4) shows the client set the Conditon option value to 3/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:3/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 3/1/5
]]> </artwork>
</figure>
<t>
The fourth example (Figure 5) shows the client adds two range Conditon options in the request ,
one sets to 3/1/5, another one sets to 3/2/15 it means that the range is within 5 and 15.
</t>
<figure>
<artwork> <![CDATA[
CLIENT SERVER
| |
| GET/temperature, observe:0,Condition:3/1/5, |
Condition:3/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 used
it must follow the secutity considertions 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 |
+-----------------------+-----+-------------+
| minium response time | 1 |[RFCXXXX] |
+-----------------------+-----+-------------+
| step | 2 |[RFCXXXX] |
+-----------------------+-----+-------------+
| range | 3 |[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>
<section anchor="Acknowledgements" title="Acknowledgements">
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&COAP;
&OBSERVE;
&LINK-FORMAT;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 18:35:03 |