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

> The trick is if we can document the bare minimum of the protocol and interface mechanisms needed to support those different applications.
+1
In this light, using one mechanism to address "intermittent reachability" nodes that also covers the sleepy nodes space would be great.
There are slight differences in properties but these indeed may not matter for the CoRE mechanism used. (For example, for a mains-powered cellular M2M node behind a NAT it could be not a problem to keep the GPRS connection 'alive' for 20 minutes when needed, or longer. For a power-harvesting device, it may only have energy storage to enable its radio for 20 seconds after which it has to sleep again.)

In November I will check some proposals in CoRE so far against the requirements for sleepy devices (http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00 ).
What I have so far is:

1. Mirror Server http://tools.ietf.org/html/draft-vial-core-mirror-server-01

2. Resource Directory with built-in request queuing (specs OMA Lightweight M2M)

3. Publish Option http://tools.ietf.org/html/draft-fossati-core-publish-monitor-options-01

4. RD based sleep tracking http://tools.ietf.org/html/draft-rahman-core-sleepy-04

Note that all above proposals are based on one fundamental assumption: the sleepy (or intermittent reachable) device needs to be a CoAP server. I.e. it has resources that another node needs to access. And that assumption could be dropped, while still being able to design a solution to meet the requirements I think. Though it may not be the prettiest solution.

Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zach Shelby
Sent: Tuesday, October 15, 2013 20:13
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: [core] New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt

On Oct 15, 2013, at 10:26 AM, "Rahman, Akbar" <Akbar.Rahman@InterDigital.com> wrote:

>       "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."

And as Peter rightly points out, if you go to far you are into lots of application specific issues. The trick is if we can document the bare minimum of the protocol and interface mechanisms needed to support those different applications.

> I think this would be a good first step to supporting these type of "intermittent reachability" nodes.  Bu it would still be worth having a discussion to see if we need to support more elaborate solutions like the Mirror Server.  The answer can always be "No (at least not in CORE)".  But until we have the discussion we cannot really conclude that.

Personally I do think this is worth documenting Mirror Server in the WG, but I don't think it solves the (intermittently reachable node) problem broadly enough to be a generic solution. So we should slowly move this towards a WG document as we get other things done first, and as there are people really implementing and using it.

Zach

--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

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

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.