One document matched: draft-dijk-core-sleepy-solutions-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6690 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6690.xml">
<!ENTITY I-D.dijk-core-sleepy-reqs SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.dijk-core-sleepy-reqs.xml">
<!ENTITY I-D.rahman-core-sleepy-problem-statement SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rahman-core-sleepy-problem-statement.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml">
<!ENTITY I-D.ietf-core-block SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-block.xml">
<!ENTITY I-D.ietf-core-observe SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-observe.xml">
<!ENTITY I-D.vial-core-mirror-server SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vial-core-mirror-server">
<!ENTITY I-D.ietf-core-resource-directory SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-resource-directory">
<!ENTITY I-D.ietf-lwig-terminology SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lwig-terminology.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-dijk-core-sleepy-solutions-02" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="CoAP Sleepy Devices - Solutions">Sleepy Devices using CoAP - Possible Solutions</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Esko Dijk" initials="E.O." role="editor"
surname="Dijk">
<organization>Philips Research</organization>
<address>
<postal>
<street>High Tech Campus 34</street>
<!-- Reorder these if your country does things differently -->
<code>5656 AE</code>
<city>Eindhoven</city>
<region></region>
<country>NL</country>
</postal>
<phone>+31 40 2747947</phone>
<email>esko.dijk@philips.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2013" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Applications</area>
<workgroup>CoRE Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>CoRE</keyword>
<keyword>CoAP</keyword>
<keyword>sleepy</keyword>
<keyword>architecture</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document describes possible solutions for sleepy devices support for the CoAP protocol.
The solutions aim to meet the requirements for CoAP sleepy devices in home and building control use cases. The
purpose of this document is to guide and stimulate the discussion on sleepy devices support for CoAP in the CoRE WG.
</t>
</abstract>
</front>
<middle>
<section title="Terminology">
<section title="Abbreviations">
<t>
<list>
<t>CoRE: Constrained RESTful Environments</t>
<t>SEP: Sleepy Endpoint</t>
<t>NSEP: Non-Sleepy Endpoint</t>
</list>
</t>
</section>
<section title="Definitions">
<t>
<list style="hanging">
<t hangText="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 <xref target="I-D.ietf-lwig-terminology"/>.
See also the similar definition of SEP in <xref target="I-D.rahman-core-sleepy-problem-statement"/>.</t>
<t hangText="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 <xref target="I-D.ietf-lwig-terminology"/>.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="Destination">: a NSEP to which event messages are sent by a SEP, or by a Proxy on behalf of a SEP.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list>
</t><t>
In addition to these definitions, readers should also be familiar with
the terms and concepts discussed in <xref target="I-D.ietf-core-coap"/>.
</t>
</section>
<section title="Requirements Language">
<t>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 in <xref
target="RFC2119">RFC 2119</xref>.
</t>
</section>
</section>
<section anchor="Introduction" title="Introduction">
<t>
The CoRE WG charter includes the topic of caching resources on behalf of sleepy devices.
This document describes an overall architecture proposal on how support
for sleepy CoAP devices can be added to Constrained RESTful systems, to support caching
but also other functions. Possible solutions for the various identified functions are
proposed. The motivation for
sleepy CoAP devices is described in <xref target="I-D.rahman-core-sleepy-problem-statement"/>
and <xref target="I-D.dijk-core-sleepy-reqs"/>.
</t>
<t>
The aim of this document is to guide and stimulate the discussion on sleepy devices support in
the CoRE WG. The use cases and requirements
documented in <xref target="I-D.dijk-core-sleepy-reqs"/> are taken as the reference.
</t>
</section>
<section anchor="Architecture" title="Architecture">
<t>Based on the use cases, requirements and existing CoRE building blocks (such as the
CoAP protocol, CoAP proxying, core-observe, etc.) a solution architecture is described
in this section. First we identify the components, then the
interfaces between components, and finally possible solutions to
realize these interfaces.
</t>
<section anchor="ArchitectureComponents" title="Components">
<t>
From the use cases and requirements the following components (i.e. devices, or functions of devices)
can be identified:
<list style="numbers">
<t>Sleepy Endpoint (SEP)</t>
<t>Proxy: NSEP that maintains a relation with SEP and caches resources on behalf of the SEP.</t>
<t>Destinations(s): NSEPs, other than Proxy, where SEP directly reports events to. Events are typically a change of resource.
A destination endpoint may consist of a multicast group.</t>
<t>External server: a CoAP server to which a SEP can make requests e.g. for parameter updates, firmware or external information.</t>
<t>Configuring NSEP: a CoAP endpoint that changes/writes data on the SEP</t>
<t>Reading NSEP: a NSEP that needs to read a resource from the SEP. This may include resources that the SEP regularly
reports as events already, or resources that a SEP did not send before.</t>
<t>Discovery Service: an optional service that enables discovery of SEPs, their resources and their associated Proxies.
For example, a Resource Directory (<xref target="I-D.ietf-core-resource-directory"/>). </t>
</list>
</t>
</section>
<section anchor="ArchitectureInterfaces" title="Interfaces">
<t>
Below diagram shows the components and the interfaces (Ixx) that need to be defined between components to meet the
various requirements for CoAP sleepy devices.
The arrowheads indicate the direction of taking initiative; e.g. the arrow from SEP to Destination NSEP(s)
shows that the SEP upon an event takes the initiative to send to one or more Destination(s). This "taking initiative" could
be implemented either via a CoAP request or a CoAP response (e.g. a core-observe response) so an arrow does not
indicate which component is acting in the role of CoAP client or CoAP server.
</t>
<figure anchor="ArchitectureDiagram" title="Architecture Components and Interfaces (numbered)" align="center">
<artwork>
<![CDATA[
+-------------+ +--------------+ I2 +---------+
| Destination | I1 | SEP |---------->| Server |
| NSEP(s) |<--------| |\ | NSEP |
+-------------+ +--------------+ \ +---------+
| | ^ \___________
I6 | |I7 |I8 I9 |
v v | v
+-------------+ I3 +--------------+ +-------------+
| Reading |-------->| Proxy | I9 | Disc. Serv. |
| NSEP | | (NSEP) |---------->|(OPTIONAL) |
+-------------+ +--------------+ +-------------+
^ | ^ ^
____________| |I5 |______________ | I10
/ I4 v I10 \ |
+-------------+ +--------------+ +-------------+
| Configuring | | Destination | | Discovering |
| NSEP | | NSEP(s) | NSEP |
+-------------+ +--------------+ +-------------+
]]>
</artwork>
</figure>
</section>
<section anchor="ArchitectureInterfacesImplementation" title="Implementation of Interfaces">
<t>
This section gives possible solutions how each interface (Ixx, identified in the previous section)
could be implemented.
The "Rxx items" (R1, R2, etc.) between brackets show which requirements from
<xref target="I-D.dijk-core-sleepy-reqs"/> are addressed by the interface.
</t>
<section anchor="I1" title="I1: SEP Reporting to Destinations (R1)">
<t>
A SEP can report events to one or more destinations using CoAP POST requests,
acting as a CoAP client. For each request either NON or CON may be used.
The endpoint(s) to report to can be hardcoded in the software and/or determined
by the configuration applied through I4 (<xref target="I4"/>). In addition,
a SEP may be programmed to fetch such configuration from a server through
I2 (<xref target="I2"/>).
To which resource (URI) the POST request is sent, plus the Content-Format
used and the contents of this content, is determined by the implementers and/or
SDOs that define application profiles on top of CoAP.
</t>
</section>
<section anchor="I2" title="I2: SEP Reading from External Server (R2,R5)">
<t>
A SEP can read from an NS server using CoAP (GET) requests, acting as a CoAP client.
While waiting for a response, a SEP is in an awake state.
Similar to I1, the selection of endpoint(s), URI and content is up to implementers and/or SDOs.
</t>
</section>
<section anchor="I3" title="I3: Reading Device Reads SEP Resource(s) Via Proxy (R3)">
<t>
A Reading Device sends CoAP GET requests to the Proxy (acting as a CoAP client) to read SEP resources.
The Proxy serves these requests from cache. If a requested resource is not cached,
various behaviors could be defined: e.g. return an error, or the Proxy returns a 5.03 Service Unavailable first,
and then starts a process to GET the resource directly from the SEP using interface I8.
</t>
</section>
<section anchor="I4" title="I4: Configuring Device Writes SEP Resource(s) Via Proxy (R4,R5,R7)">
<t>
A Configuring Device sends CoAP PUT/DELETE requests to the Proxy in order to write/delete
resources on the SEP. The resources on the Proxy that are written to are the resources that
the SEP has delegated towards the Proxy.
</t>
<t>
The Proxy itself then uses I8 to update the SEP with the new resource(s).
</t>
</section>
<section anchor="I5" title="I5: Proxy Notifies Destination (R1)">
<t>
A Destination can use core-observe to register to resource updates on the Proxy.
The Proxy sends core-observe notifications whenever the resource is updated. The resources
here are the resources that the SEP has delegated to the Proxy.
</t>
</section>
<section anchor="I6" title="I6: SEP Notifies Events to Proxy (R1)">
<t>
The SEP sends CoAP requests (acting as a CoAP client) to the Proxy to communicate
any events i.e. SEP resource updates. The format of request and response should be
partly standardized in CoRE, e.g. as in Mirror Server <xref target="I-D.vial-core-mirror-server"/>].
</t>
</section>
<section anchor="I7" title="I7: SEP Checks Proxy For Resource Updates (R4,R5)">
<t>
The SEP may send a single CoAP GET request to the Proxy to check if any changes
to its writeable delegated resources are available. If so, it could use multiple GET
requests (one per changed resource) to get the new content from the Proxy, or perhaps
a single GET to retrieve multiple resource values as a single composite representation.
</t><t>
Text TBD; some initial thoughts: a single message to post a sensor value (+ heartbeat) and to ask for any updates
is more efficient. The proxy could use its response code to signal if any updates are
available. For example, for a POST, a 2.04 Changed response may indicate a resource is changed.
A code 2.00 (which is to be defined) may indicate success but no change to resource.
Or a small payload attached to the response to the POST could indicate which updates to resources
are available at the Proxy, as was discussed on the CoRE WG list around March 29, 2013.
</t><t>
Alternative: technique that once a Proxy receives a POST from the SEP with a sensor value,
it first sends a CoAP PUT request to change a resource on the SEP, and only when that is
successful it provides a separate response to to the original POST request done by the SEP.
</t>
</section>
<section anchor="I8" title="I8: Proxy Requests Resources from SEP (R3)">
<t>
For I8 to work there needs to be a mechanism defined in I6 or I7, so that the Proxy
can be notified when a SEP is awake. Then,
a Proxy that needs to request resource(s) from a SEP can make the requests via interface I8 as soon as the
SEP has woken up.
</t>
<t>
A solution is that a SEP acts as a regular CoAP server during the time it is awake.
</t>
</section>
<section anchor="I9" title="I9: Proxy Registers Resources at Discovery Service (R7)">
<t>
This interface is OPTIONAL i.e. only required if the Discovery Service is
available. A SEP could communicate its available resources described in CoRE Link Format
<xref target="RFC6690"/> to a Proxy. The Proxy is then responsible for
registering these resources/descriptions in a further Discovery Service which may be
implemented as a Resource Directory <xref target="I-D.ietf-core-resource-directory"/>.
</t>
<t>
A SEP SHOULD describe its own resources in CoRE Link Format in its "/.well-known/core"
resource, such that a Proxy is able to read this resource description and to
do further registration of SEP resources in a Discovery Service.
</t>
</section>
<section anchor="I10" title="I10: CoAP Endpoint Discovers SEP(s) (R7)">
<t>
There are two ways in which a CoAP endpoint can discover a SEP and its resources.
The first way which should be supported in a system, requires that a Proxy includes in its
"/.well-known/core" Link Format description the descriptions of the individual SEPs
as detailed in <xref target="I-D.vial-core-mirror-server"/>. The CoAP endpoint can
then use CoRE resource discovery (<xref target="I-D.ietf-core-coap"/>) using either
unicast or multicast CoAP requests to discover the SEP.
</t><t>
The second way which is OPTIONALLY supported in a system, is that a Proxy registers the
SEP into a Discovery Service (such as RD <xref target="I-D.ietf-core-resource-directory"/>),
and the CoAP endpoint uses the specific
interface of the Discovery Service to discover a SEP.
</t>
</section>
</section>
<section anchor="Resources" title="Resources">
<t>
This section provides some information on the CoAP resources that need to be allocated on
the different components in the architecture.
</t>
<section anchor="SEPResources" title="SEP Resources">
<t>
On a SEP, a clear distinction has to be made between types of resources.
<list style="symbols">
<t>Read-only resources: resource can be modified by the SEP, but SHOULD NOT be modifiable by any external device.
This includes static information resource (e.g. manufacturer name, type, firmware version, etc.)
but also volatile resources (e.g. latest sensor value, error log entries, etc.) that the SEP
internally updates.
</t>
<t>Read/Write resources: resource can be modified by an (authorized) external device.
This is used for configuration
information (e.g. sensor thresholds, which Destination(s) to use, event frequency, etc.).
Authorized CoAP clients can write such resource at the Proxy, which will communicate the
updated resource to the SEP next time it wakes up and contacts the Proxy. To avoid
write/write conflicts, such a resource SHOULD NOT be modified autonomously by a SEP.
</t>
</list>
</t>
</section>
<section anchor="ProxyResources" title="Proxy Resources">
<t>
TBD
</t>
</section>
<section anchor="EventHandlerResources" title="Destination Resources">
<t>
TBD. One draft proposal is: a single reporting resource for receiving events "/event".
This can be changed to anything SDO/vendor specific, but above can be a default.
</t>
</section>
<section anchor="ServerResources" title="Other Resources">
<t>
TBD
</t>
</section>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBD</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This document includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD: per interface the security needs and solution need to be described. Anywhere CoAP unicast is used,
DTLS may apply as a transport security solution. DTLS key update on a sleepy device may pose a problem.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC6690;
&I-D.ietf-core-coap;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&I-D.rahman-core-sleepy-problem-statement;
&I-D.dijk-core-sleepy-reqs;
&I-D.ietf-lwig-terminology;
&I-D.ietf-core-block;
&I-D.ietf-core-observe;
&I-D.ietf-core-resource-directory;
&I-D.vial-core-mirror-server;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 20:36:10 |