Re: [core] New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt

[Zach Shelby <[e-mail]>]

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-need
> Htmlized: 
> http://tools.ietf.org/html/draft-rahman-core-sleepy-nodes-do-we-need-00
> 
> 
> 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