Internet Engineering Task Force                               T. Fossati
Internet-Draft                                                 KoanLogic
Intended status: Standards Track                             P. Giacomin
Expires: September 1, 2012                                     Freelance
                                                               S. Loreto
                                                                Ericsson
                                                              M. Rossini
                                          CS Dept. University of Bologna
                                                       February 29, 2012


                         Sleepy Option for CoAP
                  draft-giacomin-core-sleepy-option-00

Abstract

   This memo defines a framework for allowing asynchronous communication
   between sleepy sensors mediated by a supporting Proxy node.  The
   Proxy acts as a store-and-forward agent that handles requests on
   behalf of a sleepy client, and buffers responses coming from the
   target origin until the requesting client wakes up and get the
   computation results.

   A new CoAP option, Sleepy, is defined to initiate and control the
   asynchronous exchange.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 1, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Fossati, et al.         Expires September 1, 2012               [Page 1]


Internet-Draft           Sleepy Option for CoAP            February 2012


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Basic Message Flows  . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Basic Message Flow with CON Semantics  . . . . . . . . . .  4
     3.2.  Basic Message Flow with NON Semantics  . . . . . . . . . .  6
   4.  Optimized Message Flow . . . . . . . . . . . . . . . . . . . .  6
   5.  Sleepy Option  . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Limiting Network Congestion  . . . . . . . . . . . . . . . . . 10
   7.  New Link-Format Attributes . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     11.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12





















Fossati, et al.         Expires September 1, 2012               [Page 2]


Internet-Draft           Sleepy Option for CoAP            February 2012


1.  Introduction

   The proposal described in this memo covers the following use case:

      a node A, displaying a very short duty-cycle, needs to interact
      with one or more resources hosted at another sleepy node B. The
      probability of an empty intersection between their respective wake
      periods is quite high, making it hard for the two to synchronize.

   The proposal is to arm the Proxy with the ability to act as a store-
   and-forward agent mediating the request/response exchange between A
   and B.

   A declares the will to act onto a given resource hosted at B to the
   Proxy, and gives a "get back" indication that tells the Proxy the
   time at which it is going to be on duty again, and willing to
   retrieve the response from B.

   The Proxy is in charge of making the request on behalf of A, using an
   appropriate poll interval for a time span upper bounded by the "get
   back" value, and to buffer the response from B until A wakes up
   again.

   This draft defines a new CoAP elective option, Sleepy, targeted
   specifically at proxies and used to signal a Proxy the will to
   initiate an asynchronous request/response exchange.  The Sleepy
   option is partitioned in three subfields indicating: the remaining
   time before sleep, the expected sleep interval, and (optionally) the
   on-duty interval.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].  Additional
   privileged words are described below.

   Sleepy Device: a sensor/actuator (usually battery operated) that
   switches off its radio beyond the normal radio duty cycle in order to
   save energy.

   Store-and-Forward Proxy: a CoAP proxy that is able to act as an
   intermediate agent where CoAP PDUs are received, kept, and sent at a
   later time to the final destination or to another intermediate
   station.  Its use may be especially helpful in networks with
   intermittent connectivity, such those hosting a significant amount of
   sleepy devices.




Fossati, et al.         Expires September 1, 2012               [Page 3]


Internet-Draft           Sleepy Option for CoAP            February 2012


2.  Motivation

   This memo focuses on the requirement REQ3 of
   [I-D.shelby-core-coap-req]:

   REQ3:   The ability to deal with sleeping nodes.  Devices may be
           powered off at any point in time but periodically "wake up"
           for brief periods of time.


3.  Basic Message Flows

   In the most general scenario both A and B are sleepy endpoints
   showing empty intersection as to their wake intervals, while the
   Proxy cache is empty.

3.1.  Basic Message Flow with CON Semantics

   A typical flow of communication involving the Sleepy option using CON
   messaging is shown in Figure 1.































Fossati, et al.         Expires September 1, 2012               [Page 4]


