idnits 2.17.1 draft-cao-core-aol-req-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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 4, 2011) is 4678 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-06 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-02 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group Z. Cao 3 Internet-Draft China Mobile 4 Intended status: Informational July 4, 2011 5 Expires: January 5, 2012 7 Allways-online Requirement for Sleeping CoAP Node 8 draft-cao-core-aol-req-00 10 Abstract 12 CoAP is to enable a concept of web of sensors, but there are many 13 cases that the sensors are not always online and hence the requests 14 from the web client cannot reach them in timely manner. This 15 document analyzes this problem and describes the requirements for a 16 CoAP enabled sensor to behave always online. 18 Status of this Memo 20 This Internet-Draft is submitted 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). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 5, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Conventions used in this document . . . . . . . . . . . . . 4 54 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Posible Solutions . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1. Introduction 63 CoAP [I-D.ietf-core-coap] is an Application Protocol for Constrained 64 Nodes/Networks. It is intended to provide RESTful services like HTTP 65 [RFC2616], while reducing the complexity of implementation as well as 66 the size of packets exchanged in order to make these services useful 67 in a highly constrained network of themselves highly constrained 68 nodes. 70 In the Web environment built from HTTP, the resources are distributed 71 among the web servers and clients get/post resources from these 72 always-online servers. Different from HTTP, the usual use case for 73 CoAP is deploy the CoAP server on the tiny sensors and have the Web 74 client visit the resources on the sensor. 76 On normal cases where the web client can identify the CoAP sensor and 77 the sensor is also alive, CoAP can work perfect. But there are cases 78 that the sensor is unreachable from the ourside network, e.g., as in 79 Figure 1. In this situation, the client cannot directly post/get 80 information from the sensor, and the only way to walk around is to 81 have the sensor proactively connects to the web first of all. 83 +--------+ +------------+ 84 | sensor |-------------------------| web client | 85 +--------+ +------------+ 86 | \ / COAP-GET | 87 +----------X-------------------------+ 88 | / \ | 89 | | 91 Figure 1: Idle CoAP Sensor Server 93 In the constrained network environment, this may happen occasionally 94 because the sensors are too constrained to be always online, 95 including the following cases: 97 1. Sleepy nodes: the tiny sensors that are battery supplied may 98 occasionally fall asleep caused by duty circled MAC or higher 99 layer energy constrained mechanisms. 101 2. Celluar access nodes: if the sensor directly connects to the 102 cellular network with a celluar modular, it may occasionally lose 103 its IP address dure the timeout mechanism on GPRS connections. 104 The network side can hardly wake up the sensor node from the IP 105 network. The only way is to have the sensor node wake up and 106 connect to the network proactively. 108 3. NAT constraint: if the sensor is behind an NAT device (either 109 IPv4 NAT or IPv6 NAT), and the mapping relationship between the 110 inter and outer address retires, the Internet client cannot reach 111 the sensor either. The fact that CoAP messages are carried over 112 UDP makes the situation worse, because the UDP mapping timeouts 113 more frequently on the NAT boxes. 115 In all the above cases, if the web client wants to get the updated 116 information from the sensors, there should be mechanisms to provide 117 the network layer connectivity to enable the CoAP functions. Or in 118 another word, the sensor should behave always online in order to 119 build a real web-of-sensor environment. 121 This documents analyzes this problem and describes the requirements 122 for a CoAP enabled sensor to behave always online. 124 1.1. Conventions used in this document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119] 130 2. Requirements 132 We described the requirements for CoAP always online as follows: 134 1. Support of the GET method. When the web client wants to retrieve 135 the most updated information on the sensor, the GET request can 136 reach the sensor within a reasonable delay. Note that for 137 frequently changed states, the coap observe 138 [I-D.ietf-core-observe] can be used to register the subject 139 changes on-demand. But still, the initial CoAP observe message 140 needs to reach the sensor whenever requested. 141 2. Support of the POST method. When the web client requests the 142 representation be processed by the CoAP server, it sends the POST 143 method to the corresponding URI. In order to behave always 144 online, the POST method request should be able to reach the 145 sensor within a reasonable delay. 146 3. Support of the PUT method. The PUT method requests that the 147 resource identified by the request URI be updated or created with 148 the enclosed representation. It requires that the PUT method 149 request sent by the web client be processed by sensor server 150 properly. 151 4. Support of the DELETE method. The DELETE method requests that 152 the resource identified by the request URI be deleted. It 153 requires that the PUT method request sent by the web client be 154 processed by sensor server properly. 156 5. Minimize complexity. In line with the constrained environment, 157 it requires that the method to make the sensor always online 158 minimize the complexity. For example, it should avoid repeated 159 polling or keep-alive messages. 161 3. Posible Solutions 163 4. Security Considerations 165 TBD. 167 5. IANA Considerations 169 This document does not require any IANA actions. 171 6. Normative References 173 [I-D.ietf-core-coap] 174 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 175 "Constrained Application Protocol (CoAP)", 176 draft-ietf-core-coap-06 (work in progress), May 2011. 178 [I-D.ietf-core-observe] 179 Hartke, K. and Z. Shelby, "Observing Resources in CoAP", 180 draft-ietf-core-observe-02 (work in progress), March 2011. 182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 183 Requirement Levels", BCP 14, RFC 2119, March 1997. 185 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 186 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 187 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 189 Author's Address 191 Zhen Cao 192 China Mobile 193 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 194 Beijing 100053 195 China 197 Email: zehn.cao@gmail.com