Subject: [core] FW: New Version Notification for draft-rahman-core-sleepy-nodes-do-we-need-00.txt

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 10 Oct 2013 23:39:05 -0400

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: [email-masked] [mailto:[email-masked]] 
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

---

From: "weigengyu" <[email-masked]>
Date: Fri, 11 Oct 2013 14:26:40 +0800

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 ; [email-masked]
Subject: [core] FW: New Version Notification 
fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt

Hi Carsten (and WG),

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
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:

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
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 11 Oct 2013 07:48:39 +0100

Hi Akbar, thank you very much for this.

I think you are providing a really good service to the working group
in keeping the background discussion on this important topic alive.

Personally, I think that providing a set of in-protocol mechanisms (a
bunch of Options, basically) to tackle well known and understood
scenarios (as opposed to a fully fledged architecture to support
Sleepy nodes, which other SDOs are in a better position to provide) is
something that is perfectly in scope with CoAP goals and WG interest
and energy  -- as you sensed it back in August.

And yes, I'd have given you my +1 when you polled the mailing list
about this, if I weren't on holiday :-)

Cheers

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 11 Oct 2013 08:48:04 +0000

>         "Should we have a CORE deliverable for CoAP support of Sleepy Nodes?"
Yes!  (motivation: existing WG documents do not provide the complete solution yet that is required at CoAP level)

> of in-protocol mechanisms (a bunch of Options, basically)
I don't fully agree; it could be one or more options that are needed; it could be perhaps done without new options.
The thing that is needed at least, in my opinion, is functionality like [I-D.vial-core-mirror-server].  (If needed I can motivate this further on the list with use cases.)

> (as opposed to a fully fledged architecture to support Sleepy nodes, which other SDOs are in a better position to provide)
Agree. I see mirror server as an example of a useful/required component, but it is not a full architecture yet. But any CoRE defined 'building block' should fit in such architectures.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Fossati
Sent: Friday, October 11, 2013 08:49
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] FW: New Version Notification for draft-rahman-core-sleepy-nodes-do-we-need-00.txt

I think you are providing a really good service to the working group in keeping the background discussion on this important topic alive.

Personally, I think that providing a set of in-protocol mechanisms (a bunch of Options, basically) to tackle well known and understood scenarios (as opposed to a fully fledged architecture to support Sleepy nodes, which other SDOs are in a better position to provide) is something that is perfectly in scope with CoAP goals and WG interest and energy  -- as you sensed it back in August.

And yes, I'd have given you my +1 when you polled the mailing list about this, if I weren't on holiday :-)

Cheers

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

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sat, 12 Oct 2013 00:38:46 -0400

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:[email-masked]] 
Sent: Friday, October 11, 2013 2:27 AM
To: Rahman, Akbar
Cc: [email-masked]
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 ; [email-masked]
Subject: [core] FW: New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt

Hi Carsten (and WG),

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 10, 2013 11:34 PM
To: Rahman, Akbar; Rahman, Akbar
Subject: New Version Notification

Abstract:

The IETF Secretariat

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sat, 12 Oct 2013 00:44:19 -0400

Hi Esko/Thomas,

First, thanks for adding your voices to the support of creating a CORE
deliverable for Sleepy Nodes.  That is definitely appreciated.

I agree that [I-D.vial-core-mirror-server] is a good starting point for
Sleepy Node support.  However, I made the following relevant observation
in my draft:

http://tools.ietf.org/html/draft-rahman-core-sleepy-nodes-do-we-need-00#
section-5

	Another point to consider is that during WG discussions, the
CORE
   Mirror Server [I-D.vial-core-mirror-server]  is sometimes referred to
   as the "existing" solution for CORE Sleepy Node support.  However,
   this draft was never adopted as a WG draft.

Best Regards,

Akbar