Internet-Draft           Sleepy Option for CoAP            February 2012


       A                        P                         B
       .                        |                         .
       .    CON (0x7a10)        |                         .
   (1) +----------------------->|                         .
       |    Method              |                         .
       |    Proxy-Uri: B/res    |                         .
       |    Sleepy: {2,58,0}    |                         .
       |                        |                         .
       |    ACK (0x7a10)        |                         .
   (2) |<-----------------------+                         .
       .                        |   Method                .
   (3) .                        +------------------X      .
       .                        |   Uri-Path: /res        .
       .                        |                         .
       .                        |   Method                .
   (4) .                        +------------------X      .
       .                        |   Uri-Path: /res        .
       .                        |                         .
       .                        |   Method                |
   (5) .                        +------------------------>|
       .                        |   Uri-Path: /res        |
       .                        |                         |
       .                        |   Response Code         |
   (6) .                        |<------------------------+
       .                        |   [Content]             |
       .                        |                         .
       .                        |                         .
       .    CON (0xfa10)        |                         .
   (7) |<-----------------------+                         .
       |    Response Code       |                         .
       |    [Content]           |                         .
       |                        |                         .
       |    ACK (0xfa10)        |                         .
   (8) +----------------------->+                         .
       .                        |                         .

                                 Figure 1

   In message (1) a sleepy node, A, asks the Proxy to act upon the
   resource identified by the Proxy-Uri Option in a possibly
   asynchronous way by supplying the Sleepy Option indicating a time at
   which A thinks it may be ready (i.e. awake) to retrieve the response
   message.  The Sleepy Option in the message (1) tells the Proxy that A
   will go off-duty in 2 milliseconds, and it will be off-duty for 58
   milliseconds, but it does not provide any information about the
   optional on-duty interval.

   In case the Proxy understands the Sleepy Option, it replies (2) with



Fossati, et al.         Expires September 1, 2012               [Page 5]


Internet-Draft           Sleepy Option for CoAP            February 2012


   a separate ACK.

   From now on A can get back to sleep while the Proxy sends
   periodically the request to the target node, B -- messages (3-5) --
   and eventually gets a response back (6).

   The stored response is kept by the Proxy until A is on duty again.
   (The seeming on-duty time is computed using the quantities previously
   supplied by A through the Sleepy Option.)  The Proxy sends the
   separate response back, operating with the usual rules of CON
   retransmission, until an ACK from A is received, or the transmission
   retries are exhausted.

   Please note that, generally speaking, the framework is completely
   agnostic as to the transported message type and method.  Further, the
   Proxy may rearrange any implied block-wise transfer
   [I-D.ietf-core-block] or separate acknowledgment in an optimal way.

   [[OPEN ISSUE 1: What if message (2) is lost ?]]

3.2.  Basic Message Flow with NON Semantics

   In case the sleepy sensor uses NON semantics, the resulting exchange
   is the basically the same as the one depicted in Figure 1 with
   messages (2) and (8) removed.


4.  Optimized Message Flow

   The Proxy/Cache, in charge of making the request on behalf of A, MUST
   try to immediately satisfy a request by searching the Cache.

   Figure 2 shows a request from A which can be satisfied from the cache
   (i.e. cache hit) without interrogating B.

















Fossati, et al.         Expires September 1, 2012               [Page 6]


Internet-Draft           Sleepy Option for CoAP            February 2012


       A                        P                         B
       .                        |                         .
       .                        |                         .
       .    CON (0x7a10)        |                         .
   (1) +----------------------->|                         .
       |    Method              |                         .
       |    Proxy-Uri: B/res    |                         .
       |    Sleepy: {2,58,0}    |                         .
       |                        |                         .
       |                   [cache hit]                    .
       |                        |                         .
       |    ACK (0x7a10)        |                         .
   (7) |<-----------------------+                         .
       .    Response Code       |                         .
       .    [Content]           |                         .
       .                        |                         .
       .                        |                         .

                                 Figure 2

   In case a request from A can not be satisfied from the Cache (i.e.
   cache miss), the Proxy, in charge of making the request on behalf of
   A, sends periodically the request to the target node and eventually
   gets a response back.

   Figure 3 shows a cache miss scenario where the Proxy, knowing that
   the target node is awake, forwards the request to B (5) and sends the
   response to A (7) within the "time left before sleeping" indication
   supplied by A with the request (1).  The latter exchange SHALL
   concurrently arm a timeout for sending the ACK message to A before it
   goes to sleep (in case CON is in use).




















