idnits 2.17.1 draft-giacomin-core-sleepy-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 (February 29, 2012) is 4411 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: 'Content' is mentioned on line 281, but not defined == Missing Reference: 'TBD' is mentioned on line 393, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-core-block-08 == 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 Summary: 0 errors (**), 0 flaws (~~), 6 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 1, 2012 Freelance 6 S. Loreto 7 Ericsson 8 M. Rossini 9 CS Dept. University of Bologna 10 February 29, 2012 12 Sleepy Option for CoAP 13 draft-giacomin-core-sleepy-option-00 15 Abstract 17 This memo defines a framework for allowing asynchronous communication 18 between sleepy sensors mediated by a supporting Proxy node. The 19 Proxy acts as a store-and-forward agent that handles requests on 20 behalf of a sleepy client, and buffers responses coming from the 21 target origin until the requesting client wakes up and get the 22 computation results. 24 A new CoAP option, Sleepy, is defined to initiate and control the 25 asynchronous exchange. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 1, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Basic Message Flows . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Basic Message Flow with CON Semantics . . . . . . . . . . 4 66 3.2. Basic Message Flow with NON Semantics . . . . . . . . . . 6 67 4. Optimized Message Flow . . . . . . . . . . . . . . . . . . . . 6 68 5. Sleepy Option . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6. Limiting Network Congestion . . . . . . . . . . . . . . . . . 10 70 7. New Link-Format Attributes . . . . . . . . . . . . . . . . . . 10 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The proposal described in this memo covers the following use case: 83 a node A, displaying a very short duty-cycle, needs to interact 84 with one or more resources hosted at another sleepy node B. The 85 probability of an empty intersection between their respective wake 86 periods is quite high, making it hard for the two to synchronize. 88 The proposal is to arm the Proxy with the ability to act as a store- 89 and-forward agent mediating the request/response exchange between A 90 and B. 92 A declares the will to act onto a given resource hosted at B to the 93 Proxy, and gives a "get back" indication that tells the Proxy the 94 time at which it is going to be on duty again, and willing to 95 retrieve the response from B. 97 The Proxy is in charge of making the request on behalf of A, using an 98 appropriate poll interval for a time span upper bounded by the "get 99 back" value, and to buffer the response from B until A wakes up 100 again. 102 This draft defines a new CoAP elective option, Sleepy, targeted 103 specifically at proxies and used to signal a Proxy the will to 104 initiate an asynchronous request/response exchange. The Sleepy 105 option is partitioned in three subfields indicating: the remaining 106 time before sleep, the expected sleep interval, and (optionally) the 107 on-duty interval. 109 1.1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. Additional 114 privileged words are described below. 116 Sleepy Device: a sensor/actuator (usually battery operated) that 117 switches off its radio beyond the normal radio duty cycle in order to 118 save energy. 120 Store-and-Forward Proxy: a CoAP proxy that is able to act as an 121 intermediate agent where CoAP PDUs are received, kept, and sent at a 122 later time to the final destination or to another intermediate 123 station. Its use may be especially helpful in networks with 124 intermittent connectivity, such those hosting a significant amount of 125 sleepy devices. 127 2. Motivation 129 This memo focuses on the requirement REQ3 of 130 [I-D.shelby-core-coap-req]: 132 REQ3: The ability to deal with sleeping nodes. Devices may be 133 powered off at any point in time but periodically "wake up" 134 for brief periods of time. 136 3. Basic Message Flows 138 In the most general scenario both A and B are sleepy endpoints 139 showing empty intersection as to their wake intervals, while the 140 Proxy cache is empty. 142 3.1. Basic Message Flow with CON Semantics 144 A typical flow of communication involving the Sleepy option using CON 145 messaging is shown in Figure 1. 147 A P B 148 . | . 149 . CON (0x7a10) | . 150 (1) +----------------------->| . 151 | Method | . 152 | Proxy-Uri: B/res | . 153 | Sleepy: {2,58,0} | . 154 | | . 155 | ACK (0x7a10) | . 156 (2) |<-----------------------+ . 157 . | Method . 158 (3) . +------------------X . 159 . | Uri-Path: /res . 160 . | . 161 . | Method . 162 (4) . +------------------X . 163 . | Uri-Path: /res . 164 . | . 165 . | Method | 166 (5) . +------------------------>| 167 . | Uri-Path: /res | 168 . | | 169 . | Response Code | 170 (6) . |<------------------------+ 171 . | [Content] | 172 . | . 173 . | . 174 . CON (0xfa10) | . 175 (7) |<-----------------------+ . 176 | Response Code | . 177 | [Content] | . 178 | | . 179 | ACK (0xfa10) | . 180 (8) +----------------------->+ . 181 . | . 183 Figure 1 185 In message (1) a sleepy node, A, asks the Proxy to act upon the 186 resource identified by the Proxy-Uri Option in a possibly 187 asynchronous way by supplying the Sleepy Option indicating a time at 188 which A thinks it may be ready (i.e. awake) to retrieve the response 189 message. The Sleepy Option in the message (1) tells the Proxy that A 190 will go off-duty in 2 milliseconds, and it will be off-duty for 58 191 milliseconds, but it does not provide any information about the 192 optional on-duty interval. 194 In case the Proxy understands the Sleepy Option, it replies (2) with 195 a separate ACK. 197 From now on A can get back to sleep while the Proxy sends 198 periodically the request to the target node, B -- messages (3-5) -- 199 and eventually gets a response back (6). 201 The stored response is kept by the Proxy until A is on duty again. 202 (The seeming on-duty time is computed using the quantities previously 203 supplied by A through the Sleepy Option.) The Proxy sends the 204 separate response back, operating with the usual rules of CON 205 retransmission, until an ACK from A is received, or the transmission 206 retries are exhausted. 208 Please note that, generally speaking, the framework is completely 209 agnostic as to the transported message type and method. Further, the 210 Proxy may rearrange any implied block-wise transfer 211 [I-D.ietf-core-block] or separate acknowledgment in an optimal way. 213 [[OPEN ISSUE 1: What if message (2) is lost ?]] 215 3.2. Basic Message Flow with NON Semantics 217 In case the sleepy sensor uses NON semantics, the resulting exchange 218 is the basically the same as the one depicted in Figure 1 with 219 messages (2) and (8) removed. 221 4. Optimized Message Flow 223 The Proxy/Cache, in charge of making the request on behalf of A, MUST 224 try to immediately satisfy a request by searching the Cache. 226 Figure 2 shows a request from A which can be satisfied from the cache 227 (i.e. cache hit) without interrogating B. 229 A P B 230 . | . 231 . | . 232 . CON (0x7a10) | . 233 (1) +----------------------->| . 234 | Method | . 235 | Proxy-Uri: B/res | . 236 | Sleepy: {2,58,0} | . 237 | | . 238 | [cache hit] . 239 | | . 240 | ACK (0x7a10) | . 241 (7) |<-----------------------+ . 242 . Response Code | . 243 . [Content] | . 244 . | . 245 . | . 247 Figure 2 249 In case a request from A can not be satisfied from the Cache (i.e. 250 cache miss), the Proxy, in charge of making the request on behalf of 251 A, sends periodically the request to the target node and eventually 252 gets a response back. 254 Figure 3 shows a cache miss scenario where the Proxy, knowing that 255 the target node is awake, forwards the request to B (5) and sends the 256 response to A (7) within the "time left before sleeping" indication 257 supplied by A with the request (1). The latter exchange SHALL 258 concurrently arm a timeout for sending the ACK message to A before it 259 goes to sleep (in case CON is in use). 261 A P B 262 . | . 263 . | . 264 . CON (0x7a10) | . 265 (1) +----------------------->| . 266 | Method | . 267 | Proxy-Uri: B/res | . 268 | Sleepy: {5,58,5} | . 269 | | . 270 | [cache miss] . 271 | | | 272 (5) | +------------------------>| 273 | | Uri-Path: /res | 274 | | | 275 | | Response Code | 276 (6) | |<------------------------+ 277 | | [Content] | 278 | ACK (0x7a10) | . 279 (7) |<-----------------------+ . 280 . Response Code | . 281 . [Content] | . 282 . | . 283 . | . 285 Figure 3 287 In any case, if the Proxy has previously received an indication from 288 the same target about its on/off-duty behavior via the Sleepy Option 289 (Section 5), or by any other means (e.g. Section 7), it MUST use it 290 to devise the most efficient poll strategy, thus avoiding unnecessary 291 messaging which would just aggravate the constrained network 292 congestion. 294 5. Sleepy Option 296 +-----+----------+---------+--------+--------+---------+ 297 | No. | C/E | Name | Format | Length | Default | 298 +-----+----------+---------+--------+--------+---------+ 299 | XX | Elective | Sleepy | uint | 8-12 B | (none) | 300 +-----+----------+---------+--------+--------+---------+ 302 The Sleepy Option in a request is used to signal a Proxy the will to 303 initiate an asynchronous request/response exchange. 305 The Sleepy option is elective. If the Proxy does not recognize it, 306 it will try to serve a fresh representation of the requested 307 resource, or forward the request to the intended origin; depending on 308 the availability of the endpoints at the time the Proxy tries to 309 contact them, the usual proxied transaction may succeed, partially 310 fail, or completely fail. 312 The Sleepy Option MAY be discretionarily piggybacked by a sleepy node 313 on response messages to inform the network about the sleepy pattern 314 in use at the endpoint. This knowledge MAY be used by sleepy- 315 friendly Proxies to reduce the overall network congestion that is 316 implied by resorting to blind polling in order to maximize the chance 317 to get a response from the target. 319 The value of the Sleepy option is partitioned in three subfields 320 indicating: the remaining time before sleep, the expected sleep 321 interval, and (optionally) the on-duty interval. 323 Two formats are available, a long format (Figure 4), and a short one 324 (Figure 5) which are easily distinguished from the Length field of 325 the encoded option: 8 and 12 respectively. 327 +-------+-------+-------+ 328 | LEFT | SLEEP | WAKE | 329 +-------+-------+-------+ 331 Figure 4 333 +-------+-------+ 334 | LEFT | SLEEP | 335 +-------+-------+ 337 Figure 5 339 LEFT: 32-bit uint encoding the number of milliseconds that the 340 sending node is left before going off-duty. The maximum value is 341 0xFFFFFFFF, which allows for 71582 minutes. 343 SLEEP: 32-bit uint encoding the number of milliseconds that the 344 sending node is off-duty. The maximum value allows for 71582 345 minutes (i.e. approx. 50 days). 347 WAKE: optional 32-bit uint encoding the number of milliseconds 348 that the sending node is on-duty. 350 [[OPEN ISSUE 2: shrink to 24-bit uint LEFT and WAKE (i.e. max ~4 351 hours) ?]] 353 [[OPEN ISSUE 3: change milli to seconds ?]] 355 6. Limiting Network Congestion 357 The retransmit function at the Proxy is conflicting with the overall 358 requirement of congestion avoidance on the constrained network. 360 Therefore the proxy SHOULD try to learn as much as possible about the 361 on/off-duty behavior of the nodes that it is trying to reach, and 362 keep the gained knowledge to inform future message exchanges with 363 these endpoints. 365 Missing an explicit signaling at the network/transport layer, 366 endpoints that have a predictable sleep/awake pattern SHOULD try to 367 inform the other entities in the network by piggybacking, whenever 368 possible, the Sleepy Option in the messages (both requests and 369 responses) they are exchanging with other peers. 371 A further possibility is to distribute the information regarding the 372 sleep/awake pattern by extending the resource attributes available 373 through the Resource Directory with a link-format 374 [I-D.ietf-core-link-format] version of the Sleepy option (see 375 Section 7). 377 7. New Link-Format Attributes 379 This specification defines the following new attributes for use in 380 the CoRE Link Format: 382 link-extension = ( "sleep" "=" 1*DIGIT ) 383 link-extension = ( "wake" "=" 1*DIGIT ) 384 link-extension = ( "start" "=" 1*DIGIT ) ; in seconds since Epoch 386 The sleep and wake attributes have the same semantics and format as 387 the SLEEP and WAKE subfields of the Sleepy Option respectively 388 (Section 5). The start attribute sets the base time from which the 389 offsets indicated by sleep and wake must be computed. 391 8. Acknowledgements 393 [TBD] 395 9. IANA Considerations 397 The following entries are added to the CoAP Option Numbers registry: 399 .------------------------------. 400 | Number | Name | Reference | 401 :--------:---------:-----------: 402 | 2k | Sleepy | RFC XXXX | 403 `------------------------------' 405 The "start", "wake" and "sleep" attributes need to be registered when 406 a future Web Linking attribute is created. 408 10. Security Considerations 410 The same considerations as those highlighted in Section 10.3.2 and 411 10.3.3 of [I-D.ietf-core-coap] apply, and are somewhat amplified by 412 the possible congestion induced by the tentative setup of 413 communication with the target node (messages 3-5 in Figure 1). The 414 Proxy SHOULD try to send as little messages as possibile in order to 415 contact the requested endpoint and MUST make use of the wake/sleep 416 indication in case they have been previously made available by the 417 target node through the Sleepy Option. 419 11. References 421 11.1. Normative References 423 [I-D.ietf-core-block] 424 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 425 draft-ietf-core-block-08 (work in progress), 426 February 2012. 428 [I-D.ietf-core-coap] 429 Frank, B., Bormann, C., Hartke, K., and Z. Shelby, 430 "Constrained Application Protocol (CoAP)", 431 draft-ietf-core-coap-08 (work in progress), October 2011. 433 [I-D.ietf-core-link-format] 434 Shelby, Z., "CoRE Link Format", 435 draft-ietf-core-link-format-11 (work in progress), 436 January 2012. 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 11.2. Informative References 443 [I-D.shelby-core-coap-req] 444 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 446 Kelsey, "CoAP Requirements and Features", 447 draft-shelby-core-coap-req-02 (work in progress), 448 October 2010. 450 Authors' Addresses 452 Thomas Fossati 453 KoanLogic 454 Via di Sabbiuno, 11/5 455 Bologna 40100 456 Italy 458 Email: tho@koanlogic.com 460 Pierpaolo Giacomin 461 Freelance 463 Email: yrz@anche.no 465 Salvatore Loreto 466 Ericsson 467 Hirsalantie 11 468 Jorvas 02420 469 Finland 471 Email: salvatore.loreto@ericsson.com 473 Mirko Rossini 474 CS Dept. University of Bologna 476 Email: mirko.rossini@ymail.com