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

["Dijk, Esko" <[e-mail]>]

> 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:[e-mail]]
Sent: Wednesday, November 13, 2013 18:48
To: Dijk, Esko
Cc: [e-mail]; Rahman, Akbar
Subject: Re: Sleepy devices: OMA lightweight queue mode for CoAP

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

On Nov 11, 2013, at 1:21 AM, "Dijk, Esko" <[e-mail]> 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
> 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.

Zach Shelby
Director of Technology
ARM Internet of Things BU
www.arm.com
mobile: [phone]
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


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