CoRE Group A. Rahman Internet Draft JC. Zuniga Intended status: Informational G. Lu Expires: December 29, 2010 InterDigital Communications, LLC June 29, 2010 Sleeping and Multicast Considerations for CoAP draft-rahman-core-sleeping-00.txt Abstract This document further analyzes the COAP requirements related to "sleeping nodes" and "multicast" through the use of examples and use cases. The goal of this document is to trigger discussions in the CoRE working group so that all relevant considerations are taken into account when designing CoAP. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 29, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Rahman, et al. Expires December 29, 2010 [Page 1] Internet-Draft Sleeping and Multicast for CoAP June 2010 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction...................................................2 2. Conventions and Terminology....................................3 3. Handling Sleep Nodes...........................................3 3.1. General Behavior of Sleep Nodes...........................3 3.2. Handling Sleeping Nodes within CoAP.......................4 3.3. Use Cases.................................................7 3.3.1. Use Case 1: Smart Meter Reading......................7 3.3.2. Use Case 2: Smart Meter Firmware Upgrade.............9 3.3.3. Use Case 3: Obtaining Configuration.................10 3.3.4. Use Case 4: Constrained Node Sending Report.........12 4. Multicast Support in CoAP.....................................13 5. Conclusions...................................................14 6. Security Considerations.......................................14 7. IANA Considerations...........................................14 8. References....................................................14 8.1. Normative References.....................................14 8.2. Informative References...................................15 9. Acknowledgments...............................................15 1. Introduction The CoRE working group is chartered to design and standardize a Constrained Application Protocol (CoAP) for resource constrained devices and networks [I-D.draft-ietf-core-coap]. The requirements for CoRE are well documented group [I-D.draft-shelby-core-coap-req]. In this draft, we focus and expand discussions on some of these key requirements pertaining to sleeping nodes and multicast support. Specifically, the requirements we analyze are: Rahman, et al. Expires December 29, 2010 [Page 2] Internet-Draft Sleeping and Multicast for CoAP June 2010 REQ 3: The ability to deal with sleeping nodes. Devices may be powered off at any point in time but periodically "wake up" for brief periods of time. REQ 4: Protocol must support the caching of recent resource requests, along with caching subscriptions to sleeping nodes. REQ 9: CoAP will support a non-reliable IP multicast message to be sent to a group of Devices to manipulate a resource on all the Devices simultaneously. The use of multicast to query and advertise descriptions must be supported, along with the support of unicast responses. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The following are definitions of terminologies used in this draft. Sleep Mode: Refers to the state when a device is not able to send and/or receive any messages due to power conservation from the perspective of an application protocol (i.e. CoAP). Sleep Node: A device that may go to sleep mode from time to time. Sleeping Node: A device that is in sleep mode. 3. Handling Sleep Nodes 3.1. General Behavior of Sleep Nodes In this section we discuss different behaviors and scenarios of sleeping nodes. Such behaviors can affect the design of applications (such as CoAP) and network topologies (such as proxies and caching). Sleeping nodes can have various sleeping patterns. Sleep patterns can be predictable or totally unpredictable. For example, some nodes sleep at a fixed interval or upon certain triggers. Some nodes may sleep at irregular time intervals, or switch to sleep mode spontaneously. Some nodes stay in sleep mode and only wake up upon Rahman, et al. Expires December 29, 2010 [Page 3] Internet-Draft Sleeping and Multicast for CoAP June 2010 certain event triggers. A network may thus not be well aware of the sleeping state of a node at a given time. The duration of sleeping mode also varies largely, possibly from a few seconds to days. From the perspective of applications, it may not be affected by the sleeping period if it is very short. For example, a HTTP/TCP connection may still work (even if sub-optimally) if the sleep cycle is much shorter than the TCP retransmission timer. In contrast, if the sleeping period of a node exceeds a certain threshold it can impact an application. This threshold however, can be difficult to predict and often can vary from device to device and network to network. For example, this threshold can be very dependent on the topology of a constrained network especially for the case where a multi-hop path consists of multiple sleeping nodes. For this case, the cumulative effect of multiple sleeping nodes must be considered. The network topology also affects how to handle sleeping nodes. For example, in a star shaped network, a proxy node (assuming to be not a sleeping node) can cache for the sleeping nodes within the network in a centralized manner. However, in a P2P or mesh network, especially when multi-hops are involved, caching can be difficult and delivering of messages can be largely delayed due to nodes' sleeping cycles. In this case distributed proxying and caching at intermediate nodes within the network (rather than just a single node such as the border node or sink) may make sense, if intermediate nodes are not sleeping nodes and have adequate resources to support caching. 3.2. Handling Sleeping Nodes within CoAP Traffic generated for handling sleeping nodes should be minimized in a constrained network. A constrained device can delegate its authority to the proxy node for operations on its behalf. Therefore operations between the constrained device and its counterpart (e.g. a computer on the Internet) become asynchronous due to the proxy. Below we discuss the various aspects to consider for handling sleeping nodes with CoAP. 1) Exchange of sleeping schedule A node can optionally include its sleep schedule and exchange such information with other nodes and/or proxies. This provides proxy(s) with better awareness of all resources that they are able to proxy Rahman, et al. Expires December 29, 2010 [Page 4] Internet-Draft Sleeping and Multicast for CoAP June 2010 for as well as which devices sleep and their corresponding sleep cycle durations. Using this sleep information, the proxy(s) could choose which device resources it wants to create/maintain intercept caches for (e.g. support intercept caches only for sleeping devices), thus optimizing resource utilization within the proxy by selectively caching and also minimizing the impact on sleeping nodes by allowing them to sleep longer and not have to directly service incoming requests. 2) Proxy and device synchronization A common synchronization scheme is to have the device always inform the proxy of its latest sleep state by checking-in [I-D.frank- 6lowpan-chopan]. For example, the proxy can subscribe to a node and the node sends notification each time when it wakes up. However, this approach increases the traffic for managing the sleep state, especially when there are a large amount of nodes and they sleep frequently. A proxy can benefit from being synchronized to its associated constrained device's sleep and awake state. Ideally, if the proxy and device are synchronized in time and if the device has a predictable sleep schedule, the proxy can know whether the device is awake or not without the device having to check-in so often. However, time synchronization may be difficult to achieve for constrained devices. 3) Caching and Proxying It is assumed that the proxy node is awake all the time. A proxy can thus always cache for the constrained nodes, regardless of the node's sleep state. The proxy node would then act as an interception proxy. This is analogous to the concept of web caching (e.g. HTML pages, images, etc.) between a Web server and a Web browser used in the general Internet. Figure 1 shows a call flow when a constrained node (Node 1) sends a REQUEST to Node 2. The REQUEST can contain any method, GET, POST, PUT, DELETE, or SUBSCRIBE. The figure illustrates two scenarios. In Case 2a, the proxy sends a RESPONSE with intermediate status. After that, Node 1 may go to sleep mode, and receive the requested content in step 6 after it wakes up. In Case 2b, the proxy acts upon the REQUEST immediately. Node 1 may go into sleep mode at any time after sending the REQUEST, if it can handle delayed response. The proxy node is in sync with Node 1 for its sleep state and caches the Rahman, et al. Expires December 29, 2010 [Page 5] Internet-Draft Sleeping and Multicast for CoAP June 2010 RESPONSE for it when it is in sleep mode. When Node 1 wakes up, it can notify the proxy with its sleep schedule (if changed) and send data for caching as the procedure shown in step 5. Node 1 Proxy Node Node 2 (sleep cycles) (always on) (always on) | | | | 1.REQUEST(GET,POST,PUT | | | DELETE, SUBSCRIBE) | | |------------------------ >| | | | | ----------------------------------------------------------- | | | | Case 2a: sends immediate | | RESPONSE to Node 1 | | | | | 2. RESPONSE/NOTIFY | | | (Accepted) | | |< ------------------------| | | | | ---------------------------------------------------------- | | | | Case 2b: acts upon the REQUEST | | | | | | 3.REQUEST(GET,POST,PUT | | | DELETE, SUBSCRIBE) | | |------------------------ >| | | | | | 4.RESPONSE | | |< ------------------------| | | | | caches RESPONSE | | | | | checks sleep state of Node 1 | | | | | | | Wakes up | | | | | | 5. Sends updates | | | (sleep schedule) | | | (other contents) | | |< ====================== >| | | | | |< -6.RESPONSE/NOTIFY------| | | | | Rahman, et al. Expires December 29, 2010 [Page 6] Internet-Draft Sleeping and Multicast for CoAP June 2010 Figure 1 Caching and Proxying 3.3. Use Cases In this section, different scenarios are illustrated to show the operations of a proxy node for GET and non-GET REQUESTs. The REQUEST can be from the constrained or non-constrained domain. For the following figures, Node 1 is a constrained node and it goes to sleep from time to time. Node 2 is a node in the non-constrained domain. It is assumed that the proxy node and Node 2 do not go to sleep. The protocol between Node 1 and the Proxy Node is CoAP, and the protocol between the Proxy Node and Node 2 is HTTP. The figures show some key scenarios but are not exhaustive. 3.3.1. Use Case 1: Smart Meter Reading In use case 1, Node 1 is a smart meter in the constrained network, and Node 2 in the non-constrained network wants to read the data from Node 1. The proxy can enable asynchronous communication between Node 1 and Node 2. In situation 2a, since the proxy node has an updated cache for what Node 2 is requesting, the proxy can respond to Node 2, regardless of Node 1's sleep state. In situation 2b, if the proxy does not have an updated cache, and Node 1 is sleeping, the proxy can send a RESPONSE to Node 2 with RETRY-AFTER information. The proxy would need to be synchronized with Node 1 and have Node 1's sleep schedule. Otherwise the proxy has to poll Node 1, which can cause a long delay and extra messaging. The synchronization is shown in step 5. When Node 1 wakes up, it can notify the proxy with its sleep schedule (if changed) and send data for caching. Alternatively, as shown in step 2b', the proxy may buffer the REQUEST and only send a RESPONSE when it gets information from Node 1. This can reduce messaging for Node 2 to query again. The proxy should know the sleep schedule of Node 1 to make such a decision on how it reacts. If Node 1 is not waking up in a very long time, it is probably better for the proxy to send RESPONSE to Node 2 immediately. Otherwise the long delay can cause time-out and retry of Node 2. Rahman, et al. Expires December 29, 2010 [Page 7] Internet-Draft Sleeping and Multicast for CoAP June 2010 Node 1 Proxy Node Node 2 (sleep cycles) (always on) (always on) | | | | | 1.REQUEST(GET, | | | meter reading) | | |< ----------------------- | | | | | 2. Checks its cache | --------------------------------------------------------- | Case 2a: Has updated cache | | | | | | 3.RESPONSE(meter reading)| | |------------------------ >| --------------------------------------------------------- | | | | Case 2b: No cache, Node 1 is sleeping | | | | | |4.RESPONSE(Retry-After) | | |------------------------ >| wakes up | | | | | |< === 5.sends update === >| | | (with meter reading) | | | | | | updates cache | | and Node 1's schedule | | |< == 6.Node 2 sends === > | | | REQUEST again | --------------------------------------------------------- | | | | Case 2b': No cache, Node 1 is sleeping | | buffers REQUEST | wakes up | | | | | |< === 5.sends updates == >| | | (with meter reading) | | | updates cache | | and Node 1's schedule | | | | | | 6.RESPONSE(meter reading)| | |------------------------ >| | | | Figure 2 Use Case 1: Smart Meter Reading Rahman, et al. Expires December 29, 2010 [Page 8] Internet-Draft Sleeping and Multicast for CoAP June 2010 3.3.2. Use Case 2: Smart Meter Firmware Upgrade In use case 2, Node 1 is a smart meter in a constrained network and Node 2 upgrades Node 1's firmware using PUT. If the proxy knows that Node 1 is sleeping, it can either advise Node 2 to retry later, or the proxy can buffer the REQUEST till Node 1 wakes up. Node 1 Proxy Node Node 2 (sleep cycles) (always on) (always on) | | | | | 1.REQUEST(PUT, | | | firmware for Node 1) | | |< ----------------------- | | | | | 2. checks Node 1 state | | Node 1 is sleeping | | | | | | | --------------------------------------------------------- | | | | Case 3a: no buffering | | | | | | 3.RESPONSE(Retry-After) | | |------------------------ >| | | | --------------------------------------------------------- | | | | Case 3b: buffers REQUEST | | | | | | | wakes up | | | | | |< === 4.sends updates == >| | | | | | 5.REQUEST (PUT, | | | firmware for Node 1) | | |< ------------------------| | | 6.RESPONSE (Status) | | |----------------------- > | | | | | | | 7.RESPONSE(Status) | Rahman, et al. Expires December 29, 2010 [Page 9] Internet-Draft Sleeping and Multicast for CoAP June 2010 | |------------------------ >| | | | | | | Figure 3 Use Case 2: Smart Meter Firmware Upgrade 3.3.3. Use Case 3: Obtaining Configuration Use case 3 shows that Node 1 in a constrained network tried to obtain a configuration parameter from Node 2. Since the proxy is aware that Node 1 is a sleep node, the proxy sends RESPONSE to Node 1 immediately so that Node 1 can go to its sleep cycle. The proxy then requests and caches the configuration parameter for Node 1, and it can notify Node 1 when Node 1 wakes up. Rahman, et al. Expires December 29, 2010 [Page 10] Internet-Draft Sleeping and Multicast for CoAP June 2010 Node 1 Proxy Node Node 2 (sleep cycles) (always on) (always on) | | | | | | | 1.REQUEST (GET, | | | configuration) | | |------------------------ >| | | | | ----------------------------------------------------------- | | | | Case 2a: sends immediate | | RESPONSE to Node 1 | | | | | 2.RESPONSE(Accepted) | | |< ------------------------| | | | | ----------------------------------------------------------- | | | | Case 2b: acts upon the REQUEST | | | | | | 3.REQUEST(GET, | | | configuration) | | |------------------------ >| | | | | | 4.RESPONSE | | |(configuration for Node 1)| | |< ------------------------| | | | | 5. checks Node 1 state | | Node 1 is sleeping | | | | | caches RESPONSE | | | | Wakes up | | | | | |< == 6.sends updates === >| | | | | | 7.RESPONSE | | |(configuration for Node 1)| | |< ------------------------| | | | | | | | Figure 4 Use Case 3: Constrained Node Getting Configuration Rahman, et al. Expires December 29, 2010 [Page 11] Internet-Draft Sleeping and Multicast for CoAP June 2010 3.3.4. Use Case 4: Constrained Node Sending Report Use case 4 shows a smart meter Node 1 sends report to Node 2. Node 1 Proxy Node Node 2 (sleep cycles) (always on) (always on) | | | | 1.REQUEST(PUT, | | | Meter Report) | | |------------------------ >| | | | | ------------------------------------------------------------- | | | | case 2a: sends immediate | | RESPONSE to Node 1 | | | | | 2. RESPONSE(Accepted) | | | | | ------------------------------------------------------------- | case 2b: acts upon the REQUEST | | | | | | 3.REQUEST(PUT, | | | Meter Report) | | |------------------------ >| | | | | | 4.RESPONSE (Status) | | |< ------------------------| | | | | 5 Caches RESPONSE | | | | Checks Node 1 sleeping state | | Node 1 is sleeping | | | | Wakes up | | | | | |< == 6.sends updates === >| | | | | | 7.RESPONSE | | | (Status) | | |< ------------------------| | | | | Figure 5 Use Case 4: Constrained Node Sending Report Rahman, et al. Expires December 29, 2010 [Page 12] Internet-Draft Sleeping and Multicast for CoAP June 2010 4. Multicast Support in CoAP One of the requirements of the CoAP design is to support a simple and unreliable multicast method. Supporting multicast poses additional requirements to the proxy node. Within the constrained network, an application protocol (e.g. CoAP) usually runs over UDP for which IP multicast is supported. In a non- constrained network (i.e. general Internet), HTTP over TCP is typically used for which IP multicast is not naturally supported. This causes the scenario below: o The traffic within the constrained network is multicast (such as CoAP over UDP), and within the non-constrained network it is unicast (such as HTTP over TCP) Therefore the proxy node needs to have functionality to support interworking of unicast and multicast. Specifically, CoAP protocol should include support for translating a HTTP/TCP unicast request into a CoAP/UDP multicast request as illustrated in Figure 6. CoAP/UDP HTTP/TCP Multicast or Unicast Unicast Constrained Node ------| |------ Non-Constrained | | Node | | | | Constrained ------|-----Proxy Node-----|------ Non-Constrained Node | | Node | | | | Constrained ------| |------ Non-Constrained Node Node Figure 6 Multicast Support at Proxy Node Rahman, et al. Expires December 29, 2010 [Page 13] Internet-Draft Sleeping and Multicast for CoAP June 2010 5. Conclusions This draft analyzes three requirements identified in the CoAP design requirement document [I-D.draft-shelby-core-coap-req] related to handling sleeping nodes and supporting multicast. The draft discusses some considerations for CoAP design and proxy operations to meet these requirements. For a constrained network to handle sleeping nodes, a constrained node should be able to notify the proxy of its sleep schedule, and the proxy node should have an updated schedule for each sleep node. To utilize the sleep schedule, the sleep nodes and the proxy need to maintain synchronization to a certain extent. A proxy node thus enables asynchronous communications with the general Internet, since a proxy node can always cache for the constrained nodes. CoAP is targeted to interact with HTTP/TCP on the general Internet. Since IP multicast does not support TCP, the proxy node in a constrained network needs to have functionalities to support interworking of multicast and unicast to fulfill this requirement. 6. Security Considerations This draft discusses the design considerations and operations of CoAP and CoAP proxy in constrained networks. It does not introduce new security threats. 7. IANA Considerations This document makes no request of IANA. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Rahman, et al. Expires December 29, 2010 [Page 14] Internet-Draft Sleeping and Multicast for CoAP June 2010 8.2. Informative References [I-D.draft-ietf-core-coap] Shelby, Z., Frank, B., and D. Sturek, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-00 (Work in progress), June 7, 2010. [I-D.draft-frank-6lowpan-chopan] Frank, B., "Chopan - Compressed HTTP Over PANs", draft-frank-6lowpan-chopan-00 (Work in progress), June 15, 2009. [I-D.draft-shelby-core-coap-req] Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. Kelsey, "CoAP Requirements and Features", draft-shelby-core-coap-req-01 (Work in progress), April 20, 2010. 9. Acknowledgments Thanks to Jean-Louis Gauvreau and Dale Seed for their useful comments and discussions. Authors' Addresses Akbar Rahman InterDigital Communications, LLC Email: Akbar.Rahman@InterDigital.com Juan Carlos Zuniga InterDigital Communications, LLC Email: JuanCarlos.Zuniga@InterDigital.com Guang Lu InterDigital Communications, LLC Email: Guang.Lu@InterDigital.com Rahman, et al. Expires December 29, 2010 [Page 15]