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]