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

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:weigengyu@bupt.edu.cn] 
Sent: Friday, October 11, 2013 2:27 AM
To: Rahman, Akbar
Cc: core@ietf.org
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 ; core@ietf.org
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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
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
core@ietf.org
https://www.ietf.org/mailman/listinfo/core 