-----Original Message-----
From: Dijk, Esko [mailto:[email-masked]] 
Sent: Friday, October 11, 2013 4:48 AM
To: Thomas Fossati; Rahman, Akbar
Cc: [email-masked]
Subject: RE: [core] FW: New Version Notification

 >         "Should we have a CORE deliverable for CoAP support of Sleepy
Nodes?"
Yes!  (motivation: existing WG documents do not provide the complete
solution yet that is required at CoAP level)

> of in-protocol mechanisms (a bunch of Options, basically)
I don't fully agree; it could be one or more options that are needed; it
could be perhaps done without new options.
The thing that is needed at least, in my opinion, is functionality like
[I-D.vial-core-mirror-server].  (If needed I can motivate this further
on the list with use cases.)

> (as opposed to a fully fledged architecture to support Sleepy nodes,
which other SDOs are in a better position to provide)
Agree. I see mirror server as an example of a useful/required component,
but it is not a full architecture yet. But any CoRE defined 'building
block' should fit in such architectures.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas Fossati
Sent: Friday, October 11, 2013 08:49
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] FW: New Version Notification for
draft-rahman-core-sleepy-nodes-do-we-need-00.txt

I think you are providing a really good service to the working group in
keeping the background discussion on this important topic alive.

Personally, I think that providing a set of in-protocol mechanisms (a
bunch of Options, basically) to tackle well known and understood
scenarios (as opposed to a fully fledged architecture to support Sleepy
nodes, which other SDOs are in a better position to provide) is
something that is perfectly in scope with CoAP goals and WG interest and
energy  -- as you sensed it back in August.

And yes, I'd have given you my +1 when you polled the mailing list about
this, if I weren't on holiday :-)

Cheers

repository.
> Group:           Individual Submission
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-nee
d
> 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 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.

---

From: "weigengyu" <[email-masked]>
Date: Mon, 14 Oct 2013 18:11:29 +0800

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: [email-masked]
Subject: RE: [core] FW: New Version Notification 

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:

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:[email-masked]]
Sent: Friday, October 11, 2013 2:27 AM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] FW: New Version Notification 

Hi, Rahman,

regards,

Gengyu

-----原始邮件-----
From: Rahman, Akbar
Sent: Friday, October 11, 2013 11:39 AM
To: Carsten Bormann ; [email-masked]
Subject: [core] FW: New Version Notification 

Hi Carsten (and WG),

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 10, 2013 11:34 PM
To: Rahman, Akbar; Rahman, Akbar
Subject: New Version Notification

Abstract:

The IETF Secretariat

---

From: Zach Shelby <[email-masked]>
Date: Mon, 14 Oct 2013 09:14:28 -0700

Hi,

I think "Sleepy Nodes" really misses the broader point. What we are really dealing with is a node with intermittent reachability, "I'll call you, don't call me". Sleeping might just be one reason why this happens, a NAT is another even more common one. And on cellular networks nodes typically come on the network just long enough to get their business done. 

In the OMA Lightweight standard, the mechanism that uses CoAP to solve this problem was just called a "queue mode". 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. 

Although Mirror Server is a useful paradigm for some use cases (and we should eventually document it), I find it less useful as it limits the REST operations that can be performed.

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

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 15 Oct 2013 13:26:01 -0400

Hi Zach,

Thanks for the feedback.  I do support your suggestion of:

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

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.

Best Regards,

Akbar

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: Monday, October 14, 2013 12:14 PM
To: Rahman, Akbar
Cc: weigengyu; [email-masked]
Subject: Re: [core] New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt

Hi,

Zach 

On Oct 11, 2013, at 9:38 PM, "Rahman, Akbar" <[email-masked]> wrote:

> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Zach Shelby <[email-masked]>
Date: Tue, 15 Oct 2013 11:13:09 -0700

> 	"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 re…

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 so…

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

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 17 Oct 2013 08:53:46 +0000

> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: Tuesday, October 15, 2013 20:13
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt

Zach