idnits 2.17.1 draft-fossati-core-publish-monitor-options-01.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 (March 10, 2012) is 4429 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 396, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-08 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-11 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-04 == Outdated reference: A later version (-04) exists of draft-shelby-core-coap-req-02 == Outdated reference: A later version (-05) exists of draft-shelby-core-resource-directory-02 Summary: 0 errors (**), 0 flaws (~~), 7 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: September 11, 2012 Freelance 6 S. Loreto 7 Ericsson 8 March 10, 2012 10 Publish and Monitor Options for CoAP 11 draft-fossati-core-publish-monitor-options-01 13 Abstract 15 This memo defines two additional Options for the Constrained 16 Application Protocol (CoAP) especially targeted at sleepy sensors: 17 Publish and Monitor. 19 The Publish Option enables opportunistic updates of a given resource 20 state, by temporarily delegating the authority of the Publish'ed 21 resource to a Proxy node. The whole process is driven by the 22 (sleepy) origin -- which may actually never need to listen. 24 The Monitor Option complements the typical Observe pattern, enabling 25 the tracking of a resource hosted by a node sleeping most of the 26 time, by taking care of establishing and maintaining an Observe 27 relationship with the (sleepy) origin on behalf of the (sleepy) 28 client. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 11, 2012. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language and Motivation . . . . . . . . . . . 3 65 2. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Publish Option . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1.1. Publishing a Resource . . . . . . . . . . . . . . . . 4 68 2.1.2. Updating a Resource . . . . . . . . . . . . . . . . . 5 69 2.1.3. Unpublishing a Resource . . . . . . . . . . . . . . . 6 70 2.1.4. Value Format . . . . . . . . . . . . . . . . . . . . . 6 71 2.1.5. Discovery . . . . . . . . . . . . . . . . . . . . . . 6 72 2.1.5.1. Publishing the /.well-known/core Resource . . . . 6 73 2.1.5.2. Resource Directory . . . . . . . . . . . . . . . . 7 74 2.2. Monitor Option . . . . . . . . . . . . . . . . . . . . . . 7 75 2.2.1. Public Monitor Registration . . . . . . . . . . . . . 8 76 2.2.2. Monitor De-registration . . . . . . . . . . . . . . . 9 77 2.2.2.1. Explicit De-registration . . . . . . . . . . . . . 10 78 2.2.2.2. Implicit De-registration . . . . . . . . . . . . . 10 79 2.2.3. Resource Refresh . . . . . . . . . . . . . . . . . . . 10 80 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 85 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 The proposal described in this memo covers the following use case: 92 a node N, which is sleeping most of the time, depends one or more 93 resources hosted at another sleepy node M. In cases as such, the 94 probability of an empty intersection between their respective wake 95 periods is very high, making it hard for the two to synchronize. 97 In this scenario, using the basic observe [I-D.ietf-core-observe] 98 functionality is not enough, as it could lead to lost state updates 99 in case N is offline while M pushes its notifications; further, the 100 observation may never bootstrap since its initialization needs both 101 client and origin awake at the same time. 103 This memo introduces two extensions to the Proxy caching 104 functionality that give the Proxy an explicit mediation role in the 105 sleepy-to-sleepy CoAP [I-D.ietf-core-coap] communication. 107 1.1. Requirements Language and Motivation 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 This specification makes use of the following terminology: 115 Sleepy Device: a sensor/actuator (usually battery operated) that 116 powers down its radio beyond the normal radio duty cycle in order 117 to save energy. 119 and tries to provide an in-protocol solution for the requirement REQ3 120 stated in [I-D.shelby-core-coap-req]: 122 The ability to deal with sleeping nodes. Devices may be 123 powered down at any point in time but periodically "wake up" 124 for brief periods of time. 126 2. Options 128 +-----+----------+---------+--------+--------+---------+ 129 | No. | C/E | Name | Format | Length | Default | 130 +-----+----------+---------+--------+--------+---------+ 131 | YY | Critical | Publish | uint | 1 B | 0x2 | 132 | XX | Critical | Monitor | (none) | 0 B | (none) | 133 +-----+----------+---------+--------+--------+---------+ 135 2.1. Publish Option 137 The Publish Option enables the sleepy origin to temporarily (i.e. for 138 a specified "lease" time) delegate the authority of one of its hosted 139 resources to a Proxy node that will start to behave as the origin for 140 the Publish'ed resource. This allows a sleepy sensor to use the 141 Proxy as the rendezvous point for one-way sleepy to sleepy signaling. 143 2.1.1. Publishing a Resource 145 P S 146 | PUT | Proxy-URI: coap://sleepy.example.org/res 147 |<--------+ Publish: 0110 148 | r | Content-Type: text/plain 149 | | ETag: 0xabcd 150 | | Max-Age: 1200 151 | | 152 | 2.01 | 153 +-------->| 154 | | 156 Figure 1 158 The origin server publishes one of its hosted resources, specified by 159 the enclosed Proxy-URI, by PUT'ing it to the Proxy with a Publish 160 Option attached. The Publish Option value specifies the CoAP methods 161 that clients are allowed to use on the resource (see Section 2.1.4). 163 The example in Figure 1 shows a delegation where the GET and PUT 164 methods are allowed while POST and DELETE are explicitly prohibited, 165 meaning that the resource can be read and updated by clients, but it 166 can't be deleted nor created. 168 The Proxy, which is voluntarily charged by the resource owner to act 169 as the delegated origin for the "lease" time specified by Max-Age, 170 replies with a 2.01 if the authority transfer has succeeded. An 171 exact duplicate of the submitted representation is created, and from 172 now on it can be accessed using the original URI provided that 173 clients go through the delegated Proxy. If the Publish operation 174 does not succeed, the origin transfer fails, and an appropriate 175 response code is returned. 177 An ETag MAY be supplied as a metadata to be included in responses 178 involving the Publish'ed representation. If no Max-Age is given, a 179 default of 3600 seconds MUST be assumed. The Max-Age value, either 180 implicit or explicit, determines the lifetime of the origin 181 delegation. When the Max-Age value is elapsed, the Proxy MUST delete 182 the Publish'ed resource value and fall back to its usual proxying 183 function. 185 The Publish Option is critical and MUST be present in the request 186 only. If the Proxy does not recognize it, a 4.02 (Bad Option) MUST 187 be returned to the client. If the option value is not correctly 188 formatted (see Section 2.1.4), a 4.00 (Bad Request) MUST be returned 189 to the client. 191 It is sufficient for any client wishing to access the resource to do 192 so using the Proxy node that, following the Publish operation, will 193 start behaving a the origin, satisfying requests on behalf of the 194 sleeping node. 196 The Proxy MUST save the identity of the resource Publish'er in order 197 to distinguish "maintainance" operations such as update and explicit 198 deletion, from "regular" access to the published resource by clients. 200 An interesting outcome of this communication strategy is that the 201 sleepy origin may really never need to listen on its radio interface. 203 2.1.2. Updating a Resource 205 P S 206 | PUT | Proxy-URI: coap://sleepy.example.org/res 207 |<--------+ Publish: 0110 208 | r | Content-Type: text/plain 209 | | ETag: 0xdcba 210 | | Max-Age: 1200 211 | | 212 | 2.04 | 213 +-------->| 214 | | 216 Figure 2 218 In order to update the delegated resource state, the sleepy node 219 shall send the very same request to the Proxy, which in turn replies 220 with a 2.04 (Changed) status code in case the update operation has 221 succeeded, or an appropriate error code in case it fails. 223 2.1.3. Unpublishing a Resource 225 P S 226 | DELETE | Proxy-URI: coap://sleepy.example.org/res 227 |<---------+ Publish: 0x0 228 | | 229 | | 230 | 2.02 | 231 +--------->| 232 | | 234 The delegation of a given resource can be explicitly revoked by the 235 real origin at any time before the lease time expires, by issuing a 236 DELETE request to the Proxy hosting the resource duplicate with a 237 Publish Option with value 0x0. 239 On successful deletion of the delegation a 2.02 (Deleted) response 240 code is returned by the Proxy. 242 2.1.4. Value Format 244 0 1 2 3 4 5 6 7 245 +-+-+-+-+-+-+-+-+ 246 |C R U D 0 0 0 0| 247 +-+-+-+-+-+-+-+-+ 249 Each of the first 4 bits is a flag field indicating whether the 250 associated CoAP method (respectively: POST, GET, PUT and DELETE) is 251 allowed on the Publish'ed resource. The remaining 4 bits are unused 252 and MUST be set to 0. 254 In case the value is missing, the default is assumed to be 0x2, i.e. 255 the resource is read-only. 257 An all-0 value is used to explicitly revoke the delegation (see 258 Section 2.1.3.) 260 If the delegated Proxy receives a request with a method that is not 261 compatible with the supplied mask, it MUST respond with a 4.05 262 (Method Not Allowed) response code. 264 2.1.5. Discovery 266 2.1.5.1. Publishing the /.well-known/core Resource 268 The [I-D.ietf-core-link-format] has no explicit text about "well- 269 known" discovery of devices through a Proxy, nor about the 270 cacheability rules for such resource. Even if it seems reasonable to 271 assume that the /.well-known/core URI is both query-able and 272 cacheable through a Proxy, on the contrary the situation is not very 273 much so. 275 In fact, since the "well-known" interface relies on the resource 276 origin being implicitly defined by the source address of the UDP 277 packet carrying the response, quering the "well-known" interface 278 (either unicast or multicast) through a Proxy-URI has little hope to 279 be fully functional. The (ab)use of a an implicit L3 locator as the 280 identifier of the resource authority makes "well-known" discovery 281 generally incompatible with Proxy mediated communication, unless each 282 target URI in a link is given as a URI and not as a relative-ref 283 (section 4.1 of [RFC3986]). 285 Consequently, in this proposal we assume that the /.well-known/core 286 of a sleepy node can be Publish'ed if and only if the target URI in 287 the each link is not a relative-ref. 289 Its registration is the same as in Figure 1, but the Proxy MAY need 290 to treat it in a way that is slightly different from other "normal" 291 delegated resources. In fact, while delegation is in place (i.e. the 292 lease period is not elapsed, and neither explicit revocation has 293 happened) the Proxy MAY be able to respond to filtered queries 294 (section 4.1 of [I-D.ietf-core-link-format]) regarding the Publish'ed 295 /.well-known/core. 297 2.1.5.2. Resource Directory 299 Given the strong requirement on the link formatting given in 300 Section 2.1.5.1, it could be preferable (or even necessary) to use 301 the Resource Directory [I-D.shelby-core-resource-directory] as a 302 means of delegating the discovery of the resources hosted at a sleepy 303 node. 305 This can be done either by the sleepy node, or automatically by the 306 delegated Proxy when a Publish request is received. 308 [[Automatic push to RD: check it out]] 310 2.2. Monitor Option 312 The Monitor Option is a variant of the Observe Option that is aimed 313 at solving some issues that may occur when sleepy sensors are 314 involved. 316 Suppose that the resource of interest is not in cache, and a sleepy 317 endpoint wants to Observe it through the Proxy. If the origin of the 318 requested resource is sleeping at the time the observation is 319 requested, the requesting node gets an error, and may need to stay 320 awake and retry until the target node gets ready -- which is clearly 321 not an option in case the sensor has a very small duty cycle. 323 The Monitor Option is used to ask a Proxy to keep a given resource 324 fresh by observing it, while the requesting node is sleeping. Thus 325 the sleepy sensor can possibly get the latest representation 326 published by the monitored resource when it wakes up, even if the 327 origin is sleeping -- and was sleeping at the time the Monitor has 328 been requested. 330 The Monitor Option is critical and MUST be present in the request 331 only. If the Proxy does not recognize it, a 4.02 (Bad Option) MUST 332 be returned to the client. 334 2.2.1. Public Monitor Registration 336 P C 337 | POST | Proxy-URI: coap://sleepy.example.org/res 338 |<-------+ Monitor: 339 | | Max-Age: 86400 340 | | Content-Type: application/json 341 | 2.01 | 342 +------->| Location-Path: temp 343 | | Location-Path: res 344 | | 346 Figure 3 348 The client POST's the resource to be monitored, identified by the 349 Proxy-URI. The request message contains an empty Monitor Option, and 350 possibly specifies a TTL (i.e. an implicit de-registration 351 indication) for the monitor through Max-Age. One or more content 352 types for the acceptable representations of the resource are 353 optionally specified via the Accept option. In case no TTL is 354 supplied, a default value of 3600 seconds is assumed. 356 The operation creates a "monitor" resource at the Proxy, that MUST 357 maintain a fresh carbon copy of one or more representations of the 358 requested resource depending on the supplied Content-Type's. For 359 convenience, multiple "monitor" resources corresponding to the same 360 target resource, can be coalesced into the same monitor object at the 361 Proxy -- possibly with the same URI. In such case, a set containing 362 one entry for each registered client is kept, which holds the client 363 identities, their expiry and one or more preferred media types for 364 their representation(s). When all entries are deleted (either 365 because clients have explicitly deregistered the monitor, or the 366 monitor period has expired), the corresponding "monitor" object is 367 deleted. Note that an underlying cache entry MAY still be kept in 368 case the cached representation(s) are still fresh (i.e. the Max-Age 369 of the "monitor" resource and Max-Age of the target resource have 370 completely different semantics.) 372 If the monitor resource is successfully created, the server MUST 373 return a 2.01 response containing one or more Location-Path and/or 374 Location-Query Options to identify the monitored resource instance, 375 which can be used from now on by the requester as an alias to the 376 target resource. 378 At a later time, the client wakes up and wants to access the 379 monitored resource. It does so by requesting the Proxy monitor 380 resource that has been previously created. 382 P C 383 | GET | URI-Path: temp 384 |<-------+ URI-Path: res 385 | | Accept: application/json 386 | | 387 | 2.05 | 388 +------->| (Content) 389 | | 390 | | 392 Figure 4 394 In case the observation on the target node has not been started 395 because the Proxy has not yet been able to contact the origin, the 396 Proxy will return a [TBD] error code. 398 In case the requested resource was not present on the origin, the 399 Proxy will return an empty response (i.e. one with no payload.) 401 [[XXX: add an explicit response code perhaps like HTTP 204 ?]] 403 In case the monitor resource is not found in the Proxy, either 404 because the Proxy has rebooted and lost its state, or the monitor 405 resource has been de-registered (see Section 2.2.2), a 4.04 response 406 code is returned to the client -- that can recreate it, if needed. 408 2.2.2. Monitor De-registration 410 The monitor object MUST be deleted at the Proxy when all its 411 associated resources have been de-registered or have expired. 413 In order to save storage, a Proxy MAY decide to delete a monitor 414 resource in case it has not been requested for a sufficiently long 415 time, or for any other reason. Note that the Proxy may also reboot 416 and lose its state, including the state associated to any monitored 417 resource. The requester can realize that the state at the Proxy has 418 been lost, and re-instantiate the monitor, when it receives an 419 unexpected 4.04 from the "monitor" resource. 421 2.2.2.1. Explicit De-registration 423 P C 424 | DELETE | Path: temp 425 |<-------+ Path: res 426 | | 427 | 2.02 | 428 +------->| 429 | | 431 Figure 5 433 Explicit de-registration is performed by a client, with a DELETE on 434 the URI returned by the Proxy on the corresponding registration. 436 2.2.2.2. Implicit De-registration 438 Implicit de-registration MUST occur when the monitoring period 439 specified by the client via Max-Age expires. If no Max-Age was 440 supplied at registration time, a default of 3600 seconds MUST be 441 assumed. 443 2.2.3. Resource Refresh 445 In order to minimize the number of messages used by the monitoring 446 process, the Proxy MUST try to install an observation on the 447 requested resource. In case this first attempt fails, the Proxy MAY 448 fall back to repeated poll whose duration is upper bounded by the 449 Max-Age value indicated by the client during registration. 451 Usual cache validation MUST be applied to the cached copy of the 452 monitored resource. 454 3. Acknowledgements 456 Bruce Nordman. 458 4. IANA Considerations 460 The following entries are added to the CoAP Option Numbers registry: 462 .------------------------------. 463 | Number | Name | Reference | 464 :--------:---------:-----------: 465 | 2n+1 | Publish | RFC XXXX | 466 +--------+---------+-----------+ 467 | 2m+1 | Monitor | RFC XXXX | 468 `------------------------------' 470 5. Security Considerations 472 Threat: cache poisoning. 473 Countermeasure: authenticate sender. 475 Threat: unauthorized de-registration 476 Countermeasure: authenticate requester. 478 Threat: Proxy resources' exhaustion. 479 Countermeasure: authenticate requester + quota limit. 481 Threat: global state loss. 482 Countermeasure: cache redundancy. 484 6. References 486 6.1. Normative References 488 [I-D.ietf-core-coap] 489 Frank, B., Bormann, C., Hartke, K., and Z. Shelby, 490 "Constrained Application Protocol (CoAP)", 491 draft-ietf-core-coap-08 (work in progress), October 2011. 493 [I-D.ietf-core-link-format] 494 Shelby, Z., "CoRE Link Format", 495 draft-ietf-core-link-format-11 (work in progress), 496 January 2012. 498 [I-D.ietf-core-observe] 499 Hartke, K., "Observing Resources in CoAP", 500 draft-ietf-core-observe-04 (work in progress), 501 February 2012. 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, March 1997. 506 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 507 Resource Identifier (URI): Generic Syntax", STD 66, 508 RFC 3986, January 2005. 510 6.2. Informative References 512 [I-D.shelby-core-coap-req] 513 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 514 Kelsey, "CoAP Requirements and Features", 515 draft-shelby-core-coap-req-02 (work in progress), 516 October 2010. 518 [I-D.shelby-core-resource-directory] 519 Krco, S. and Z. Shelby, "CoRE Resource Directory", 520 draft-shelby-core-resource-directory-02 (work in 521 progress), October 2011. 523 Authors' Addresses 525 Thomas Fossati 526 KoanLogic 527 Via di Sabbiuno, 11/5 528 Bologna 40100 529 Italy 531 Email: tho@koanlogic.com 533 Pierpaolo Giacomin 534 Freelance 536 Email: yrz@anche.no 538 Salvatore Loreto 539 Ericsson 540 Hirsalantie 11 541 Jorvas 02420 542 Finland 544 Email: salvatore.loreto@ericsson.com