One document matched: draft-cao-core-aol-req-00.txt

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]