CoRE Working Group Z. Cao Internet-Draft China Mobile Intended status: Informational July 4, 2011 Expires: January 5, 2012 Allways-online Requirement for Sleeping CoAP Node draft-cao-core-aol-req-00 Abstract CoAP is to enable a concept of web of sensors, but there are many cases that the sensors are not always online and hence the requests from the web client cannot reach them in timely manner. This document analyzes this problem and describes the requirements for a CoAP enabled sensor to behave always online. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 5, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Simplified BSD License. Cao Expires January 5, 2012 [Page 1] Internet-Draft LWIP Gateway July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Posible Solutions . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Cao Expires January 5, 2012 [Page 2] Internet-Draft LWIP Gateway July 2011 1. Introduction CoAP [I-D.ietf-core-coap] is an Application Protocol for Constrained Nodes/Networks. It is intended to provide RESTful services like HTTP [RFC2616], while reducing the complexity of implementation as well as the size of packets exchanged in order to make these services useful in a highly constrained network of themselves highly constrained nodes. In the Web environment built from HTTP, the resources are distributed among the web servers and clients get/post resources from these always-online servers. Different from HTTP, the usual use case for CoAP is deploy the CoAP server on the tiny sensors and have the Web client visit the resources on the sensor. On normal cases where the web client can identify the CoAP sensor and the sensor is also alive, CoAP can work perfect. But there are cases that the sensor is unreachable from the ourside network, e.g., as in Figure 1. In this situation, the client cannot directly post/get information from the sensor, and the only way to walk around is to have the sensor proactively connects to the web first of all. +--------+ +------------+ | sensor |-------------------------| web client | +--------+ +------------+ | \ / COAP-GET | +----------X-------------------------+ | / \ | | | Figure 1: Idle CoAP Sensor Server In the constrained network environment, this may happen occasionally because the sensors are too constrained to be always online, including the following cases: 1. Sleepy nodes: the tiny sensors that are battery supplied may occasionally fall asleep caused by duty circled MAC or higher layer energy constrained mechanisms. 2. Celluar access nodes: if the sensor directly connects to the cellular network with a celluar modular, it may occasionally lose its IP address dure the timeout mechanism on GPRS connections. The network side can hardly wake up the sensor node from the IP network. The only way is to have the sensor node wake up and connect to the network proactively. Cao Expires January 5, 2012 [Page 3] Internet-Draft LWIP Gateway July 2011 3. NAT constraint: if the sensor is behind an NAT device (either IPv4 NAT or IPv6 NAT), and the mapping relationship between the inter and outer address retires, the Internet client cannot reach the sensor either. The fact that CoAP messages are carried over UDP makes the situation worse, because the UDP mapping timeouts more frequently on the NAT boxes. In all the above cases, if the web client wants to get the updated information from the sensors, there should be mechanisms to provide the network layer connectivity to enable the CoAP functions. Or in another word, the sensor should behave always online in order to build a real web-of-sensor environment. This documents analyzes this problem and describes the requirements for a CoAP enabled sensor to behave always online. 1.1. Conventions used in this document 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] 2. Requirements We described the requirements for CoAP always online as follows: 1. Support of the GET method. When the web client wants to retrieve the most updated information on the sensor, the GET request can reach the sensor within a reasonable delay. Note that for frequently changed states, the coap observe [I-D.ietf-core-observe] can be used to register the subject changes on-demand. But still, the initial CoAP observe message needs to reach the sensor whenever requested. 2. Support of the POST method. When the web client requests the representation be processed by the CoAP server, it sends the POST method to the corresponding URI. In order to behave always online, the POST method request should be able to reach the sensor within a reasonable delay. 3. Support of the PUT method. The PUT method requests that the resource identified by the request URI be updated or created with the enclosed representation. It requires that the PUT method request sent by the web client be processed by sensor server properly. 4. Support of the DELETE method. The DELETE method requests that the resource identified by the request URI be deleted. It requires that the PUT method request sent by the web client be processed by sensor server properly. Cao Expires January 5, 2012 [Page 4] Internet-Draft LWIP Gateway July 2011 5. Minimize complexity. In line with the constrained environment, it requires that the method to make the sensor always online minimize the complexity. For example, it should avoid repeated polling or keep-alive messages. 3. Posible Solutions 4. Security Considerations TBD. 5. IANA Considerations This document does not require any IANA actions. 6. Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-06 (work in progress), May 2011. [I-D.ietf-core-observe] Hartke, K. and Z. Shelby, "Observing Resources in CoAP", draft-ietf-core-observe-02 (work in progress), March 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Author's Address Zhen Cao China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: zehn.cao@gmail.com Cao Expires January 5, 2012 [Page 5]