idnits 2.17.00 (12 Aug 2021) /tmp/idnits62273/draft-rahman-core-sleeping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 29, 2010) is 4337 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.draft-frank-6lowpan-chopan' is defined on line 575, but no explicit reference was found in the text == Outdated reference: draft-ietf-core-coap has been published as RFC 7252 == Outdated reference: A later version (-04) exists of draft-shelby-core-coap-req-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CoRE Group A. Rahman 2 Internet Draft JC. Zuniga 3 Intended status: Informational G. Lu 4 Expires: December 29, 2010 InterDigital Communications, LLC 5 June 29, 2010 7 Sleeping and Multicast Considerations for CoAP 8 draft-rahman-core-sleeping-00.txt 10 Abstract 12 This document further analyzes the COAP requirements related to 13 "sleeping nodes" and "multicast" through the use of examples and use 14 cases. The goal of this document is to trigger discussions in the 15 CoRE working group so that all relevant considerations are taken into 16 account when designing CoAP. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on December 29, 2010. 41 Copyright Notice 43 Copyright (c) 2010 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 BSD License. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Conventions and Terminology....................................3 60 3. Handling Sleep Nodes...........................................3 61 3.1. General Behavior of Sleep Nodes...........................3 62 3.2. Handling Sleeping Nodes within CoAP.......................4 63 3.3. Use Cases.................................................7 64 3.3.1. Use Case 1: Smart Meter Reading......................7 65 3.3.2. Use Case 2: Smart Meter Firmware Upgrade.............9 66 3.3.3. Use Case 3: Obtaining Configuration.................10 67 3.3.4. Use Case 4: Constrained Node Sending Report.........12 68 4. Multicast Support in CoAP.....................................13 69 5. Conclusions...................................................14 70 6. Security Considerations.......................................14 71 7. IANA Considerations...........................................14 72 8. References....................................................14 73 8.1. Normative References.....................................14 74 8.2. Informative References...................................15 75 9. Acknowledgments...............................................15 77 1. Introduction 79 The CoRE working group is chartered to design and standardize a 80 Constrained Application Protocol (CoAP) for resource constrained 81 devices and networks [I-D.draft-ietf-core-coap]. The requirements 82 for CoRE are well documented group [I-D.draft-shelby-core-coap-req]. 84 In this draft, we focus and expand discussions on some of these key 85 requirements pertaining to sleeping nodes and multicast support. 86 Specifically, the requirements we analyze are: 88 REQ 3: The ability to deal with sleeping nodes. Devices may be 89 powered off at any point in time but periodically "wake up" for 90 brief periods of time. 92 REQ 4: Protocol must support the caching of recent resource 93 requests, along with caching subscriptions to sleeping nodes. 95 REQ 9: CoAP will support a non-reliable IP multicast message to be 96 sent to a group of Devices to manipulate a resource on all the 97 Devices simultaneously. The use of multicast to query and advertise 98 descriptions must be supported, along with the support of unicast 99 responses. 101 2. Conventions and Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 The following are definitions of terminologies used in this draft. 109 Sleep Mode: Refers to the state when a device is not able to send 110 and/or receive any messages due to power conservation from the 111 perspective of an application protocol (i.e. CoAP). 113 Sleep Node: A device that may go to sleep mode from time to time. 115 Sleeping Node: A device that is in sleep mode. 117 3. Handling Sleep Nodes 119 3.1. General Behavior of Sleep Nodes 121 In this section we discuss different behaviors and scenarios of 122 sleeping nodes. Such behaviors can affect the design of applications 123 (such as CoAP) and network topologies (such as proxies and caching). 125 Sleeping nodes can have various sleeping patterns. Sleep patterns can 126 be predictable or totally unpredictable. For example, some nodes 127 sleep at a fixed interval or upon certain triggers. Some nodes may 128 sleep at irregular time intervals, or switch to sleep mode 129 spontaneously. Some nodes stay in sleep mode and only wake up upon 130 certain event triggers. A network may thus not be well aware of the 131 sleeping state of a node at a given time. 133 The duration of sleeping mode also varies largely, possibly from a 134 few seconds to days. From the perspective of applications, it may not 135 be affected by the sleeping period if it is very short. For example, 136 a HTTP/TCP connection may still work (even if sub-optimally) if the 137 sleep cycle is much shorter than the TCP retransmission timer. In 138 contrast, if the sleeping period of a node exceeds a certain 139 threshold it can impact an application. This threshold however, can 140 be difficult to predict and often can vary from device to device and 141 network to network. For example, this threshold can be very dependent 142 on the topology of a constrained network especially for the case 143 where a multi-hop path consists of multiple sleeping nodes. For this 144 case, the cumulative effect of multiple sleeping nodes must be 145 considered. 147 The network topology also affects how to handle sleeping nodes. For 148 example, in a star shaped network, a proxy node (assuming to be not a 149 sleeping node) can cache for the sleeping nodes within the network in 150 a centralized manner. However, in a P2P or mesh network, especially 151 when multi-hops are involved, caching can be difficult and delivering 152 of messages can be largely delayed due to nodes' sleeping cycles. In 153 this case distributed proxying and caching at intermediate nodes 154 within the network (rather than just a single node such as the border 155 node or sink) may make sense, if intermediate nodes are not sleeping 156 nodes and have adequate resources to support caching. 158 3.2. Handling Sleeping Nodes within CoAP 160 Traffic generated for handling sleeping nodes should be minimized in 161 a constrained network. A constrained device can delegate its 162 authority to the proxy node for operations on its behalf. Therefore 163 operations between the constrained device and its counterpart (e.g. a 164 computer on the Internet) become asynchronous due to the proxy. 166 Below we discuss the various aspects to consider for handling 167 sleeping nodes with CoAP. 169 1) Exchange of sleeping schedule 170 A node can optionally include its sleep schedule and exchange such 171 information with other nodes and/or proxies. This provides proxy(s) 172 with better awareness of all resources that they are able to proxy 173 for as well as which devices sleep and their corresponding sleep 174 cycle durations. Using this sleep information, the proxy(s) could 175 choose which device resources it wants to create/maintain intercept 176 caches for (e.g. support intercept caches only for sleeping devices), 177 thus optimizing resource utilization within the proxy by selectively 178 caching and also minimizing the impact on sleeping nodes by allowing 179 them to sleep longer and not have to directly service incoming 180 requests. 182 2) Proxy and device synchronization 183 A common synchronization scheme is to have the device always inform 184 the proxy of its latest sleep state by checking-in [I-D.frank- 185 6lowpan-chopan]. For example, the proxy can subscribe to a node and 186 the node sends notification each time when it wakes up. However, this 187 approach increases the traffic for managing the sleep state, 188 especially when there are a large amount of nodes and they sleep 189 frequently. 191 A proxy can benefit from being synchronized to its associated 192 constrained device's sleep and awake state. Ideally, if the proxy and 193 device are synchronized in time and if the device has a predictable 194 sleep schedule, the proxy can know whether the device is awake or not 195 without the device having to check-in so often. However, time 196 synchronization may be difficult to achieve for constrained devices. 198 3) Caching and Proxying 199 It is assumed that the proxy node is awake all the time. A proxy can 200 thus always cache for the constrained nodes, regardless of the node's 201 sleep state. The proxy node would then act as an interception proxy. 202 This is analogous to the concept of web caching (e.g. HTML pages, 203 images, etc.) between a Web server and a Web browser used in the 204 general Internet. 206 Figure 1 shows a call flow when a constrained node (Node 1) sends a 207 REQUEST to Node 2. The REQUEST can contain any method, GET, POST, 208 PUT, DELETE, or SUBSCRIBE. The figure illustrates two scenarios. In 209 Case 2a, the proxy sends a RESPONSE with intermediate status. After 210 that, Node 1 may go to sleep mode, and receive the requested content 211 in step 6 after it wakes up. In Case 2b, the proxy acts upon the 212 REQUEST immediately. Node 1 may go into sleep mode at any time after 213 sending the REQUEST, if it can handle delayed response. The proxy 214 node is in sync with Node 1 for its sleep state and caches the 215 RESPONSE for it when it is in sleep mode. When Node 1 wakes up, it 216 can notify the proxy with its sleep schedule (if changed) and send 217 data for caching as the procedure shown in step 5. 219 Node 1 Proxy Node Node 2 220 (sleep cycles) (always on) (always on) 221 | | | 222 | 1.REQUEST(GET,POST,PUT | | 223 | DELETE, SUBSCRIBE) | | 224 |------------------------ >| | 225 | | | 226 ----------------------------------------------------------- 227 | | | 228 | Case 2a: sends immediate | 229 | RESPONSE to Node 1 | 230 | | | 231 | 2. RESPONSE/NOTIFY | | 232 | (Accepted) | | 233 |< ------------------------| | 234 | | | 235 ---------------------------------------------------------- 236 | | | 237 | Case 2b: acts upon the REQUEST | 238 | | | 239 | | 3.REQUEST(GET,POST,PUT | 240 | | DELETE, SUBSCRIBE) | 241 | |------------------------ >| 242 | | | 243 | | 4.RESPONSE | 244 | |< ------------------------| 245 | | | 246 | caches RESPONSE | 247 | | | 248 | checks sleep state of Node 1 | 249 | | | 250 | | | 251 Wakes up | | 252 | | | 253 | 5. Sends updates | | 254 | (sleep schedule) | | 255 | (other contents) | | 256 |< ====================== >| | 257 | | | 258 |< -6.RESPONSE/NOTIFY------| | 259 | | | 260 Figure 1 Caching and Proxying 262 3.3. Use Cases 264 In this section, different scenarios are illustrated to show the 265 operations of a proxy node for GET and non-GET REQUESTs. The REQUEST 266 can be from the constrained or non-constrained domain. For the 267 following figures, Node 1 is a constrained node and it goes to sleep 268 from time to time. Node 2 is a node in the non-constrained domain. It 269 is assumed that the proxy node and Node 2 do not go to sleep. The 270 protocol between Node 1 and the Proxy Node is CoAP, and the protocol 271 between the Proxy Node and Node 2 is HTTP. 273 The figures show some key scenarios but are not exhaustive. 275 3.3.1. Use Case 1: Smart Meter Reading 277 In use case 1, Node 1 is a smart meter in the constrained network, 278 and Node 2 in the non-constrained network wants to read the data from 279 Node 1. 281 The proxy can enable asynchronous communication between Node 1 and 282 Node 2. In situation 2a, since the proxy node has an updated cache 283 for what Node 2 is requesting, the proxy can respond to Node 2, 284 regardless of Node 1's sleep state. 286 In situation 2b, if the proxy does not have an updated cache, and 287 Node 1 is sleeping, the proxy can send a RESPONSE to Node 2 with 288 RETRY-AFTER information. The proxy would need to be synchronized with 289 Node 1 and have Node 1's sleep schedule. Otherwise the proxy has to 290 poll Node 1, which can cause a long delay and extra messaging. The 291 synchronization is shown in step 5. When Node 1 wakes up, it can 292 notify the proxy with its sleep schedule (if changed) and send data 293 for caching. 295 Alternatively, as shown in step 2b', the proxy may buffer the REQUEST 296 and only send a RESPONSE when it gets information from Node 1. This 297 can reduce messaging for Node 2 to query again. The proxy should know 298 the sleep schedule of Node 1 to make such a decision on how it 299 reacts. If Node 1 is not waking up in a very long time, it is 300 probably better for the proxy to send RESPONSE to Node 2 immediately. 301 Otherwise the long delay can cause time-out and retry of Node 2. 303 Node 1 Proxy Node Node 2 304 (sleep cycles) (always on) (always on) 305 | | | 306 | | 1.REQUEST(GET, | 307 | | meter reading) | 308 | |< ----------------------- | 309 | | | 310 | 2. Checks its cache | 311 --------------------------------------------------------- 312 | Case 2a: Has updated cache | 313 | | | 314 | | 3.RESPONSE(meter reading)| 315 | |------------------------ >| 316 --------------------------------------------------------- 317 | | | 318 | Case 2b: No cache, Node 1 is sleeping | 319 | | | 320 | |4.RESPONSE(Retry-After) | 321 | |------------------------ >| 322 wakes up | | 323 | | | 324 |< === 5.sends update === >| | 325 | (with meter reading) | | 326 | | | 327 | updates cache | 328 | and Node 1's schedule | 329 | |< == 6.Node 2 sends === > | 330 | | REQUEST again | 331 --------------------------------------------------------- 332 | | | 333 | Case 2b': No cache, Node 1 is sleeping | 334 | buffers REQUEST | 335 wakes up | | 336 | | | 337 |< === 5.sends updates == >| | 338 | (with meter reading) | | 339 | updates cache | 340 | and Node 1's schedule | 341 | | | 342 | | 6.RESPONSE(meter reading)| 343 | |------------------------ >| 344 | | | 346 Figure 2 Use Case 1: Smart Meter Reading 348 3.3.2. Use Case 2: Smart Meter Firmware Upgrade 350 In use case 2, Node 1 is a smart meter in a constrained network and 351 Node 2 upgrades Node 1's firmware using PUT. If the proxy knows that 352 Node 1 is sleeping, it can either advise Node 2 to retry later, or 353 the proxy can buffer the REQUEST till Node 1 wakes up. 355 Node 1 Proxy Node Node 2 356 (sleep cycles) (always on) (always on) 357 | | | 358 | | 1.REQUEST(PUT, | 359 | | firmware for Node 1) | 360 | |< ----------------------- | 361 | | | 362 | 2. checks Node 1 state | 363 | Node 1 is sleeping | 364 | | | 365 | | | 366 --------------------------------------------------------- 367 | | | 368 | Case 3a: no buffering | 369 | | | 370 | | 3.RESPONSE(Retry-After) | 371 | |------------------------ >| 372 | | | 373 --------------------------------------------------------- 374 | | | 375 | Case 3b: buffers REQUEST | 376 | | | 377 | | | 378 wakes up | | 379 | | | 380 |< === 4.sends updates == >| | 381 | | | 382 | 5.REQUEST (PUT, | | 383 | firmware for Node 1) | | 384 |< ------------------------| | 385 | 6.RESPONSE (Status) | | 386 |----------------------- > | | 387 | | | 388 | | 7.RESPONSE(Status) | 389 | |------------------------ >| 390 | | | 391 | | | 393 Figure 3 Use Case 2: Smart Meter Firmware Upgrade 395 3.3.3. Use Case 3: Obtaining Configuration 397 Use case 3 shows that Node 1 in a constrained network tried to obtain 398 a configuration parameter from Node 2. Since the proxy is aware that 399 Node 1 is a sleep node, the proxy sends RESPONSE to Node 1 400 immediately so that Node 1 can go to its sleep cycle. The proxy then 401 requests and caches the configuration parameter for Node 1, and it 402 can notify Node 1 when Node 1 wakes up. 404 Node 1 Proxy Node Node 2 405 (sleep cycles) (always on) (always on) 406 | | | 407 | | | 408 | 1.REQUEST (GET, | | 409 | configuration) | | 410 |------------------------ >| | 411 | | | 412 ----------------------------------------------------------- 413 | | | 414 | Case 2a: sends immediate | 415 | RESPONSE to Node 1 | 416 | | | 417 | 2.RESPONSE(Accepted) | | 418 |< ------------------------| | 419 | | | 420 ----------------------------------------------------------- 421 | | | 422 | Case 2b: acts upon the REQUEST | 423 | | | 424 | | 3.REQUEST(GET, | 425 | | configuration) | 426 | |------------------------ >| 427 | | | 428 | | 4.RESPONSE | 429 | |(configuration for Node 1)| 430 | |< ------------------------| 431 | | | 432 | 5. checks Node 1 state | 433 | Node 1 is sleeping | 434 | | | 435 | caches RESPONSE | 436 | | | 437 Wakes up | | 438 | | | 439 |< == 6.sends updates === >| | 440 | | | 441 | 7.RESPONSE | | 442 |(configuration for Node 1)| | 443 |< ------------------------| | 444 | | | 445 | | | 447 Figure 4 Use Case 3: Constrained Node Getting Configuration 449 3.3.4. Use Case 4: Constrained Node Sending Report 451 Use case 4 shows a smart meter Node 1 sends report to Node 2. 453 Node 1 Proxy Node Node 2 454 (sleep cycles) (always on) (always on) 455 | | | 456 | 1.REQUEST(PUT, | | 457 | Meter Report) | | 458 |------------------------ >| | 459 | | | 460 ------------------------------------------------------------- 461 | | | 462 | case 2a: sends immediate | 463 | RESPONSE to Node 1 | 464 | | | 465 | 2. RESPONSE(Accepted) | | 466 | | | 467 ------------------------------------------------------------- 468 | case 2b: acts upon the REQUEST | 469 | | | 470 | | 3.REQUEST(PUT, | 471 | | Meter Report) | 472 | |------------------------ >| 473 | | | 474 | | 4.RESPONSE (Status) | 475 | |< ------------------------| 476 | | | 477 | 5 Caches RESPONSE | 478 | | 479 | Checks Node 1 sleeping state | 480 | Node 1 is sleeping | 481 | | | 482 Wakes up | | 483 | | | 484 |< == 6.sends updates === >| | 485 | | | 486 | 7.RESPONSE | | 487 | (Status) | | 488 |< ------------------------| | 489 | | | 491 Figure 5 Use Case 4: Constrained Node Sending Report 493 4. Multicast Support in CoAP 495 One of the requirements of the CoAP design is to support a simple and 496 unreliable multicast method. Supporting multicast poses additional 497 requirements to the proxy node. 499 Within the constrained network, an application protocol (e.g. CoAP) 500 usually runs over UDP for which IP multicast is supported. In a non- 501 constrained network (i.e. general Internet), HTTP over TCP is 502 typically used for which IP multicast is not naturally supported. 503 This causes the scenario below: 505 o The traffic within the constrained network is multicast (such 506 as CoAP over UDP), and within the non-constrained network it 507 is unicast (such as HTTP over TCP) 509 Therefore the proxy node needs to have functionality to support 510 interworking of unicast and multicast. Specifically, CoAP protocol 511 should include support for translating a HTTP/TCP unicast request 512 into a CoAP/UDP multicast request as illustrated in Figure 6. 514 CoAP/UDP HTTP/TCP 515 Multicast or Unicast Unicast 517 Constrained 518 Node ------| |------ Non-Constrained 519 | | Node 520 | | 521 | | 522 Constrained ------|-----Proxy Node-----|------ Non-Constrained 523 Node | | Node 524 | | 525 | | 526 Constrained ------| |------ Non-Constrained 527 Node Node 529 Figure 6 Multicast Support at Proxy Node 531 5. Conclusions 533 This draft analyzes three requirements identified in the CoAP design 534 requirement document [I-D.draft-shelby-core-coap-req] related to 535 handling sleeping nodes and supporting multicast. The draft discusses 536 some considerations for CoAP design and proxy operations to meet 537 these requirements. 539 For a constrained network to handle sleeping nodes, a constrained 540 node should be able to notify the proxy of its sleep schedule, and 541 the proxy node should have an updated schedule for each sleep node. 542 To utilize the sleep schedule, the sleep nodes and the proxy need to 543 maintain synchronization to a certain extent. A proxy node thus 544 enables asynchronous communications with the general Internet, since 545 a proxy node can always cache for the constrained nodes. 547 CoAP is targeted to interact with HTTP/TCP on the general Internet. 548 Since IP multicast does not support TCP, the proxy node in a 549 constrained network needs to have functionalities to support 550 interworking of multicast and unicast to fulfill this requirement. 552 6. Security Considerations 554 This draft discusses the design considerations and operations of CoAP 555 and CoAP proxy in constrained networks. It does not introduce new 556 security threats. 558 7. IANA Considerations 560 This document makes no request of IANA. 562 8. References 564 8.1. Normative References 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, March 1997. 569 8.2. Informative References 571 [I-D.draft-ietf-core-coap] Shelby, Z., Frank, B., and D. Sturek, 572 "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-00 573 (Work in progress), June 7, 2010. 575 [I-D.draft-frank-6lowpan-chopan] Frank, B., "Chopan - Compressed HTTP 576 Over PANs", draft-frank-6lowpan-chopan-00 (Work in 577 progress), June 15, 2009. 579 [I-D.draft-shelby-core-coap-req] Shelby, Z., Stuber, M., Sturek, D., 580 Frank, B., and R. Kelsey, "CoAP Requirements and Features", 581 draft-shelby-core-coap-req-01 (Work in progress), April 20, 582 2010. 584 9. Acknowledgments 586 Thanks to Jean-Louis Gauvreau and Dale Seed for their useful comments 587 and discussions. 589 Authors' Addresses 591 Akbar Rahman 592 InterDigital Communications, LLC 593 Email: Akbar.Rahman@InterDigital.com 595 Juan Carlos Zuniga 596 InterDigital Communications, LLC 597 Email: JuanCarlos.Zuniga@InterDigital.com 599 Guang Lu 600 InterDigital Communications, LLC 601 Email: Guang.Lu@InterDigital.com