Observing Resources in CoAP
draft-ietf-core-observe-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7641.
|
|
|---|---|---|---|
| Author | Klaus Hartke | ||
| Last updated | 2011-02-07 (Latest revision 2010-10-18) | ||
| Replaces | draft-hartke-coap-observe | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 7641 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Peter Saint-Andre | ||
| Send notices to | core-chairs@tools.ietf.org, draft-ietf-core-observe@tools.ietf.org |
draft-ietf-core-observe-04
8. Security Considerations
The security considerations of RFC XXXX [I-D.ietf-core-coap] apply.
Note that the considerations about amplification attacks are somewhat
amplified when observing resources. In NoSec mode, a server MUST
therefore strictly limit the number of notifications that it sends
between receiving acknowledgements that confirm the actual interest
of the client in the data; i.e., any notifications sent in non-
confirmable messages MUST be interspersed with confirmable messages.
(An attacker may still spoof the acknowledgements if the confirmable
messages are sufficiently predictable.)
As with any protocol that creates state, attackers may attempt to
exhaust the resources that the server has available for maintaining
the list of observers for each resource. Servers MAY want to access-
control this creation of state. As degraded behavior, the server can
always fall back to processing the request as a normal GET request
(without an Observe Option) if it is unwilling or unable to add a
client to the list of observers of a resource, including if system
resources are exhausted or nearing exhaustion.
Intermediaries MUST be careful to ensure that notifications cannot be
employed to create a loop. A simple way to break any loops is to
employ caches for forwarding notifications in intermediaries.
9. IANA Considerations
The following entries are added to the CoAP Option Numbers registry:
+--------+---------+-----------+
| Number | Name | Reference |
+--------+---------+-----------+
| 10 | Observe | [RFCXXXX] |
+--------+---------+-----------+
10. Acknowledgements
Carsten Bormann was an original author of this draft and is
acknowledged for significant contribution to this document.
Thanks to Daniele Alessandrelli, Jari Arkko, Peter Bigot, Angelo
Castellani, Gilbert Clark, Esko Dijk, Thomas Fossati, Brian Frank,
Cullen Jennings, Salvatore Loreto, Charles Palmer and Zach Shelby for
helpful comments and discussions that have shaped the document.
Hartke Expires August 17, 2012 [Page 15]
Internet-Draft Observing Resources in CoAP February 2012
Klaus Hartke was funded by the Klaus Tschira Foundation.
11. References
11.1. Normative References
[I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
draft-ietf-core-block-07 (work in progress), January 2012.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-08 (work in progress), October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
11.2. Informative References
[GOF] Gamma, E., Helm, R., Johnson, R., and J. Vlissides,
"Design Patterns: Elements of Reusable Object-Oriented
Software", Addison-Wesley, Reading, MA, USA,
November 1994.
[I-D.ietf-core-link-format]
Shelby, Z., "CoRE Link Format",
draft-ietf-core-link-format-11 (work in progress),
January 2012.
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000, <http://
www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC5989] Roach, A., "A SIP Event Package for Subscribing to Changes
to an HTTP Resource", RFC 5989, October 2010.
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
Hartke Expires August 17, 2012 [Page 16]
Internet-Draft Observing Resources in CoAP February 2012
"Known Issues and Best Practices for the Use of Long
Polling and Streaming in Bidirectional HTTP", RFC 6202,
April 2011.
Appendix A. Examples
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
1 | |
2 unknown | | 18.5 C
3 +----->| Header: GET 0x43011633
4 | GET | Token: 0x4a
5 | | Uri-Path: temperature
6 | | Observe: 0
7 | |
8 | |
9 ____________ |<-----+ Header: 2.05 0x64451633
10 | 2.05 | Token: 0x4a
11 18.5 C | | Observe: 9
12 | | Max-Age: 15
13 | | Payload: "18.5 C"
14 | |
15 | | ____________
16 ____________ |<-----+ Header: 2.05 0x54457b50
17 | 2.05 | 19.2 C Token: 0x4a
18 19.2 C | | Observe: 16
29 | | Max-Age: 15
20 | | Payload: "19.2 C"
21 | |
Figure 3: A client registers and receives a notification of the
current state and upon a state change
Hartke Expires August 17, 2012 [Page 17]
Internet-Draft Observing Resources in CoAP February 2012
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
22 | |
23 19.2 C | | 19.2 C
24 | | ____________
25 | X----+ Header: 2.05 0x54457b51
26 | 2.05 | 19.7 C Token: 0x4a
27 | | Observe: 25
28 | | Max-Age: 15
29 | | Payload: "19.7 C"
30 | |
31 ____________ | |
32 +----->| Header: GET 0x43011633
33 19.2 C | GET | Token: 0xb2
34 (stale) | | Uri-Path: temperature
35 | | Observe: 0
36 | |
37 | |
38 ____________ |<-----+ Header: 2.05 0x55457b52
39 | 2.05 | Token: 0xb2
40 19.7 C | | Observe: 38
41 | | Max-Age: 15
42 | | ETag: 0x78797a7a79
43 | | Payload: "19.7 C"
44 | |
Figure 4: The client re-registers after Max-Age ends
Hartke Expires August 17, 2012 [Page 18]
Internet-Draft Observing Resources in CoAP February 2012
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
45 | |
46 19.7 C | | 19.7 C
47 | |
48 | | ____________
49 | CRASH
50 |
51 |
52 | |
53 ____________ | | ____________
54 +----->| Header: GET 0x44011634
55 19.7 C | GET | 20.0 C Token: 0xf9
56 (stale) | | Uri-Path: temperature
57 | | Observe: 0
58 | | ETag: 0x78797a7a79
59 | |
60 | |
61 ____________ |<-----+ Header: 2.05 0x64451634
62 | 2.05 | Token: 0xf9
63 20.0 C | | Observe: 61
64 | | Max-Age: 15
65 | | Payload: "20.0 C"
66 | |
67 | | ____________
68 ____________ |<-----+ Header: 2.03 0x5543aa0c
69 | 2.03 | 19.7 C Token: 0xf9
70 19.7 C | | Observe: 68
71 | | ETag: 0x78797a7a79
72 | | Max-Age: 15
73 | |
Figure 5: The client re-registers and gives the server the
opportunity to select a stored response
Hartke Expires August 17, 2012 [Page 19]
Internet-Draft Observing Resources in CoAP February 2012
A.1. Proxying
CLIENT PROXY SERVER
| | |
| +----->| Header: GET 0x44015fb8
| | GET | Token: 0x1a
| | | Uri-Host: sensor.example
| | | Uri-Path: status
| | | Observe: 0
| | |
| |<-----+ Header: 2.05 0x64455fb8
| | 2.05 | Token: 0x1a
| | | Observe: 42
| | | Max-Age: 60
| | | Payload: "ready"
| | |
+----->| | Header: GET 0x42011633
| GET | | Token: 0x9a
| | | Proxy-Uri: coap://sensor.example/status
| | |
|<-----+ | Header: 2.05 0x62451633
| 2.05 | | Token: 0x9a
| | | Max-Age: 53
| | | Payload: "ready"
| | |
| |<-----+ Header: 2.05 0x544505fc0
| | 2.05 | Token: 0x1a
| | | Observe: 135
| | | Max-Age: 60
| | | Payload: "busy"
| | |
+----->| | Header: GET 0x42011634
| GET | | Token: 0x9b
| | | Proxy-Uri: coap://sensor.example/status
| | |
|<-----+ | Header: 2.05 0x62451634
| 2.05 | | Token: 0x9b
| | | Max-Age: 49
| | | Payload: "busy"
| | |
Figure 6: A proxy observes a resource to keep its cache up to date
Hartke Expires August 17, 2012 [Page 20]
Internet-Draft Observing Resources in CoAP February 2012
CLIENT PROXY SERVER
| | |
+----->| | Header: GET 0x43011635
| GET | | Token: 0x6a
| | | Proxy-Uri: coap://sensor.example/status
| | | Observe: 0
| | |
|<- - -+ | Header: 0x60001635
| | |
| +----->| Header: GET 0x4401af90
| | GET | Token: 0xaa
| | | Uri-Host: sensor.example
| | | Uri-Path: status
| | | Observe: 0
| | |
| |<-----+ Header: 2.05 0x6445af90
| | 2.05 | Token: 0xaa
| | | Observe: 67
| | | Max-Age: 60
| | | Payload: "ready"
| | |
|<-----+ | Header: 2.05 0x4445af94
| 2.05 | | Token: 0x6a
| | | Observe: 17346
| | | Max-Age: 60
| | | Payload: "ready"
| | |
+- - ->| | Header: 0x6000af94
| | |
| |<-----+ Header: 2.05 0x54455a20
| | 2.05 | Token: 0xaa
| | | Observe: 157
| | | Max-Age: 60
| | | Payload: "busy"
| | |
|<-----+ | Header: 2.05 0x5445af9b
| 2.05 | | Token: 0x6a
| | | Observe: 17436
| | | Max-Age: 60
| | | Payload: "busy"
| | |
Figure 7: A client observes a resource through a proxy
Hartke Expires August 17, 2012 [Page 21]
Internet-Draft Observing Resources in CoAP February 2012
A.2. Block-wise Transfer
CLIENT SERVER
| |
+----->| Header: GET 0x43011636
| GET | Token: 0xfb
| | Uri-Path: status-icon
| | Observe: 0
| |
|<-----+ Header: 2.05 0x65451636
| 2.05 | Token: 0xfb
| | Block2: 0/1/128
| | Observe: 62354
| | Max-Age: 60
| | Payload: [128 bytes]
| |
|<-----+ Header: 2.05 0x5545af9c
| 2.05 | Token: 0xfb
| | Block2: 1/0/128
| | Observe: 62354
| | Max-Age: 60
| | Payload: [27 bytes]
| |
|<-----+ Header: 2.05 0x5545af9d
| 2.05 | Token: 0xfb
| | Block2: 0/1/128
| | Observe: 62444
| | Max-Age: 60
| | Payload: [128 bytes]
| |
|<-----+ Header: 2.05 0x5545af9e
| 2.05 | Token: 0xfb
| | Block2: 1/0/128
| | Observe: 62444
| | Max-Age: 60
| | Payload: [27 bytes]
| |
Figure 8: A server sends two notifications of two blocks each
Appendix B. Modeling Resources to Tailor Notifications
A server may want to provide notifications that respond to very
specific conditions on some state. This is best done by modeling the
resources that the server exposes according to these needs.
For example, for a CoAP server with an attached temperature sensor,
Hartke Expires August 17, 2012 [Page 22]
Internet-Draft Observing Resources in CoAP February 2012
o the server could, in the simplest form, expose a resource
<coap://server/temperature> that changes its state every second to
the current temperature measured by the sensor;
o the server could, however, also expose a resource
<coap://server/temperature/felt> that changes its state to "cold"
when the temperature drops below a preconfigured threshold, and to
"warm" when the temperature exceeds a second, higher threshold;
o the server could expose a parameterized resource
<coap://server/temperature/critical?above=45> that changes its
state to the current temperature if the temperature exceeds the
specified value, and changes its state to "OK" when the
temperature drops below; or
o the server could expose a parameterized resource <coap://server/
temperature?query=select+avg(temperature)+from+
Sensor.window:time(30sec)> that accepts expressions of arbitrary
complexity and changes its state accordingly.
In any case, the client is notified about the current state of the
resource whenever the state of the appropriately modeled resource
changes. By designing resources that change their state on certain
conditions, it is possible to notify the client only when these
conditions occur instead of continuously supplying it with
information it doesn't need. With parametrized resources, this is
not limited to conditions defined by the server, but can be extended
to arbitrarily complex conditions defined by the client. Thus, the
server designer can choose exactly the right level of complexity for
the application envisioned and devices used, and is not constrained
to a "one size fits all" mechanism built into the protocol.
Appendix C. Changelog
Changes from ietf-03 to ietf-04:
o Removed the "Max-OFE" Option.
o Allowed RST in reply to non-confirmable notifications.
o Added a section on cancellation.
o Updated examples.
Changes from ietf-02 to ietf-03:
Hartke Expires August 17, 2012 [Page 23]
Internet-Draft Observing Resources in CoAP February 2012
o Separated client-side and server-side requirements.
o Fixed uncertainty if client is still on the list of observers by
introducing a liveliness model based on Max-Age and a new option
called "Max-OFE" (#174).
o Simplified the text on message reordering (#129).
o Clarified requirements for intermediaries.
o Clarified the combination of block-wise transfers with
notifications (#172).
o Updated examples to show how the state observed by the client
becomes eventually consistent with the actual state on the server.
o Added examples for parameterization of observable resource.
Changes from ietf-01 to ietf-02:
o Removed the requirement of periodic refreshing (#126).
o The new "Observe" Option replaces the "Lifetime" Option.
o Introduced a new mechanism to detect message reordering.
o Changed 2.00 (OK) notifications to 2.05 (Content) notifications.
Changes from ietf-00 to ietf-01:
o Changed terminology from "subscriptions" to "observation
relationships" (#33).
o Changed the name of the option to "Lifetime".
o Clarified establishment of observation relationships.
o Clarified that an observation is only identified by the URI of the
observed resource and the identity of the client (#66).
o Clarified rules for establishing observation relationships (#68).
o Clarified conditions under which an observation relationship is
terminated.
o Added explanation on how clients can terminate an observation
relationship before the lifetime ends (#34).
Hartke Expires August 17, 2012 [Page 24]
Internet-Draft Observing Resources in CoAP February 2012
o Clarified that the overriding objective for notifications is
eventual consistency of the actual and the observed state (#67).
o Specified how a server needs to deal with clients not
acknowledging confirmable messages carrying notifications (#69).
o Added a mechanism to detect message reordering (#35).
o Added an explanation of how notifications can be cached,
supporting both the freshness and the validation model (#39, #64).
o Clarified that non-GET requests do not affect observation
relationships, and that GET requests without "Lifetime" Option
affecting relationships is by design (#65).
o Described interaction with block-wise transfers (#36).
o Added Resource Discovery section (#99).
o Added IANA Considerations.
o Added Security Considerations (#40).
o Added examples (#38).
Author's Address
Klaus Hartke
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63905
Fax: +49-421-218-7000
Email: hartke@tzi.org
Hartke Expires August 17, 2012 [Page 25]