One document matched: draft-rahman-core-sleepy-nodes-do-we-need-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!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 RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC6690 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6690.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-resource-directory SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-resource-directory.xml">
<!ENTITY I-D.arkko-core-sleepy-sensors SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.arkko-core-sleepy-sensors.xml">
<!ENTITY I-D.cao-core-aol-req SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cao-core-aol-req.xml">
<!ENTITY I-D.giacomin-core-sleepy-option SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.giacomin-core-sleepy-option.xml">
<!ENTITY I-D.fossati-core-publish-option SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.fossati-core-publish-option.xml">
<!ENTITY I-D.fossati-core-monitor-option SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.fossati-core-monitor-option.xml">
<!ENTITY I-D.castellani-core-alive SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.castellani-core-alive.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.dijk-core-sleepy-solutions SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.dijk-core-sleepy-solutions.xml">
<!ENTITY I-D.rahman-core-sleeping SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rahman-core-sleeping.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.rahman-core-sleepy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rahman-core-sleepy.xml">
<!ENTITY I-D.vial-core-mirror-server SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vial-core-mirror-server.xml">
<!ENTITY I-D.bormann-core-roadmap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bormann-core-roadmap.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-rahman-core-sleepy-nodes-do-we-need-01" 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="Sleepy Devices for CORE">Sleepy Devices: Do we need to Support them in CORE?</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Akbar Rahman" initials="A."
surname="Rahman">
<organization>InterDigital Communications, LLC</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Montreal</city>
<region>Quebec</region>
<code>H3A 3G4</code>
<country>Canada</country>
</postal>
<phone>+1-514-585-0761</phone>
<email>akbar.rahman@interdigital.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="11" month="February" year="2014" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>CORE WG</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. -->
<abstract>
<t>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.</t>
</abstract>
</front>
<!-- ************************** Main Body ************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<middle>
<section title="Terminology and Conventions">
<t>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
<xref target="RFC2119">RFC 2119</xref>.</t>
<t>This document assumes readers are familiar with the terms
and concepts that are used in <xref target="I-D.ietf-core-coap"/>
and <xref target="RFC6690"/>.</t>
</section>
<section anchor="Intro" title="Introduction">
<t>At IETF-87 (Berlin), it was suggested to review/summarize the CORE WG
interest on the topic of Sleepy Node support. Specifically whether
the WG feels that explicit support of sleepy endpoints is required for the CoAP protocol,
CORE Link Format, CORE Resource Directory, etc. Alternatively,
whether the WG feels that Sleepy Node support can be completely
done outside CORE such as in the lower Layer 2 (MAC) scheduling and/or
in Layer 7 (application) logic.
</t>
</section>
<section anchor="Background" title="Background">
<t>The base CoAP specification <xref target="I-D.ietf-core-coap"/> (section 2.3) provides
indirect support of sleepy nodes via the support of caching by intermediaries. This allows
resource representations (previously retrieved) from a sleepy node to be temporarily available
to other clients from a caching proxy even though the node (origin server) is currently asleep.
</t>
</section>
<section anchor="Drafts" title="Drafts Related to Sleepy Nodes">
<t>There have been multiple drafts in the CORE WG directly related to the subject of Sleepy Nodes including:
<list style="symbols">
<t><xref target="I-D.rahman-core-sleepy-problem-statement"/> summarizes the overall problem space of Sleepy Nodes.</t>
<t><xref target="I-D.cao-core-aol-req"/> defines requirements for Sleepy Nodes to behave as if they are "always on".</t>
<t><xref target="I-D.dijk-core-sleepy-reqs"/> defines requirements for Sleepy Nodes based on home and building control use cases.</t>
<t><xref target="I-D.rahman-core-sleeping"/> defines general requirements for Sleepy Nodes.</t>
<t><xref target="I-D.bormann-core-roadmap"/> provides a classification and overview of CORE drafts (and features)
including a section on Sleepy Nodes.</t>
<t><xref target="I-D.arkko-core-sleepy-sensors"/> describes a sensor network implementation and shows how different communication
models affect implementation complexity and energy consumption (including Sleepy Node support).</t>
<t><xref target="I-D.giacomin-core-sleepy-option"/> defines a proxy that acts as a store-and-forward agent for a Sleepy Node.</t>
<t><xref target="I-D.castellani-core-alive"/> defines a new CoAP message type which the Sleepy Node
multicasts to all interested devices when it wakes up.</t>
<t><xref target="I-D.fossati-core-publish-option"/> allows an endpoint to temporarily delegate authority of its
resources (when it is sleeping) to a proxy server that is always on.</t>
<t><xref target="I-D.fossati-core-monitor-option"/> extends the Observe functionality to handle the
scenario when both the server and clients are Sleepy Nodes.</t>
<t><xref target="I-D.dijk-core-sleepy-solutions"/> defines an architectural approach to support Sleepy Nodes.</t>
<t><xref target="I-D.rahman-core-sleepy"/> defines new parameters that describe an endpoint's sleepy characteristics and stores them
in the Resource Directory.</t>
<t><xref target="I-D.vial-core-mirror-server"/> defines a special type of Resource Directory from which
endpoints can fetch the resource regardless of the (sleep) state of the server.</t>
</list>
</t>
</section>
<section anchor="Email" title="WG Email List Poll for Sleepy Node Deliverable">
<t>A pulse was taken on the WG Email list asking for interest in a "CORE Sleepy Node support" deliverable
<xref target="Post-IETF87-Poll"/>, <xref target="Post-IETF88-Poll"/>.</t>
<t>The interesting (but non-normative) results were as follows:
<list style="symbols">
<t>Support FOR a new CORE Sleepy Node support deliverable: 11</t>
<t>Support AGAINST a new CORE Sleepy Node support deliverable: 3</t>
</list>
</t>
</section>
<section anchor="Summary" title="Summary">
<t>There have been over ten drafts related to the concept of CORE support of Sleepy Nodes. The WG Email list
poll on the topic had a large majority of responders supporting creation of a CORE charter item for support of Sleepy Nodes.
However there were some important and high profile dissenters that argued against such a charter item.
Another point to consider is that during WG discussions, the CORE Mirror Server
<xref target="I-D.vial-core-mirror-server"/> is sometimes referred to as the
"existing" solution for CORE Sleepy Node support. However, this draft was never adopted as a WG draft.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Carsten Bormann and Zach Shelby for valuable discussions and feedback on the topic of Sleepy Nodes.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Not applicable. </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;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC6690;
&I-D.ietf-core-coap;
&I-D.ietf-core-resource-directory;
&I-D.arkko-core-sleepy-sensors;
&I-D.cao-core-aol-req;
&I-D.giacomin-core-sleepy-option;
&I-D.castellani-core-alive;
&I-D.fossati-core-publish-option;
&I-D.fossati-core-monitor-option;
&I-D.dijk-core-sleepy-reqs;
&I-D.dijk-core-sleepy-solutions;
&I-D.rahman-core-sleeping;
&I-D.rahman-core-sleepy-problem-statement;
&I-D.rahman-core-sleepy;
&I-D.vial-core-mirror-server;
&I-D.bormann-core-roadmap;
<reference anchor="Post-IETF87-Poll" target="http://www.ietf.org/mail-archive/web/core/current/msg04750.html">
<front>
<title>Do we need a CORE charter item for CoAP support of Sleepy Nodes?</title>
<author initials="A." surname="Rahman" fullname="Akbar Rahman"/>
<date month="August" year="2013" />
</front>
</reference>
<reference anchor="Post-IETF88-Poll" target="http://www.ietf.org/mail-archive/web/core/current/msg05098.html">
<front>
<title>WG interest in Sleepy Node topic</title>
<author initials="A." surname="Rahman" fullname="Akbar Rahman"/>
<date month="November" year="2013" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:10:09 |