idnits 2.17.1 draft-fossati-core-monitor-option-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2012) is 4280 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 201, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-10 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-05 ** Downref: Normative reference to an Informational draft: draft-shelby-core-coap-req (ref. 'I-D.shelby-core-coap-req') Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Fossati 3 Internet-Draft KoanLogic 4 Intended status: Standards Track P. Giacomin 5 Expires: January 10, 2013 Freelance 6 S. Loreto 7 Ericsson 8 July 9, 2012 10 Monitor Option for CoAP 11 draft-fossati-core-monitor-option-00 13 Abstract 15 This memo defines Monitor, an additional Option for the Constrained 16 Application Protocol (CoAP) especially targeted at sleepy sensors. 18 The Monitor Option complements the typical Observe pattern, enabling 19 the tracking of a resource hosted by a node sleeping most of the 20 time, by taking care of establishing and maintaining an Observe 21 relationship with the (sleepy) origin on behalf of the (sleepy) 22 client. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 10, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language and Motivation . . . . . . . . . . . 3 60 2. Monitor Option . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Public Monitor Registration . . . . . . . . . . . . . . . . 4 62 2.2. Monitor De-registration . . . . . . . . . . . . . . . . . . 6 63 2.2.1. Explicit De-registration . . . . . . . . . . . . . . . 6 64 2.2.2. Implicit De-registration . . . . . . . . . . . . . . . 6 65 2.3. Resource Refresh . . . . . . . . . . . . . . . . . . . . . 6 66 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 6. Normative References . . . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 The proposal described in this memo covers the following use case: a 75 node N, which is sleeping most of the time, depends on one or more 76 resources hosted at another sleepy node M. In cases as such, the 77 probability of an empty intersection between their respective wake 78 periods is very high, making it hard for the two to synchronize. 80 In this scenario, using the basic observe [I-D.ietf-core-observe] 81 functionality is not enough, as it could lead to lost state updates 82 in case N is offline while M pushes its notifications; further, the 83 observation may never bootstrap since its initialization needs both 84 client and origin awake at the same time. 86 This memo introduces an extension to the Proxy caching functionality 87 that give the Proxy an explicit mediation role in the sleepy-to- 88 sleepy CoAP [I-D.ietf-core-coap] communication. 90 1.1. Requirements Language and Motivation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 This specification makes use of the following terminology: 98 Sleepy Device: a sensor/actuator (usually battery operated) that 99 powers down its radio beyond the normal radio duty cycle in order 100 to save energy. 102 and tries to provide an in-protocol solution for requirement REQ3 in 103 [I-D.shelby-core-coap-req]: 105 The ability to deal with sleeping nodes. Devices may be 106 powered down at any point in time but periodically "wake up" 107 for brief periods of time. 109 2. Monitor Option 111 +-----+----------+---------+--------+--------+---------+ 112 | No. | C/E | Name | Format | Length | Default | 113 +-----+----------+---------+--------+--------+---------+ 114 | XX | Critical | Monitor | (none) | 0 B | (none) | 115 +-----+----------+---------+--------+--------+---------+ 117 The Monitor Option is a variant of the Observe Option that is aimed 118 at solving some issues that may occur when sleepy sensors are 119 involved. 121 Suppose that the resource of interest is not cached anywhere, and a 122 sleepy endpoint wants to Observe it through a Proxy. If the origin 123 of the requested resource is sleeping at the time the observation is 124 requested, the requesting node gets an error, and may need to stay 125 awake and retry until the target node gets ready -- which is clearly 126 not an option in case the sensor has a very small duty cycle. 128 The Monitor Option is used to ask a Proxy to keep a given resource 129 fresh by observing it, while the requesting node is sleeping. Thus 130 the sleepy sensor can possibly get the latest representation 131 published by the monitored resource when it wakes up, even if the 132 origin is sleeping -- and was sleeping at the time the Monitor has 133 been requested. 135 The Monitor Option is critical and MUST be present in the request 136 only. If the Proxy does not recognize it, a 4.02 (Bad Option) MUST 137 be returned to the client. 139 2.1. Public Monitor Registration 141 P C 142 | POST | Proxy-URI: coap://sleepy.example.org/res 143 |<-------+ Monitor: 144 | | Max-Age: 86400 145 | | Content-Type: application/json 146 | 2.01 | 147 +------->| Location-Path: temp 148 | | Location-Path: res 149 | | 151 Figure 1 153 The client POST's the resource to be monitored, identified by the 154 Proxy-URI. The request message contains an empty Monitor Option, and 155 possibly specifies a TTL (i.e. an implicit de-registration 156 indication) for the monitor through Max-Age. One or more content 157 types for the acceptable representations of the resource are 158 optionally specified via the Accept option. In case no TTL is 159 supplied, a default value of 3600 seconds is assumed. 161 The operation creates a "monitor" resource at the Proxy, that MUST 162 maintain a fresh carbon copy of one or more representations of the 163 requested resource depending on the supplied Content-Type. For 164 convenience, multiple "monitor" resources corresponding to the same 165 target resource, can be coalesced into the same monitor object at the 166 Proxy -- possibly with the same URI. In such case, a set containing 167 one entry for each registered client is kept, which holds the client 168 identities, their expiry and one or more preferred media types for 169 their representation(s). When all entries are deleted (either 170 because clients have explicitly deregistered the monitor, or the 171 monitor period has expired), the corresponding "monitor" object is 172 deleted. Note that an underlying cache entry MAY still be kept in 173 case the cached representation(s) are still fresh (i.e. the Max-Age 174 of the "monitor" resource and Max-Age of the target resource have 175 completely different semantics.) 177 If the monitor resource is successfully created, the server MUST 178 return a 2.01 response containing one or more Location-Path and/or 179 Location-Query Options to identify the monitored resource instance, 180 which can be used from now on by the requester as an alias to the 181 target resource. 183 At a later time, the client wakes up and wants to access the 184 monitored resource. It does so by requesting the Proxy monitor 185 resource that has been previously created. 187 P C 188 | GET | URI-Path: temp 189 |<-------+ URI-Path: res 190 | | Accept: application/json 191 | | 192 | 2.05 | 193 +------->| (Content) 194 | | 195 | | 197 Figure 2 199 In case the observation on the target node has not been started 200 because the Proxy has not yet been able to contact the origin, the 201 Proxy will return a [TBD] error code. 203 In case the requested resource was not present on the origin, the 204 Proxy will return an empty response (i.e. one with no payload.) 206 [[XXX: add an explicit response code perhaps like HTTP 204 ?]] 208 In case the monitor resource is not found in the Proxy, either 209 because the Proxy has rebooted and lost its state, or the monitor 210 resource has been de-registered (see Section 2.2), a 4.04 response 211 code is returned to the client -- that can recreate it, if needed. 213 2.2. Monitor De-registration 215 The monitor object MUST be deleted at the Proxy when all its 216 associated resources have been de-registered or have expired. 218 In order to save storage, a Proxy MAY decide to delete a monitor 219 resource in case it has not been requested for a sufficiently long 220 time, or for any other reason. Note that the Proxy may also reboot 221 and lose its state, including the state associated to any monitored 222 resource. The requester can realize that the state at the Proxy has 223 been lost, and re-instantiate the monitor, when it receives an 224 unexpected 4.04 from the "monitor" resource. 226 2.2.1. Explicit De-registration 228 P C 229 | DELETE | Path: temp 230 |<-------+ Path: res 231 | | 232 | 2.02 | 233 +------->| 234 | | 236 Figure 3 238 Explicit de-registration is performed by a client, with a DELETE on 239 the URI returned by the Proxy on the corresponding registration. 241 2.2.2. Implicit De-registration 243 Implicit de-registration MUST occur when the monitoring period 244 specified by the client via Max-Age expires. If no Max-Age was 245 supplied at registration time, a default of 3600 seconds MUST be 246 assumed. 248 2.3. Resource Refresh 250 In order to minimize the number of messages used by the monitoring 251 process, the Proxy MUST try to install an observation on the 252 requested resource. In case this first attempt fails, the Proxy MAY 253 fall back to repeated poll whose duration is upper bounded by the 254 Max-Age value indicated by the client during registration. 256 Usual cache validation MUST be applied to the cached copy of the 257 monitored resource. 259 3. Acknowledgements 261 Bruce Nordman and Matthieu Vial for discussing and giving advice on 262 some of the ideas contained in this document. 264 4. IANA Considerations 266 The following entries are added to the CoAP Option Numbers registry: 268 .------------------------------. 269 | Number | Name | Reference | 270 :--------:---------:-----------: 271 | 2m+1 | Monitor | RFC XXXX | 272 `------------------------------' 274 5. Security Considerations 276 Threat: cache poisoning. 277 Countermeasure: authenticate sender. 279 Threat: unauthorized de-registration 280 Countermeasure: authenticate requester. 282 Threat: Proxy resources' exhaustion. 283 Countermeasure: authenticate requester + quota limit. 285 Threat: global state loss. 286 Countermeasure: cache redundancy. 288 Threat: DoS on remote constrained resource via unneeded monitoring. 289 Countermeasure: access control on the constrained resource (?) 291 6. Normative References 293 [I-D.ietf-core-coap] 294 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 295 "Constrained Application Protocol (CoAP)", 296 draft-ietf-core-coap-10 (work in progress), June 2012. 298 [I-D.ietf-core-observe] 299 Hartke, K., "Observing Resources in CoAP", 300 draft-ietf-core-observe-05 (work in progress), March 2012. 302 [I-D.shelby-core-coap-req] 303 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 305 Kelsey, "CoAP Requirements and Features", 306 draft-shelby-core-coap-req-04 (work in progress), 307 May 2011. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 Authors' Addresses 314 Thomas Fossati 315 KoanLogic 316 Via di Sabbiuno, 11/5 317 Bologna 40100 318 Italy 320 Email: tho@koanlogic.com 322 Pierpaolo Giacomin 323 Freelance 325 Email: yrz@anche.no 327 Salvatore Loreto 328 Ericsson 329 Hirsalantie 11 330 Jorvas 02420 331 Finland 333 Email: salvatore.loreto@ericsson.com