Fossati, et al.         Expires September 1, 2012               [Page 7]


Internet-Draft           Sleepy Option for CoAP            February 2012


       A                        P                         B
       .                        |                         .
       .                        |                         .
       .    CON (0x7a10)        |                         .
   (1) +----------------------->|                         .
       |    Method              |                         .
       |    Proxy-Uri: B/res    |                         .
       |    Sleepy: {5,58,5}    |                         .
       |                        |                         .
       |                   [cache miss]                   .
       |                        |                         |
   (5) |                        +------------------------>|
       |                        |   Uri-Path: /res        |
       |                        |                         |
       |                        |   Response Code         |
   (6) |                        |<------------------------+
       |                        |   [Content]             |
       |    ACK (0x7a10)        |                         .
   (7) |<-----------------------+                         .
       .    Response Code       |                         .
       .    [Content]           |                         .
       .                        |                         .
       .                        |                         .

                                 Figure 3

   In any case, if the Proxy has previously received an indication from
   the same target about its on/off-duty behavior via the Sleepy Option
   (Section 5), or by any other means (e.g.  Section 7), it MUST use it
   to devise the most efficient poll strategy, thus avoiding unnecessary
   messaging which would just aggravate the constrained network
   congestion.


5.  Sleepy Option

   +-----+----------+---------+--------+--------+---------+
   | No. | C/E      | Name    | Format | Length | Default |
   +-----+----------+---------+--------+--------+---------+
   |  XX | Elective | Sleepy  | uint   | 8-12 B | (none)  |
   +-----+----------+---------+--------+--------+---------+

   The Sleepy Option in a request is used to signal a Proxy the will to
   initiate an asynchronous request/response exchange.

   The Sleepy option is elective.  If the Proxy does not recognize it,
   it will try to serve a fresh representation of the requested
   resource, or forward the request to the intended origin; depending on



Fossati, et al.         Expires September 1, 2012               [Page 8]


Internet-Draft           Sleepy Option for CoAP            February 2012


   the availability of the endpoints at the time the Proxy tries to
   contact them, the usual proxied transaction may succeed, partially
   fail, or completely fail.

   The Sleepy Option MAY be discretionarily piggybacked by a sleepy node
   on response messages to inform the network about the sleepy pattern
   in use at the endpoint.  This knowledge MAY be used by sleepy-
   friendly Proxies to reduce the overall network congestion that is
   implied by resorting to blind polling in order to maximize the chance
   to get a response from the target.

   The value of the Sleepy option is partitioned in three subfields
   indicating: the remaining time before sleep, the expected sleep
   interval, and (optionally) the on-duty interval.

   Two formats are available, a long format (Figure 4), and a short one
   (Figure 5) which are easily distinguished from the Length field of
   the encoded option: 8 and 12 respectively.

                         +-------+-------+-------+
                         | LEFT  | SLEEP | WAKE  |
                         +-------+-------+-------+

                                 Figure 4


                             +-------+-------+
                             | LEFT  | SLEEP |
                             +-------+-------+

                                 Figure 5

      LEFT: 32-bit uint encoding the number of milliseconds that the
      sending node is left before going off-duty.  The maximum value is
      0xFFFFFFFF, which allows for 71582 minutes.

      SLEEP: 32-bit uint encoding the number of milliseconds that the
      sending node is off-duty.  The maximum value allows for 71582
      minutes (i.e. approx. 50 days).

      WAKE: optional 32-bit uint encoding the number of milliseconds
      that the sending node is on-duty.

   [[OPEN ISSUE 2: shrink to 24-bit uint LEFT and WAKE (i.e. max ~4
   hours) ?]]

   [[OPEN ISSUE 3: change milli to seconds ?]]




