[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
CoRE Working Group                                          E. Dijk, Ed.
Internet-Draft                                          Philips Research
Intended status: Informational                             June 10, 2013
Expires: December 12, 2013


                Sleepy Devices using CoAP - Requirements
                     draft-dijk-core-sleepy-reqs-00

Abstract

   This document provides requirements for operation of sleepy CoAP
   devices, based on home control and building control use cases.  These
   requirements can be used to help design, or select, a solution for
   sleepy CoAP devices in the CoRE WG.  In addition, for the existing
   CoAP, core-block and core-observe functions some notes are made on
   how these functions could be used in an overall CoRE sleepy devices
   solution that meets the requirements.

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 December 12, 2013.

Copyright Notice

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

   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



Dijk                    Expires December 12, 2013               [Page 1]


Internet-Draft       CoAP Sleepy Device Requirements           June 2013


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   2
     1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Requirements Categories and Use Cases . . . . . . . . . . . .   4
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  R1 - SEP Reports To NSEP  . . . . . . . . . . . . . . . .   7
     4.2.  R2 - SEP Reads From NSEP  . . . . . . . . . . . . . . . .   8
     4.3.  R3 - NSEP Reads From SEP  . . . . . . . . . . . . . . . .   9
     4.4.  R4 - NSEP Writes To SEP . . . . . . . . . . . . . . . . .   9
     4.5.  R5 - Large transfer From NSEP To SEP  . . . . . . . . . .  10
     4.6.  R6 - Security . . . . . . . . . . . . . . . . . . . . . .  10
     4.7.  R7 - Configuration, commissioning, diagnostics,
           maintenance . . . . . . . . . . . . . . . . . . . . . . .  11
     4.8.  R8 - General  . . . . . . . . . . . . . . . . . . . . . .  11
     4.9.  R9 - Non-functional requirements  . . . . . . . . . . . .  12
   5.  CoRE Building Blocks in a Sleepy Devices Solution . . . . . .  12
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Terminology

   For terminology regarding constrained nodes we use
   [I-D.ietf-lwig-terminology].  This document focuses on S0 class
   devices ("always-off").

1.1.  Abbreviations

      CoRE: Constrained RESTful Environments

      SEP: Sleepy Endpoint

      NSEP: Non-Sleepy Endpoint

1.2.  Definitions





Dijk                    Expires December 12, 2013               [Page 2]


Internet-Draft       CoAP Sleepy Device Requirements           June 2013


   Sleepy Endpoint (SEP)  : A CoAP endpoint hosted on a networked
      computing device, which sets its network link to a disconnected
      state during long periods of time to save energy.  "Long" means
      here that the period is of such duration that most messages sent
      to a SEP are lost despite use of standard "reliable transmission"
      techniques.  The device is S0 class and any of E0/E1/E2 class
      according to [I-D.ietf-lwig-terminology].  See also the similar
      definition of SEP in [I-D.rahman-core-sleepy-problem-statement].

   Non-Sleepy Endpoint (NSEP)  : A CoAP endpoint hosted on a networked
      computing device, which has its network interface in an always-
      connected state or operates its network interface such that the
      endpoint(s) on it appear always-connected.  The device is S1 or S2
      class and any of E1/E2/E3 class as in [I-D.ietf-lwig-terminology].

   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.

   Awake/Not Sleeping  : A SEP being in an "awake state" i.e. its
      network interface is connected and the SEP is able to send or
      receive messages.

   Destination  : a NSEP to which event messages are sent by a SEP, or
      by a Proxy on behalf of a SEP.

   Heartbeat  : a type of message (event), which is sent periodically to
      indicate to a Destination that the sender is still operational and
      able to communicate to the Destination.  A heartbeat message may
      contain data about the current status of the sender.  Typically
      sent by a SEP.

   Proxy  : a NSEP which is communicating directly with a SEP; able to
      cache information/CoAP resources on behalf of SEP for the purpose
      of further distribution or making it accessible to interested
      endpoints.  It acts as an intermediary between a SEP and a NSEP.
      The Proxy provides immediate/reliable connectivity, to enable
      NSEPs to operate on SEP resources even while the SEP is sleeping.

   In addition to these definitions, readers should also be familiar
   with the terms and concepts discussed in [I-D.ietf-core-coap].

1.3.  Requirements Language








Dijk                    Expires December 12, 2013               [Page 3]


Internet-Draft       CoAP Sleepy Device Requirements           June 2013


   Capitalized equirements language is used in this document to indicate
   the importance of requirements.  "MUST" level requirements are those
   required to be addressed by a solution.  "SHOULD" level requirements
   are about functionality that is preferably provided by a solution.
   "MAY" level requirements describe optional functionality.

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

2.  Introduction

   The CoRE WG charter includes the topic of caching resources on behalf
   of sleepy devices.  Already, various proposals have been made in the
   CoRE WG with solutions to enable operation of sleepy CoAP endpoints.

   During and shortly after IETF 83 (March 2012) it was proposed to
   first clarify the scope and the requirements that a solution should
   fulfil, before choosing for or developing a solution to support
   sleepy device operation in CoRE using CoAP.

   This document aims to provide input to the mentioned requirement
   gathering and selection process.  The application area that we focus
   on is Home Control and Building Control.  The reader is assumed to be
   familiar with the Sleepy Devices in CoAP Problem Statement
   [I-D.rahman-core-sleepy-problem-statement].  Possibly, the content of
   this document can be input to the Problem Statement I-D.

   First, the requirements categories and related use cases are listed
   in Section 3.  From the use cases a set of requirements was
   extracted, which is detailed in Section 4.  Finally, Section 5
   provides some ideas how current protocols being defined in the CoRE
   WG ([I-D.ietf-core-coap], [I-D.ietf-core-block],
   [I-D.ietf-core-observe]) can be applied to a sleepy CoAP devices
   solution that meets the requirements.

3.  Requirements Categories and Use Cases

   From use cases, a number of requirements can be extracted for SEPs
   and for constrained RESTful systems that contain SEP devices.
   Section 4 will list the main requirements that we extracted.

   This section lists a number of use cases in Home Control and Building
   Control, in which SEP functionality would be desired.  The main
   driver for SEP functionality in CoAP is to achieve fully wireless,
   battery-operated or energy-harvesting CoAP devices that require
   minimal manual maintenance, e.g. having a long battery lifetime.



Dijk                    Expires December 12, 2013               [Page 4]


Internet-Draft       CoAP Sleepy Device Requirements           June 2013


   Note that CoRE application domains like Industrial Sensing, Smart
   Energy or Smart City are not covered by these use cases.  However, it
   is likely that requirements from these domains overlap to a large
   extent with those presented here.

   The requirements are organized in the categories (Rx) shown below.
   Per category, some use case examples are provided.

      R1.  Report SEP->NSEP: SEP reports new information (e.g. events)
      to a non-SEP, or to a multicast group of non-SEPs.

      *  A solar-powered daylight sensor periodically measures daylight
         intensity in a room and reports this information to a
         designated NSEP or group of endpoints.  For example, a local
         luminaire that adapts its dim level according to daylight
         level.

      *  An energy-harvesting light switch is pressed, switches on the
         radio and sends a request to a light or group of lights (NSEPs)
         to turn on.

      *  A battery-powered occupancy sensor detects an event of people
         present, switches on the radio and sends a request to one or a
         group of CoAP-enabled lights to turn on.

      *  Alternative to above: instead of sending directly to the
         light(s) the sensor sends to an intermediate CoAP node (e.g.
         Proxy or controller) which then carries out the request to
         endpoint/group(s) of endpoints.

      *  A battery-powered temperature sensor reports room temperature
         to a designated NSEP that controls HVAC devices.  The sensor
         reports periodically and reports extra when the temperature
         deviates from a predefined range.

      *  A battery-powered sensor sends an event "battery low" to a
         designated reporting location (NSEP).

      R2.  Read SEP->NSEP: SEP reads (or queries) information from a
      non-SEP

      *  A sleepy sensor (periodically) updates internal data tables by
         fetching it from a predetermined remote NSEP, e.g. a backend
         server.







Dijk                    Expires December 12, 2013               [Page 5]


Internet-Draft       CoAP Sleepy Device Requirements           June 2013


      *  A sleepy sensor (periodically) checks for new firmware with a
         remote (CoAP) endpoint.  If new firmware is found, the sensor
         switches to a non-sleepy operation mode, starts an update
         procedure and new firmware is downloaded in the device.

      R3.  Read NSEP->SEP: Non-SEP reads (or queries) information from a
      SEP, or from a multicast group of SEPs.

      *  A NSEP (e.g. in the backend) requests the status of a deployed
         sleepy sensor, e.g. current sensor state and/or firmware
         version and/or battery status and/or its error log.  It expects
         a response within one, or at most a few, second(s).

      *  A NSEP (e.g. in the backend) requests the status of a group of
         deployed sleepy sensors.  It expects responses even for the
         sensors that are sleeping at the time of doing the request.

      *  A NSEP requests information on when a sleepy sensor was 'last
         active' (i.e. identified as being awake) in the network.

      *  A NSEP subscribes itself to sensor events and status reports of
         multiple sleepy sensors for diagnostic purposes.  The
         subscription relation is only temporary, until the diagnostic
         operation concludes.

      R4.  Write NSEP->SEP: Non-SEP writes (or configures, updates,
      deletes, etc.) information to a SEP

      *  An authorized NSEP changes the reporting frequency of a
         deployed sleepy sensor.

      *  An authorized NSEP adds a new reporting endpoint to an
         operational sleepy sensor.  From that moment on, the new
         endpoint (NSEP) receives also the sensor events and status
         updates from the sleepy sensor.

      *  A remote NSEP instructs a sleepy sensor to upgrade its
         firmware.  The sensor firmware is then upgraded.  (In whatever
         way - the SEP may pull data from a server, or the remote NSEP
         may push data to the SEP.)

      R5.  Transfer NSEP->SEP: Large data volume e.g. firmware is
      transferred into a SEP.  The data originates from a non-SEP.
      Either NSEP or SEP takes initiative to start the transfer.







Dijk                    Expires December 12, 2013               [Page 6]


Internet-Draft       CoAP Sleepy Device Requirements           June 2013


      *  A remote NSEP instructs a sleepy sensor to upgrade its
         firmware.  The sensor firmware is then upgraded.  (In whatever
         way - the SEP may pull data from a server, or the remote NSEP
         may push data to the SEP.)

      *  A sleepy sensor (SEP) on own initiative switches to a non-
         sleepy operation mode, starts an update procedure and new
         firmware is downloaded in the device.

      R6.  Security

      R7.  Configuration, commissioning, diagnostics & maintenance

      *  An installer deploys a new sleepy sensor in a room.  The sensor
         is then configured to control all lights in the room in a
         commissioning phase.  Finally, the sleepy operation is enabled
         in the sensor right after the commissioning phase (i.e. start
         of the operational phase).

      R8.  General

4.  Requirements

4.1.  R1 - SEP Reports To NSEP

   1.   Reporting destination type(s).  A SEP MUST be able to report
        directly to an endpoint or group; and to an intermediate node/
        Proxy that takes care of communicating to the final endpoint/
        group.  Multiple reporting destinations MUST be supported.
        Rationale: direct unicast/multicast reporting is needed for high
        reliability, low latency, and avoiding single-point-of-failure
        situations.

   2.   Reporting destination location.  A reporting destination
        endpoint MUST be able to handle any addressing like: link-local,
        subnet-local (e.g. 6LoWPAN), site-local (typ. corporate LAN/
        Intranet), or global (WAN/Intranet/Internet).

   3.   Reporting latency.  Any report SHOULD be delivered with low
        latency to the final local destination.  Rationale: use cases
        include e.g. person detection applications, actuators react
        within 200 ms.

   4.   Reporting reliability unicast.  SEP MUST be able to reliably
        report events in unicast.  For example, a 99.9% reliability may
        be required in a specific use case.





Dijk                    Expires December 12, 2013               [Page 7]


Internet-Draft       CoAP Sleepy Device Requirements           June 2013


   5.   Reporting reliability multicast.  SEP MUST be able to report
        events in multicast to a group of NSEPs, with similar
        reliability as is achievable by a NSEP doing a multicast.

   6.   Multicast report via Proxy.  It SHOULD be possible to configure
        a Proxy, to which a SEP reports in unicast, such that it resends
        the report in multicast.  Rationale: to allow simplified SEPs
        that do not have multicast ability; or devices that do not know
        a priori how multicast operation needs to be done in target
        networks.

   7.   Reporting group topology.  For a multicast group it MUST be
        possible to place group members across multiple subnets, with
        routers in between.  Rationale: allow for flexibility and
        organic IP network growth.

   8.   SEP reporting configuration.  A CoRE solution MUST leave the
        freedom to configure a SEP with reporting destination
        address(es) in the following ways: standard-defined, pre-
        commissioned, runtime configured, runtime discovered.
        Rationale: leave it to vendors or other SDOs how device
        relations are (pre)configured.

   9.   Configuration of receiver of SEP events.  A CoRE solution SHOULD
        allow a receiver of SEP events to discover group IP address(es)
        it has to listen to, to receive events from a specific SEP.

   10.  Direct SEP subscription.  A mechanism MUST be provided for NSEPs
        to receive events (i.e. resource updates) sent by a SEP directly
        to NSEP, during a given period.  Event delivery MUST still work
        even if a Proxy is not available at the time of the event.
        Subscribing to events MUST work also if the SEP is sleeping at
        the time of subscribing.

   11.  Proxy subscription.  A solution SHOULD be provided for clients
        to receive events sent by a Proxy on behalf of a SEP, during a
        given period.  Rationale: to avoid high load on the SEP due to
        high number of subscribers.

4.2.  R2 - SEP Reads From NSEP

   1.  Read direct.  It SHOULD be possible for a SEP to read from/query
       a selected CoAP and/or HTTP server.

   2.  Sleep mode change.  It is allowed that the SEP temporarily
       switches to an always-on mode to perform a Read task.





Dijk                    Expires December 12, 2013               [Page 8]


Internet-Draft       CoAP Sleepy Device Requirements           June 2013


4.3.  R3 - NSEP Reads From SEP

   1.  Read via Proxy.  It MUST be possible for a NSEP to read/query
       designated SEP information via a Proxy.  Rationale: the SEP is
       unavailable most of the time, making direct contact practically
       impossible.

   2.  Multicast read via proxies.  It SHOULD be possible for a NSEP to
       perform a CoAP multicast request to read/query a group of SEPs,
       or a group of proxies.

   3.  Reading reported information.  A client MUST be able to read the
       information (CoAP resources) that a SEP is currently reporting
       (e.g. periodically or event-based).

   4.  Reading non-reported information.  A client MUST be able to read
       information (CoAP resources) that a SEP is currently not
       reporting.

       *  Note: this may require that the Proxy has a specific relation
          to the SEP that enables it to detect when the SEP is awake,
          and at that moment forward the information request to the SEP
          for processing.

       *  Note: some information (manufacturer name) may be sent a
          priori by the SEP to a Proxy, while other information (error
          log) may be sent on demand only.

   5.  Read latency.  The response time for a read operation SHOULD NOT
       differ significantly from a typical NSEP->NSEP request in the
       same IP network, if the information is available in the Proxy.
       If the Proxy needs to wait for the next SEP's wakeup, the
       response time SHOULD NOT significantly exceed the device's
       current sleep duration.

   6.  Client location.  A requesting client MUST be allowed to be link-
       local to the SEP, or subnet-local (e.g. 6LoWPAN), or site-local
       (typ. corporate LAN/Intranet), or global (WAN/Intranet/Internet).

4.4.  R4 - NSEP Writes To SEP

   1.  Write via Proxy.  It MUST be possible for an authorized NSEP to
       write information to or delete information on a SEP via a Proxy.

   2.  Client location: see R3 client location.

   3.  Write latency.  The writing latency SHOULD be approximately equal
       to the current sleep interval duration of the SEP, or less.



Dijk                    Expires December 12, 2013               [Page 9]


Internet-Draft       CoAP Sleepy Device Requirements           June 2013


       Rationale: while SEP is sleeping, no writing can possibly take
       place.  Best performance is when write operation occurs at the
       next SEP wake-up.

   4.  Write reliability.  The write operation MUST be performed
       reliably.  (For example, a 99% success rate may be required in a
       use case, with notification to the application layer about
       outcome of the write operation.)

4.5.  R5 - Large transfer From NSEP To SEP

   1.  Sleeping mode.  A SEP MAY switch its mode of operation
       temporarily to always-on to execute a data transfer.

   2.  Buffering requirement.  A Proxy MUST NOT be required to buffer an
       entire data object in its memory.  Rationale: a firmware image
       will never fit entirely in a Proxy's available memory.

   3.  Location of data object.  See R3 client location.

   4.  Transfer external trigger.  There MUST be a reliable way for a
       NSEP to trigger a SEP into starting a large data transfer.
       Rationale: to cover situations where the SEP itself is in best
       position to initiate the transfer, e.g. acting as a CoAP/HTTP
       client to fetch data blocks at its own pace.

   5.  Transfer latency.  If a transfer is initiated by a NSEP, It
       SHOULD be possible for the transfer to start at the next time
       instant the SEP wakes up.

4.6.  R6 - Security

   1.  Security level.  It MUST be possible to secure communication with
       a SEP at a level similar to NSEP communication.  (E.g., DTLS.)

   2.  Bootstrap security.  It SHOULD be possible to secure any
       communication with a SEP that is needed to bootstrap a (new) SEP
       into a network.

   3.  Proxy security.  The Proxy MAY be a trusted device.  That is,
       end-to-end CoAP security from SEP to Destination is NOT REQUIRED
       if a Proxy is used in the communication process.

   4.  Write Authentication and Authorization.  When information/
       resources on a SEP are being written or deleted, it MUST be
       possible for a SEP (or its Proxy) to authenticate the writer and
       to check that it is authorized to do so.




Dijk                    Expires December 12, 2013              [Page 10]


Internet-Draft       CoAP Sleepy Device Requirements           June 2013


   5.  Read/subscribe Authentication and Authorization.  When
       information/resources on a SEP are being requested, it SHOULD be
       possible for a SEP (or its Proxy) to authenticate the reader/
       subscriber and to check that it is authorized to read.

4.7.  R7 - Configuration, commissioning, diagnostics, maintenance

   1.  Configurable sleep interval(s).  The sleep interval (i.e.
       heartbeat interval) MUST be fully configurable per sleepy node.
       A wide range of values (seconds, minutes, hours, days) SHOULD be
       supported.  Variable sleep intervals SHOULD be supported.
       Multiple sleep intervals (such as a different interval for each
       sensor resource attached to an endpoint) MUST be supported.

   2.  Discoverability.  There MUST be one or more ways defined for a
       NSEP to establish the existince of a SEP and to find the IP
       address to contact the device (either directly or its Proxy).
       Note: possible ways may be DNS discovery, Resource Directory, IP
       address(es) derived from hardware identifier, pre-commissioned,
       standard-defined, etc.

   3.  Discoverability 2.  There SHOULD be a way to discover all proxies
       in a given network scope (e.g. link-local, subnet-local, site-
       local) and to find out which SEP they are representing.

   4.  Portability.  A SEP SHOULD be able to be relocated to a new
       physical position, while keeping its existing association to an
       IP subnet or PAN, without requiring any reconfiguration of the
       SEP and/or NSEPs/proxies it communicates with.

   5.  A Proxy caching information from a SEP MAY be configured to store
       additional computed information based on past resource values,
       e.g. an average, standard deviation, history graph, etc.

4.8.  R8 - General

   1.  Optional reliability.  It MUST be possible for a SEP to
       optionally use Confirmable (CON) CoAP messaging.

   2.  Cached resources freshness.  Having a different Max-Age
       (freshness duration) per resource MUST be supported.

   3.  Wake-up triggers.  Wake-up based on a timer trigger, wake-up
       based on an (unpredictable) event trigger (e.g. sensor based),
       and a combination of both all MUST be possible.

   4.  Local Proxy.  A SEP MAY rely on the presence of at least one
       "parent/Proxy" device in radio range.



Dijk                    Expires December 12, 2013              [Page 11]


Internet-Draft       CoAP Sleepy Device Requirements           June 2013


   5.  Reception windows.  A SEP SHOULD enable a radio reception
       interval at least once every interval it is awake.

4.9.  R9 - Non-functional requirements

   1.  Implementation complexity.  A solution SHOULD have minimal
       implementation complexity on the SEPs.  Even if this implies
       shifting additional complexity to the clients/proxies.
       Rationale: sleepy sensor devices are expected to be more
       constrained along multiple resource axes (RAM, ROM, MCU, energy).

   2.  Configuration effort sleepy.  A solution SHOULD operate with
       minimal configuration effort of SEPs.

   3.  Configuration effort proxies/clients.  A solution SHOULD operate
       with minimal configuration effort of non-SEPs, keeping in mind
       that both configuration effort and implementation complexity for
       SEPs should be minimized with higher priority.  Rationale: SEPs
       are typically harder to configure once deployed, due to frequent/
       unpredictable sleep periods.

   4.  Network load.  A solution SHOULD introduce minimal extra network
       load (number of messages, message sizes, etc.)

   5.  Battery life.  A CoRE SEP solution SHOULD aim to provide as long
       as possible battery life for SEPs.  Battery life of non-SEPs is
       assumed to be of minor importance.

   6.  Scalability.  Number of devices that can subscribe to events from
       a single SEP SHOULD be as high as possible.

   7.  Adaptability.  SEPs SHOULD be aware, or made aware, of any
       relevant network configuration changes.

   8.  NSEP communication effort.  The "effort" a NSEP has to spend on
       communicating with SEPs SHOULD be minimal.  Note: "effort" here
       includes complexity, need for protocols in addition to core-coap,
       number of transactions/messages needed, waiting time, etc.

5.  CoRE Building Blocks in a Sleepy Devices Solution

   In the CoRE WG there are various functions, or "building blocks",
   being developed that could be applied in a CoRE sleepy devices
   solution.

   o  [I-D.ietf-core-coap] CoAP proxy: can possibly be re-used to
      implement the role of Proxy as defined in this document.  However,
      this could require adding some special functions/measures to deal



Dijk                    Expires December 12, 2013              [Page 12]


Internet-Draft       CoAP Sleepy Device Requirements           June 2013


      with SEPs.  Currently a CoAP proxy will have the problem that it
      may not reach the SEP for prolonged periods of time, e.g. to
      forward a CoAP request or a CoAP+observe request to the SEP.

   o  [I-D.ietf-core-observe]: the core-observe paradigm and
      subscription + notification syntax can possibly be re-used to meet
      the subscription/notification requirements.  A problem to solve is
      that a CoAP client is unable to perform an observe request to a
      SEP, since it is likely to be sleeping at the time the request is
      made.  In worst case, the SEP can never be reached by the client.

   o  [I-D.ietf-core-block]: can be used for implementing the
      requirements R5 (Large transfers, Section 4.5).  However, a
      blockwise POST or PUT initiated by a NSEP can not be immediately
      used, again due to the reason that the SEP is likely to be asleep
      at the time(s) the NSEP sends its request.

6.  Acknowledgements

   Thanks to Peter van der Stok and Sye Loong Keoh for reviewing the
   text.

7.  IANA Considerations

   This document includes no request to IANA.

8.  Security Considerations

   This document contains requirements for solutions, including security
   requirements (Section 4.6).  Refer to [I-D.ietf-core-coap]
   Section 11.2 for security considerations on (caching) proxies.  This
   is very relevant as the requirements indicate that use of a caching
   proxy may be necessary.

9.  References

9.1.  Normative References

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., and C. Bormann, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-17
              (work in progress), May 2013.

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

9.2.  Informative References




Dijk                    Expires December 12, 2013              [Page 13]


Internet-Draft       CoAP Sleepy Device Requirements           June 2013


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

   [I-D.ietf-core-observe]
              Hartke, K., "Observing Resources in CoAP", draft-ietf-
              core-observe-08 (work in progress), February 2013.

   [I-D.ietf-lwig-terminology]
              Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained Node Networks", draft-ietf-lwig-terminology-04
              (work in progress), April 2013.

   [I-D.rahman-core-sleepy-problem-statement]
              Rahman, A., Fossati, T., Loreto, S., and M. Vial, "Sleepy
              Devices in CoAP - Problem Statement", draft-rahman-core-
              sleepy-problem-statement-01 (work in progress), October
              2012.

Author's Address

   Esko Dijk (editor)
   Philips Research
   High Tech Campus 34
   Eindhoven  5656 AE
   NL

   Phone: +31 40 2747947
   Email: esko.dijk@philips.com






















Dijk                    Expires December 12, 2013              [Page 14]