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

"weigengyu" <weigengyu@bupt.edu.cn> Mon, 14 October 2013 10:26 UTC

Return-Path: <weigengyu@bupt.edu.cn>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A193421F9E96 for <core@ietfa.amsl.com>; Mon, 14 Oct 2013 03:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvxNKsSpPEeR for <core@ietfa.amsl.com>; Mon, 14 Oct 2013 03:26:31 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id A2F1221E815F for <core@ietf.org>; Mon, 14 Oct 2013 03:12:59 -0700 (PDT)
Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 0DE6A19F3A0; Mon, 14 Oct 2013 18:11:31 +0800 (HKT)
Message-ID: <7BE3D5EAF615441CA2C0A5157667FDCB@WeiGengyuPC>
From: weigengyu <weigengyu@bupt.edu.cn>
To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>
References: <D60519DB022FFA48974A25955FFEC08C05529BC9@SAM.InterDigital.com> <A027140C2AF449828323C6388B0C69B6@WeiGengyuPC> <D60519DB022FFA48974A25955FFEC08C055A236A@SAM.InterDigital.com>
In-Reply-To: <D60519DB022FFA48974A25955FFEC08C055A236A@SAM.InterDigital.com>
Date: Mon, 14 Oct 2013 18:11:29 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"; reply-type="original"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3505.912
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912
Cc: core@ietf.org
Subject: Re: [core] FW: New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Oct 2013 10:26:37 -0000

Hi, Akbar,

I agree that one defintion of  sleepy node is required for the WG.

Because low power state is the most important means for the mobile teminal 
to have longer working time,
the sleepy node concept should be considered.

By ROLL, sleepy node has two mode: sleep mode and normal (awake) mode.
To my knowledge,  a communication node costs more power to send than to 
receive,
so three modes, i.e.  awake, dummy, and sleep mode might be flexible.

regards,

Gengyu

-----原始邮件----- 
From: Rahman, Akbar
Sent: Saturday, October 12, 2013 12:38 PM
To: weigengyu
Cc: core@ietf.org
Subject: 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