Subject: [core] Sleepy devices: OMA lightweight queue mode for CoAP

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 11 Nov 2013 09:21:55 +0000

Hello Zach, all,

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

In this solution, does the Proxy queue a CoAP request for an arbitrary time period? I assume it works as follows

1- the CoAP client that needs to reach the sleepy/intermittent-connectivity endpoint (SICEP) sends a CON request to Proxy, containing the Proxy-Uri or Proxy-Scheme option
2- Proxy ACKs the CON message and puts the request in queue
3- SICEP wakes up, updates its registration on Proxy
4- Proxy sends queued request (CON) to SICEP
(- optional: if request fails to be delivered to SICEP it is re-queued for next time; then move back to step 3)
5- Proxy receives CoAP response from SICEP
6- Proxy delivers response to the CoAP client (using CON)

From core-coap I understand there is no inherent limit to the time between a CoAP request and its response. E.g. it may be 24 hours in above example.
I wonder if current implementations of core-coap allow this, or are tested on this aspect.

One benefit of this solution (if I see it right) is that there is no resource delegation/buffering needed at all. A drawback is that the SICEP needs to acts as CoAP server as well as CoAP client, while some other solutions require only CoAP-client functionality in the SICEP.

Esko

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

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

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

> 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),
>
>
> 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-n
> eed
> Htmlized:
> http://tools.ietf.org/html/draft-rahman-core-sleepy-nodes-do-we-need-0
> 0
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

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

---

From: Zach Shelby <[email-masked]>
Date: Wed, 13 Nov 2013 09:47:36 -0800

Esko,

Only the what you might call the SICEP-PROXY interface is within scope of the OMA specification. How the client interacts with the proxy is out of scope. In the device management space the proxy often times is the application, in other cases it might be an HTTP reverse proxy.

The only timings discussed in the OMA spec are the CoAP timeouts used to time how long the SICEP can be assumed to be awake after sending a registration update.

I would prefer to document only the SICEP-PROXY interface, really that is the only part in scope of the resource directory specification anyways.

Zach

> One benefit of this solution (if I see it right) is that there is no resource delegation/buffering needed at all. A drawback is that the SICEP needs to acts as CoAP server as well as CoAP client, w…

Zach Shelby
Director of Technology
ARM Internet of Things BU
www.arm.com
mobile: +1 (408) 203-9434
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 26 Nov 2013 13:37:33 +0000

> in other cases it might be an HTTP reverse proxy.
Considering this case, wouldn't the HTTP request usually time out?
The 'SICEP' may typically wake up once a day and the HTTP connection would be dropped long before that. (A few minutes typically?)

I'm therefore wondering whether this request caching is suitable for the general case (where the requesting client is not integrated into the proxy node itself)

Esko

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]]
Sent: Wednesday, November 13, 2013 18:48
To: Dijk, Esko
Cc: [email-masked]; Rahman, Akbar
Subject: Re: Sleepy devices: OMA lightweight queue mode for CoAP

Esko,

Zach

On Nov 11, 2013, at 1:21 AM, "Dijk, Esko" <[email-masked]> wrote:

>> 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.
>
> In this solution, does the Proxy queue a CoAP request for an arbitrary
> time period? I assume it works as follows
>
> 1- the CoAP client that needs to reach the
> sleepy/intermittent-connectivity endpoint (SICEP) sends a CON request
> to Proxy, containing the Proxy-Uri or Proxy-Scheme option

Zach Shelby
Director of Technology

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Zach Shelby <[email-masked]>
Date: Tue, 26 Nov 2013 09:29:49 -0800

> The 'SICEP' may typically wake up once a day and the HTTP connection would be dropped long before that. (A few minutes typically?)

You would need to long-poll or use a callback of course.

Zach Shelby
Director of Technology

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 26 Nov 2013 19:49:43 +0200

Zach Shelby wrote:
> Esko Dijk wrote:

I'd expect a 2.xx (Accepted)* response here with Location options
indicating a resource that the client can poll or observe to track the
progress of the request.

(*like HTTP 202 Accepted
<http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25#section-6.3.3>;
currently not defined in CoAP)

Best regards,
Klaus

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 27 Nov 2013 06:44:10 +0000

Thanks,

> I'd expect a 2.xx (Accepted)* response here with Location options indicating
> a resource that the client can poll or observe to track the progress of the request.
For the HTTP-to-CoAP proxy case, status 202 seems to fit the use case very well.
In the CoAP Proxy case, a 2.xx (Accepted) is then the most intuitive solution.

With the solution of HTTP long polling: this assumes different knowledge on the HTTP client side, in the sense that the client already knows it may take very long and is prepared to long-poll for that amount of time and repeat its request. The "status 202" solution does not assume such pre-knowledge on the client side.

(Btw in the typical sleepy/SICEP use cases I consider, the HTTP client or CoAP client initiating a request via Proxy does not have this  pre-knowledge.)

Esko

-----Original Message-----
From: Klaus Hartke [mailto:[email-masked]]
Sent: Tuesday, November 26, 2013 18:50
To: Zach Shelby
Cc: Dijk, Esko; [email-masked]
Subject: Re: [core] Sleepy devices: OMA lightweight queue mode for CoAP

Zach Shelby wrote:
> Esko Dijk wrote:
>> The 'SICEP' may typically wake up once a day and the HTTP connection
>> would be dropped long before that. (A few minutes typically?)
>

I'd expect a 2.xx (Accepted)* response here with Location options indicating a resource that the client can poll or observe to track the progress of the request.

(*like HTTP 202 Accepted

Best regards,
Klaus