Re: [core] Do we need a CORE charter item for CoAP support of Sleepy Nodes?

Robert Cragie <robert.cragie@gridmerge.com> Mon, 05 August 2013 17:44 UTC

Return-Path: <robert.cragie@gridmerge.com>
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 B26AB21F9EAD for <core@ietfa.amsl.com>; Mon, 5 Aug 2013 10:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 GNywIXOZiO5f for <core@ietfa.amsl.com>; Mon, 5 Aug 2013 10:44:17 -0700 (PDT)
Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 30D4D21F9EC3 for <core@ietf.org>; Mon, 5 Aug 2013 10:44:11 -0700 (PDT)
Received: from [94.116.195.250] (helo=[10.38.240.170]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1V6Op8-0000Dl-IG for core@ietf.org; Mon, 05 Aug 2013 18:44:02 +0100
Message-ID: <51FFE462.7050903@gridmerge.com>
Date: Mon, 05 Aug 2013 18:44:02 +0100
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: core@ietf.org
References: <D60519DB022FFA48974A25955FFEC08C0537E49C@SAM.InterDigital.com> <51FBC0D2.2030909@ericsson.com> <51FEB8FF.9080101@anche.no> <5c07f5eb4caba701bd1c5b99cebe14a4@xs4all.nl> <6E0184DF-5393-48F7-AE1C-C09B2415DFEC@sensinode.com>
In-Reply-To: <6E0184DF-5393-48F7-AE1C-C09B2415DFEC@sensinode.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms030505070406020402070304"
X-Authenticated-As: robert.cragie@gridmerge.com
Subject: Re: [core] Do we need a CORE charter item for CoAP support of Sleepy Nodes?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
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, 05 Aug 2013 17:44:26 -0000

I agree too with what Zach and Peter say. Sleepy nodes have to be 
considered vertically through the stack so it goes beyond the reach of 
what is being done in CoRE. As mentioned in Berlin, there are two drafts 
in LWIG which look at the problem from an implementation standpoint 
across all layers as opposed to a protocol standpoint at a specific layer:

http://datatracker.ietf.org/doc/draft-hex-lwig-energy-efficient/
http://datatracker.ietf.org/doc/draft-hong-lwig-sleepynode-problem-statement/

Robert

On 05/08/2013 15:43, Zach Shelby wrote:
> I agree with Peter, and am also skeptical about this work item as it has been discussed so far.
>
> This is really a problem that needs to be solved within a complete architecture, and we don't really have that architecture here. Other SDOs have or are solving this problem using CoRE mechanisms, for example OMA Lightweight M2M already includes simple sleep (or in general non-reachable CoAP endpoint support) using RD and queueing at a proxy. Not to mention other L2 mechanisms or application layer designs that already solve the problem.
>
> If we would like to document a setup to support such endpoints, then it should probably done by just documenting something done in a complete architecture for the sake of allowing re-use. We also have existing solutions like Mirror Server that can be used in some cases where that architecture is applicable. Inventing new solutions outside a full architecture and real deployments needs seems like research to me.
>
> Finally, we just have way too much work on our plate right now in CoRE to even think about taking more on. First, we need to ship Observe and Block to the IESG (and through the whole process), then we have three other work items we've just started on. I would think it is not time to discuss something new until we're pretty stable with those three (close to shipping them e.g.). Taking sleep work on now would just distract us from making progress.
>
> Zach
>
> On Aug 5, 2013, at 9:35 AM, peter van der Stok <stokcons@xs4all.nl> wrote:
>
>> In contrast to the earlier mails I am personally not convinced we should do (much) work on sleepy nodes.
>> In the simplest level 3 communication case, a sleepy node needs intialization of operational parameters, is switched on, and sends regularly data to an IP address.
>> More specifically, the IP address can be an MPL multicast address.
>> Anything more complex needs to be done with a proxy.
>> In my opinion SDOs like OMA, ZigBee, or BACnet, etc. have very different opinions on what such a proxy should do and how to communicate between the sleepy node an the proxy. They are best positioned to define the proxy in the context of their organization.
>>
>> In the limit, at IETF, we just need to define a MIB for the initialization of the sleepy node.
>> If we want to do more, I think the draft by Matthieu Vial covers the case quite adequately.
>>
>> Peter van der Stok
>>
>>
>>
>> Pierpaolo Giacomin schreef op 2013-08-04 22:26:
>>> On 08/02/2013 05:23 PM, Salvatore Loreto wrote:
>>> I do think we should have in CORE a deliverable for CoAP support of
>>> Sleepy Nodes,
>>> +1
>>> we have seen a lot of ideas and mail discussion about this topic one
>>> year ago,
>>> and the 4 individual submissions (if I am not wrong there are also a
>>> couple of the expired drafts on the topic)
>>> on the same subject listed by Akbar is a clear sign of interest and
>>> energy to work on it
>>> cheers
>>> /Sal
>>> --
>>> Salvatore Loreto, PhD
>>> www.sloreto.com
>>> On 8/1/13 6:02 PM, Rahman, Akbar wrote:
>>> Hi,
>>> Carsten asked me to send this message out to the WG list as we did not
>>> have a chance to discuss the Sleepy Node topic in this IETF due to a
>>> lack of time on the agenda.
>>> ------------------------------------------------------------------------------
>>> We have several current I-Ds in CORE (and LWIG) that discusses the
>>> topic of Sleepy Nodes. Among those are:
>>> draft-dijk-core-sleepy-reqs-00
>>> <https://datatracker.ietf.org/doc/draft-dijk-core-sleepy-reqs/>
>>> draft-dijk-core-sleepy-solutions-01
>>> <https://datatracker.ietf.org/doc/draft-dijk-core-sleepy-solutions/>
>>> draft-hong-lwig-sleepynode-problem-statement-00
>>> <https://datatracker.ietf.org/doc/draft-hong-lwig-sleepynode-problem-statement/>
>>> draft-rahman-core-sleepy-03
>>> <https://datatracker.ietf.org/doc/draft-rahman-core-sleepy/>
>>> Hence the following question to the WG:
>>> ·Should we have a CORE deliverable for CoAP support of Sleepy Nodes?
>>> Please write back with your thoughts!
>>> Best Regards,
>>> Akbar
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core