Fossati, et al.         Expires September 1, 2012               [Page 9]


Internet-Draft           Sleepy Option for CoAP            February 2012


6.  Limiting Network Congestion

   The retransmit function at the Proxy is conflicting with the overall
   requirement of congestion avoidance on the constrained network.

   Therefore the proxy SHOULD try to learn as much as possible about the
   on/off-duty behavior of the nodes that it is trying to reach, and
   keep the gained knowledge to inform future message exchanges with
   these endpoints.

   Missing an explicit signaling at the network/transport layer,
   endpoints that have a predictable sleep/awake pattern SHOULD try to
   inform the other entities in the network by piggybacking, whenever
   possible, the Sleepy Option in the messages (both requests and
   responses) they are exchanging with other peers.

   A further possibility is to distribute the information regarding the
   sleep/awake pattern by extending the resource attributes available
   through the Resource Directory with a link-format
   [I-D.ietf-core-link-format] version of the Sleepy option (see
   Section 7).


7.  New Link-Format Attributes

   This specification defines the following new attributes for use in
   the CoRE Link Format:

   link-extension = ( "sleep" "=" 1*DIGIT )
   link-extension = ( "wake" "=" 1*DIGIT )
   link-extension = ( "start" "=" 1*DIGIT ) ; in seconds since Epoch

   The sleep and wake attributes have the same semantics and format as
   the SLEEP and WAKE subfields of the Sleepy Option respectively
   (Section 5).  The start attribute sets the base time from which the
   offsets indicated by sleep and wake must be computed.


8.  Acknowledgements

   [TBD]


9.  IANA Considerations

   The following entries are added to the CoAP Option Numbers registry:





Fossati, et al.         Expires September 1, 2012              [Page 10]


Internet-Draft           Sleepy Option for CoAP            February 2012


   .------------------------------.
   | Number | Name    | Reference |
   :--------:---------:-----------:
   |  2k    | Sleepy  | RFC XXXX  |
   `------------------------------'

   The "start", "wake" and "sleep" attributes need to be registered when
   a future Web Linking attribute is created.


10.  Security Considerations

   The same considerations as those highlighted in Section 10.3.2 and
   10.3.3 of [I-D.ietf-core-coap] apply, and are somewhat amplified by
   the possible congestion induced by the tentative setup of
   communication with the target node (messages 3-5 in Figure 1).  The
   Proxy SHOULD try to send as little messages as possibile in order to
   contact the requested endpoint and MUST make use of the wake/sleep
   indication in case they have been previously made available by the
   target node through the Sleepy Option.


11.  References

11.1.  Normative References

   [I-D.ietf-core-block]
              Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
              draft-ietf-core-block-08 (work in progress),
              February 2012.

   [I-D.ietf-core-coap]
              Frank, B., Bormann, C., Hartke, K., and Z. Shelby,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-08 (work in progress), October 2011.

   [I-D.ietf-core-link-format]
              Shelby, Z., "CoRE Link Format",
              draft-ietf-core-link-format-11 (work in progress),
              January 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [I-D.shelby-core-coap-req]
              Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R.



Fossati, et al.         Expires September 1, 2012              [Page 11]


Internet-Draft           Sleepy Option for CoAP            February 2012


              Kelsey, "CoAP Requirements and Features",
              draft-shelby-core-coap-req-02 (work in progress),
              October 2010.


Authors' Addresses

   Thomas Fossati
   KoanLogic
   Via di Sabbiuno, 11/5
   Bologna  40100
   Italy

   Email: tho@koanlogic.com


   Pierpaolo Giacomin
   Freelance

   Email: yrz@anche.no


   Salvatore Loreto
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: salvatore.loreto@ericsson.com


   Mirko Rossini
   CS Dept. University of Bologna

   Email: mirko.rossini@ymail.com
















Fossati, et al.         Expires September 1, 2012              [Page 12]