Re: [core] WG interest in Sleepy Node topic

"weigengyu" <weigengyu@bupt.edu.cn> Wed, 11 December 2013 09:36 UTC

Return-Path: <weigengyu@bupt.edu.cn>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15C41AE033 for <core@ietfa.amsl.com>; Wed, 11 Dec 2013 01:36:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.237
X-Spam-Level: *
X-Spam-Status: No, score=1.237 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va2A1RyMFpDc for <core@ietfa.amsl.com>; Wed, 11 Dec 2013 01:36:40 -0800 (PST)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id A2F1D1A1F5B for <core@ietf.org>; Wed, 11 Dec 2013 01:36:37 -0800 (PST)
Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 4618319F36A; Wed, 11 Dec 2013 17:36:29 +0800 (HKT)
Message-ID: <FEE43668972443B484ED4BFF923A3F80@WeiGengyuPC>
From: weigengyu <weigengyu@bupt.edu.cn>
To: Carsten Bormann <cabo@tzi.org>
References: <D60519DB022FFA48974A25955FFEC08C0561B74B@SAM.InterDigital.com><CAByMhx9aWkuDR397hYYNBVQCmz1v5XLvihuieTUQE3YPOZqZJA@mail.gmail.com> <B29BEB02-85AF-454C-A500-F5B6F01E9D6F@tzi.org>
In-Reply-To: <B29BEB02-85AF-454C-A500-F5B6F01E9D6F@tzi.org>
Date: Wed, 11 Dec 2013 17:36:30 +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 <core@ietf.org>
Subject: Re: [core] WG interest in Sleepy Node topic
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 11 Dec 2013 09:36:44 -0000

Hi Carsten and all,

I think the Sleepy node problem is important, and CoAP mailing list seems to 
consider intermitent node currently.
While, what is the sleepy node and what is the intermitent node?
What network parameter are effected and what kind of networks needs 
concerning?

I would like to give what intermitent node (or intermitent endpoint) I 
concern.
I think the intermitent indicates the following situations of CoAP endpoint:
1. the node will be power off and on, or reboot;
2. the node will go out and into the signal coverage, so the wireless 
commnication could be able and inable intermitently;
3. the node is into sleep mode in order to save power. Such a node might be 
the sleepy node you called.
    Due to its inability to reponse the request, the sleepy node may be like 
the intermitent node.
   In other words, the sleepy node is an intermitent node in nature in terms 
of communication ability intervals.

The  bootup process is required in the above cases 1, but not in the cases 
of 2 and 3.
The network parameters , such as IP address, re-allocation is determined by 
the networks that the node accesses.

By Esko’ email, if the node is auto-configured by DHCP server, or the like,
the node could get back network configured parameters whenever reboot.
But this does not means that when rebooting the node saves the parameters 
itself enve though flash memory is embeded.
The most typical network is WIFI.  When the mobile PC reboots,
the DHCP server's parameters (option) determines whether to change the 
mobile PC's IP address.

The very different network is mobile 3G/4G, the mobile node will get new IP 
address in the case of 1 and  probably 2.
The node in sleepy mode closes the data sending port and/or receiving port.
The smart phone usually close both ports. (As a result signalling storm is 
apppeared in the mobile networks)
This is case 3, and the node holds its network parameters. The communication 
ability will be delayed until the sleepy interval is expired.

Maybe the problem of configuration is out of CoAP scope,  and it is not 
clear what the CoAP endpoint enviroments have.
Only the Resource Directory Server is depicted  and may function this in the 
given cases.

There is not a systematic processes defined to tackle sleepy or intermitent 
node.

So, the sleepy node I concerned is case 3; the intermitent node I concerned 
is case 1,2 and 3.

Regards,

Gengyu

Network Technology Center
School of Computer
Beijing University of Posts & Telecommunications.


-----原始邮件----- 
From: Carsten Bormann
Sent: Saturday, November 09, 2013 9:25 AM
To: Thomas Fossati
Cc: Core
Subject: Re: [core] WG interest in Sleepy Node topic

On 08 Nov 2013, at 01:48, Thomas Fossati <tho@koanlogic.com> wrote:

> out of CoRE scope

At this stage of the discussion, I would be less concerned with the WG scope 
than with finding out what the industry actually needs to be standardized to 
foster interoperability.  If there are items within this set that are 
outside CoRE scope, we can always try to find a home for them, either by 
rechartering or by finding another WG.  But it is important to have a clear 
understanding of the items that we think need to be speced.  At a level a 
bit more specific than we have been discussing so far.

Grüße, Carsten

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core