| CoRE Working Group | C. Ma |
| Internet-Draft | P. Hong |
| Intended status: Standards Track | K. Xue |
| Expires: July 02, 2013 | USTC |
| December 29, 2012 |
Stateful Observation in CoAP
draft-ma-core-stateful-observe-01
The Observe Option allows a CoAP client to observe changes in the state of resources and obtain a current representation of the last resource state. To be an observer of an origin server's resources, the client is required to register its interest with the server. A successful registration will make the client added into the server’s observation list, while a failed one may drive the client to re-register.
However, repeated and frequent re-registrations cannot guarantee the client to eventually become an observer of the target server. In the case that the server is unable or unwilling to accept an observer, the time-intensive re-registrations will just bring redundant messages in the constrained network and considerable energy consumption on both the client and the server.
This memo defines a new CoAP option, State, for providing stateful observation on the resources of CoAP servers. By observing the state of the server in terms of the Observe Option, a client can explicitly learn when the server will not actively reject an observation registration, and then can wisely performs the re-registration. This avoids the potential registration flooding that causes considerable network overhead and energy consumption on the constrained nodes.
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
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."
This Internet-Draft will expire on July 02, 2013.
Copyright (c) 2012 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.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
CoAP [I-D.ietf-core-coap] is an Application Protocol for Constrained Nodes/Networks. The observe [I-D.ietf-core-observe] specification describes a subject/observer pattern to establish an observation relationship between a CoAP client and a CoAP server. In this way, the CoAP client will be notified whenever the state of the observed resource changes. Furthermore, to provide the CoAP client with tailored resources, the conditional observe [ID.li-core-conditional-observe] specification proposes to implement frequently occurring conditional observations by virtue of a new CoAP Condition Option.
In both of the specifications, the client is required to register its interest with the server. A successful registration will make the client added into the server’s observation list, while a failed one may drive the client to re-register. If the registration is frustrated by factors such as network congestion and transmission error, the client still has chances to become an observer by re-registering with the server. In the case that the registration failure results from the target server's incapability or unwillingness, however, time-intensive re-registrations will not work but just cause redundant messages in the constrained network and waste the constrained energy of both the client and the server.
This memo provides a mechanism for CoAP clients to explicitly learn when the server will not actively reject an observation registration, and to wisely perform a re-registration. This is accomplished through a new CoAP option “State”, which defines three states of a CoAP server in terms of the “Observe” option (observation states) as follows.
STATE 0: The CoAP server can add a CoAP client in the observation list;
STATE 1: The CoAP server cannot add a CoAP client in the observation list, but into the candidate queue, which is maintained by the server for notifying the members about the changed observation state;
STATE 2: The CoAP server is unwilling or unable to accept a CoAP client as an observer or a candidate.
A CoAP client who wishes to observe the resources of a CoAP server can add the State Option along with the Observe Option in the initial registration request. If the server is in STATE 0, the client will be successfully added into the observation list and will become an observer of the resources of the server. If the server is in STATE 1, the client will become a candidate, and thus can re-register with the server when it is notified that the server returns to STATE 0. This case is a typical stateful observation pattern as shown in Figure 1. If the server is in STATE 2, the client temporarily quits registering with the server.
Observer Subject
| |
| Register |
+-------------------->|
| |
| State Notification |
|<--------------------+
| |
| State Notification |
|<--------------------+
| |
| Re-register |
+-------------------->|
| |
|Resource Notification|
|<--------------------+
| |
|Resource Notification|
|<--------------------+
| |
Figure 1: Stateful Observation Design Pattern
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
+------+-----+----------+-----------+--------+---------+
| Type | C/E | Name | Data type | Length | Default |
+------+-----+----------+-----------+--------+---------+
| 30 | E | State | uint | 1-2B | (none) |
+------+-----+----------+-----------+--------+---------+
Table 1: State Option Format
The State Option can be presented in both request and response messages. In this document, the State Option MUST be used together with the “Observe” Option and MAY be used with the “Max-age” Option.
0 1 2 3 4 5 6 7 0 1 2
+-+-+-+-+-+-+-+-+-+-+
| TYPE |R| VAL |
+-+-+-+-+-+-+-+-+-+-+
Figure 2: State Option Value
TYPE: The type indicates which option is described by the State Option. In this document, the option number of the described Observe Option is 10, therefore, the type should be 001010. It is set to be a 6-bit integer for option description extension use.
R: The reliability flag indicates whether a state notification needs to be sent in non-confirmable (0) form or in confirmable (1) form.
VAL: The state value that is represented by the VAL flag is used to indicate the state of a CoAP server in terms of an option. For instance, the state values combined with the Observe Option are 0, 1, and 10, referring to the three observation states of an observable CoAP server that are summarized in TABLE 2. The maximal length of VAL is set to be 3 bits for extension use. The VAL part of a State Option in the request message MUST be vacant.
+----------+-----------+--------------------------------+
|State Type|State Value| Indication |
+----------+-----------+--------------------------------+
| 1010 | 0 | Observation list is available |
+----------+-----------+--------------------------------+
| 1010 | 1 |Observation list is unavailable |
| | | Candidate queue is available |
+----------+-----------+--------------------------------+
| 1010 | 10 | Both are unavailable |
+----------+-----------+--------------------------------+
Table 2: State Indication
If a CoAP client is added in the observation list of a CoAP server, it will receive resource notifications as described in [I-D.ietf-core-observe]. If the client is added in the candidate queue, however, it will receive state notifications describing the observation state of the server. A state notification includes an Observe Option, a State Option, a Token Option that matches the token specified by the client in the GET request, and a Max-age Option that indicates the state notification delivery interval, and MAY contains the payload which is in reply to the GET request.
If a CoAP client wants to establish an observation relationship with a CoAP server, it sends a GET request with an Observe Option, a State Option and a Token Option to the server. Specifically, the TYPE of the State Option is 1010, indicating that the client wants to observe the observation state of the server, and the VAL part of the State Option in the request message MUST be vacant.
A CoAP server keeps an observation list and a candidate queue. When the CoAP server receives the request, it performs as follows.
It firstly checks the state of its observation list and the candidate queue.
If the server is in STATE 0, it adds the client in the observation list, and responds as the same way described in [I-D.ietf-core-observe], which excludes the State Option.
If the server is in STATE 1, it adds the client in the candidate queue and sends a response containing the payload in reply to the GET request, the Observe Option, the Token Option, the Max-age Option, and the State Option with the TYPE part of 1010 and the VAL part of 1. Note that the Max-age Option is set for indicating the life time of a state notifications, rather than the payload, and its default value is 60s.
If the server is in STATE 2, it sends a response containing the payload in reply to the GET request, the Observe Option, the Token Option, and the State Option with the TYPE part of 1010 and the VAL part of 10. The client will not be added into the candidate queue and will not receive subsequent state notifications.
The server MUST chooses an appropriate max-age for the state notification. The value of the max-age should be larger than that in the resource notifications.
The server sends the state notification with the VAL part of 1 to the observation candidates whenever the last state notification has been sent over the max-age, and notifies the candidates when its observation state changes to be State 0.
Upon receiving the state notification with the VAL part of 0, the candidate re-registers with the server by sending a GET request with the Observe Option, the State Option and a new token.
The number (n) of the responsive candidates MAY be larger than that (N) of the observers the server can additionally add in the list. In this case, the server just simply chooses the top N candidates whose responses are firstly received by it. The rest n-N responders still stay in the candidate queue. A former candidate learns whether the former re-registration succeeds through the subsequent notification. Namely, a subsequent rescoure notification indicates a successful re-registration, while a subsequent state notification indicates a failed re-registration.
When a CoAP client wants to leave the observation list, it follows the operations in [I-D.ietf-core-observe]. If the client wants to leave the candidate queue, it can reject a confirmable notification with a RST message or perform a GET request without the State Option and the Observe Option for a currently observed state. In both of the two cases, the server will remove the client from the candidate queue.
The dismission of an observer is the same as that in [I-D.ietf-core-observe]. If the server wants to dismiss a candidate, it SHOULD set the VAL part of the state notification to be 10 and choose a large max-age for the state notification. Otherwise, the server SHOULD NOT send the state notification with the VAL part of 10 to the candidates.
It is possible that there is an intermediary between an origin server and the CoAP client that is interested in a resource in the namespace of the server. In this case, the client registers its interest with the intermediary towards the origin server, acting as if it was communicating with the origin server itself as specified in Section 3. The intermediary provides the client with a current representation of the target resource and sends (state) notifications upon changes to the resource (or observation) state, as an origin server as specified in Section 3. To accomplish this, the intermediary SHOULD make use of the protocol specified in this document, taking the role of the client and registering its own interest in the target resource with the original server.
If there is more than one CoAP-to-CoAP intermediary between the CoAP client and the origin server, the first intermediary towards the origin server is in charge of providing the client with a current representation of the target resource and sends (state) notifications upon changes to the resource (or observation) state, as an origin server as specified in Section 3. The intermediary transmits the GET request from the client hop by hop. If the next hop does not return a response with an Observe Option, the intermediary MAY resort to polling the next hop, or MAY itself return a response without an Observe Option. The last intermediary towards the server transmits the request to the server as if it is the client, or responds to the request with the storage in its cache.
Additionally, the intermediary can also register in several target resources with the original servers that it can directly reach, and keep its own cache up to date. Whenever there is a GET request with an Observe Option and a State Option from the client (or other intermediary), the intermediary responds to the client with the storage in its cache.
This section gives a number of examples to illustrate the use of State Option in a GET request.
The first example (Figure 3) shows that a registration that is carried in the GET request with Observe Option and State Option makes the client added in the observation list of the server. The client receives resource notifications of the current state and upon a state change.
Observed CLIENT SERVER Resource Observation
content State State
________ | | ________ _____
| |
unknown | | 20.6 C list
+--------->| Header: GET 0x43011633
| GET | Token: 0x4a
| | Uri-Path: temperature
| | Observe: 0
| | State:
| |
________ |<---------+ Header: 2.05 0x63451633
| 2.05 | Token: 0x4a
20.6 C | | Observe: 8
| | Max-Age: 20
| | Payload: "20.6 C"
| | ________ _____
| |
________ |<---------+ 18.9 C list
| 2.05 | Header: 2.05 0x53457b50
18.9 C | | Token: 0x4a
| | Observe: 16
| | Max-Age: 20
| | Payload: "18.9 C"
| |
Figure 3: The client is added in the observation list after a registration
The example in Figure 4 shows that a registration that is carried in the GET request with Observe Option and State Option makes the client added into the candidate queue of the server. The client receives a state notification of the current observation state and upon a state change. When the client learns the server is in STATE 0 through the state notification, the client re-registers with the server and then is added into the observation list.
Observed CLIENT SERVER Resource Observation
content State State
________ | | ________ _____
| |
unknown | | 20.6 C queue
+--------->| Header: GET 0x43011633
| GET | Token: 0x4a
| | Uri-Path: temperature
| | Observe: 0
| | State:
| |
________ |<---------+ Header: 2.05 0x63451633
| 2.05 | Token: 0x4a
1 | | Observe: 8
20.6 C | | Max-Age: 40
| | State: 1
| | ________ _____ Payload: "20.6 C"
| |
| | 18.9 C list
________ |<---------+ Header: 2.03 0x53457b50
| 2.03 | Token: 0x4a
0 | | Observe: 16
20.6 C | | Max-Age: 40
| | State: 0
| |
+--------->| Header: GET 0x43021634
| GET | Token: 0xa1
| | Uri-Path: temperature
| | Observe: 23
| | State:
| |
________ |<---------+ Header: 2.05 0x64451733
| 2.05 | Token: 0xa1
18.9 C | | Observe: 31
| | Max-Age: 20
| | Payload: “18.9 C”
| |
Figure 4: The client is added into the candidate queue after the initial registration and is added into the observation list after the re-registration
This example (Figure 5) shows that the client that is in the candidate queue hasn’t received a state notification over a max-age time of 40s, and thus re-registers with the server.
Observed CLIENT SERVER Resource Observation
content State State
________ | | ________ _____
| |
1 | | 20.6 C queue
19.7 C | |
| | ________ _____
| |
| | 18.9 C list
| X-------+ Header: 2.03 0x53457b50
| 2.03 | Token: 0x4a
| | Observe: 16
| | Max-Age: 40
| | State: 0
________ | |
+--------->| Header: GET 0x43011633
1 | GET | Token: 0xb4
19.7 C | | Uri-Path: temperature
| | Observe: 27
| | ________ _____ State:
| |
________ |<---------+ 19.4 C list Header: 2.05 0x63451633
| 2.05 | Token: 0xb4
19.4 C | | Observe: 31
| | Max-Age: 40
| | Payload: “19.4 C”
| |
Figure 5: The client re-registers after Max-Age ends
The example in Figure 6 shows that a proxy registers its interest with the server, and receives state notifications to keep its cache up to date. The client gets state notification from the proxy and registers with the server (via the proxy) when the server returns to State 0.
CLIENT PROXY SERVER
| | |
| +------>| Header: GET 0x44015fb8
| | GET | Token: 0x1a
| | | Uri-Host: sensor.example
| | | Uri-Path: temperature
| | | Observe: 0
| | | State:
| | |
| |<------+ Header: 2.05 0x63455fb8
| | 2.05 | Token: 0x1a
| | | Observe: 32
| | | Max-Age: 60
| | | State: 1
| | | Payload: "19.4 C"
| | |
| |<------+ Header: 2.03 0x63455f56
| | 2.03 | Token: 0x1a
| | | Observe: 40
| | | Max-Age: 60
| | | State: 0
| | |
| +------>| Header: GET 0x42011663
| | GET | Token: 0x3b
| | | Uri-Host: sensor.example
| | | Uri-Path: temperature
| | | Observe: 45
| | | State:
| | |
| <-------+ Header: 2.05 0x64451733
| | 2.05 | Token: 0x3b
| | | Observe: 49
| | | Max-Age: 30
| | | Payload: "18.9 C"
| | |
+------>| | Header: GET 0x42011633
| GET | | Token: 0x9a
| | | Proxy-Uri: coap://sensor.example/temperature
| | | Observe: 52
| | | State:
| | |
|<-----+| | Header: 2.03 0x62451633
| 2.05 | | Token: 0x9a
| | | Observe: 56
| | | Max-Age: 25
| | | Payload: "18.9 C"
| | |
Figure 6: A proxy registers with the server and receives state notification to keep its cache up to date
The amplification attacks towards observing the observation state are more mitigatory compared to observing resources, since the state notification has smaller message size and lower frequency than a resource notification due to the lack of resource representation payload and a larger max-age. Nonetheless, to further reduce the harmful effects caused by the amplification attacks, the state notifications sent in non-confirmable messages are recommended to be interspersed with confirmable messages.
Spoofing (state) notifications or RST in the response to a (state) notification in a CON message, MAY make a client “deaf”. For instance, if a state notification with “VAL=0” is tampered by the spoofing attacker to be a state notification with “VAL=10” and a large max-age, the client will be spoofed to be waiting for a long time. This kind of attack can be prevented using security modes other than NoSec.
+--------+---------+-----------+
| Number | Name | Reference |
+--------+---------+-----------+
| 30 | State | [RFCXXXX] |
+--------+---------+-----------+
The following entries are added to the CoAP Option Numbers registry of [I-D.ietf-core-coap]:
Thanks to the support from the National Science and Technology Major Project of China under Grant No.2011ZX03005-006.
Changed from draft-00 to draft-01:
Added the description of max-age. Section 3.4
Changed the description of cancellation. Section 3.5
| [I-D.ietf-core-coap] | Shelby, Z, Hartke, K, Bormann, C and B Frank, "Constrained Application Protocol (CoAP)", Internet-Draft draft-ietf-core-coap-10, June 2012. |
| [I-D.ietf-core-observe] | Hartke, K, "Observing Resources in CoAP", Internet-Draft draft-ietf-core-observe-05, March 2012. |
| [I-D.li-core-conditional-observe] | Li, S, Hoebeke, J and A Jara, "Conditional observe in CoAP", Internet-Draft draft-li-core-conditional-observe-02, June 2012. |