[core] Sleepy devices: OMA lightweight queue mode for CoAP

["Dijk, Esko" <[e-mail]>]

Hello Zach, all,

> In the OMA Lightweight standard, the mechanism that uses CoAP to solve this problem was just called a "queue mode". This is in practice realised with a Proxy and
> an RD in the same box. An RD registration parameter is used to indicate that a node is in queue mode. From there on the proxy queues all incoming requests to the
> node, which are released upon reception of a registration update request from the node. If the WG wants, this could fairly easily be documented in the Resource
> Directory draft maintaining compatibility with OMA Lightweight.

In this solution, does the Proxy queue a CoAP request for an arbitrary time period? I assume it works as follows

1- the CoAP client that needs to reach the sleepy/intermittent-connectivity endpoint (SICEP) sends a CON request to Proxy, containing the Proxy-Uri or Proxy-Scheme option
2- Proxy ACKs the CON message and puts the request in queue
3- SICEP wakes up, updates its registration on Proxy
4- Proxy sends queued request (CON) to SICEP
(- optional: if request fails to be delivered to SICEP it is re-queued for next time; then move back to step 3)
5- Proxy receives CoAP response from SICEP
6- Proxy delivers response to the CoAP client (using CON)

From core-coap I understand there is no inherent limit to the time between a CoAP request and its response. E.g. it may be 24 hours in above example.
I wonder if current implementations of core-coap allow this, or are tested on this aspect.

One benefit of this solution (if I see it right) is that there is no resource delegation/buffering needed at all. A drawback is that the SICEP needs to acts as CoAP server as well as CoAP client, while some other solutions require only CoAP-client functionality in the SICEP.

Esko

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Zach Shelby
Sent: Monday, October 14, 2013 18:14
To: Rahman, Akbar
Cc: [e-mail]
Subject: Re: [core] New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt

Hi,

I think "Sleepy Nodes" really misses the broader point. What we are really dealing with is a node with intermittent reachability, "I'll call you, don't call me". Sleeping might just be one reason why this happens, a NAT is another even more common one. And on cellular networks nodes typically come on the network just long enough to get their business done.

In the OMA Lightweight standard, the mechanism that uses CoAP to solve this problem was just called a "queue mode". This is in practice realised with a Proxy and an RD in the same box. An RD registration parameter is used to indicate that a node is in queue mode. From there on the proxy queues all incoming requests to the node, which are released upon reception of a registration update request from the node. If the WG wants, this could fairly easily be documented in the Resource Directory draft maintaining compatibility with OMA Lightweight.

Although Mirror Server is a useful paradigm for some use cases (and we should eventually document it), I find it less useful as it limits the REST operations that can be performed.

Zach

On Oct 11, 2013, at 9:38 PM, "Rahman, Akbar" <[e-mail]> wrote:

> Thanks, Gengyu, for your support for the topic of Sleepy Nodes.
>
> I agree that we can have different definitions of what we mean from a CORE perspective for a Sleepy Node.  At this point (until we adopt a WG deliverable for this topic) one definition is just as valid as another.  However, it is also interesting to see what other WGs are doing.  So for example, in ROLL, the definition is:
>
>
> http://tools.ietf.org/html/draft-ietf-roll-terminology-13
>
>
>   Sleepy Node: A sleepy node is a node that may sometimes go into a
>   sleep mode (i.e.  go into a low power state to conserve power) and
>   temporarily suspend protocol communication.  When no in a sleep mode,
>   the sleepy node is in a fully powered on state where it has the
>   capability to perform communication.
>
>
> And this ROLL definition, at least, is similar to the one from
> draft-dijk-core-sleepy-reqs-00
>
>
>
> Best Regards,
>
>
> Akbar
>
>
>
> -----Original Message-----
> From: weigengyu [mailto:[e-mail]]
> Sent: Friday, October 11, 2013 2:27 AM
> To: Rahman, Akbar
> Cc: [e-mail]
> Subject: Re: [core] FW: New Version Notification
> fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
>
> Hi, Rahman,
>
> My answer the question "Should we have a CORE deliverable for CoAP support of Sleepy Nodes?" is YES.
>
> But I have some questions about the use cases.
> According to "Sleepy Devices using CoAP - Requirements draft-dijk-core-sleepy-reqs-00"
> the definitin of Sleeping/Asleep as following:
>   Sleeping/Asleep  : A SEP being in a "sleeping state" i.e. its network interface is disconnected and a SEP is not able to send or receive messages.
> So, a sleepy node should not start to communicate with other nodes.  The communication between sleepy nodes is not possible, that is given in "Problem statement and Use cases of Sleepy node in Constrained node networks draft-hong-lwig-sleepynode-problem-statement-00"
>
> When a node is in sleeping state, it can receive, but it cannot send.
> The sleeping node can be waken-up by a received message or timer expired event; therefore the node turns to be awake.
> An alarming message may cause the sleepy node awake and then to give response.
> The timer expired event may cause  the sleepy node awake and then to send heartbeat.
> A node can send a message out only when it is awake.
>
> Afterall, it is possible that the non-sleep node  initiates communication with a sleepy node. The sleep node is passive.
> If the node in sleepy state wants to respond the message, it firstly turns to awake state.
>
> regards,
>
> Gengyu
>
>
> -----原始邮件-----
> From: Rahman, Akbar
> Sent: Friday, October 11, 2013 11:39 AM
> To: Carsten Bormann ; [e-mail]
> Subject: [core] FW: New Version Notification
> fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
>
> Hi Carsten (and WG),
>
>
> I wrote a short draft based on the following question from IETF-87 (Berlin):
>
> "Should we have a CORE deliverable for CoAP support of Sleepy Nodes?"
>
> http://www.ietf.org/mail-archive/web/core/current/msg04750.html
>
>
>
> Any and all comments will be much appreciated.
>
>
>
> Akbar
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, October 10, 2013 11:34 PM
> To: Rahman, Akbar; Rahman, Akbar
> Subject: New Version Notification
> fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
>
>
> A new version of I-D, draft-rahman-core-sleepy-nodes-do-we-need-00.txt
> has been successfully submitted by Akbar Rahman and posted to the IETF
> repository.
>
> Filename: draft-rahman-core-sleepy-nodes-do-we-need
> Revision: 00
> Title: Sleepy Devices: Do we need to Support them in CORE?
> Creation date: 2013-10-11
> Group: Individual Submission
> Number of pages: 6
> URL:
> http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-nodes-do-
> we-need-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-rahman-core-sleepy-nodes-do-we-n
> eed
> Htmlized:
> http://tools.ietf.org/html/draft-rahman-core-sleepy-nodes-do-we-need-0
> 0
>
>
> Abstract:
>   This document summarizes the discussion in the CORE WG related to the
>   question of whether support of sleepy devices is required for the
>   CoAP protocol, CORE Link Format, CORE Resource Directory, etc.  The
>   only goal of this document is to trigger discussions in the CORE WG
>   so that all relevant considerations for sleeping devices are taken
>   into account.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: [phone]
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net




_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.