One document matched: draft-rahman-core-sleepy-04.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 RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.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-observe SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-observe.xml">
<!ENTITY I-D.ietf-core-resource-directory SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-resource-directory.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="std" docName="draft-rahman-core-sleepy-04" 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="Enhanced Sleepy Node Support">Enhanced Sleepy Node Support for CoAP</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="08" month="October" year="2013" />
<!-- 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>CoAP is a specialized web transfer protocol for constrained devices. These devices
typically have some combination of limited battery power, small memory
footprint and low throughput links. It is expected that in CoAP networks
there will be a certain portion of devices that are "sleepy" and which may
occasionally go into a sleep mode (i.e. go into a low power state to
conserve power) and temporarily suspend CoAP protocol communication.
This document proposes a minimal and efficient mechanism building on the
Resource Directory (RD) functionality to enhance sleepy node support in CoAP
networks. The RD functionality may be incorporated as part of a CoAP Proxy.</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"/>. In addition, this document defines the following terminology:
<list style="hanging">
<t hangText="Sleepy Node"><vspace /> <!--XML2RFC is stupid-->
A sleepy node is a CoAP client or server that may sometimes go
into a sleep mode (i.e. go into a low power state to conserve
power) and temporarily suspend CoAP protocol communication.
A sleepy node will otherwise remain in a fully
powered on state where it has the capability to perform full CoAP
protocol communication.</t>
<t hangText="Non-Sleepy Node"><vspace /> <!--XML2RFC is stupid-->
A non-sleepy node is a CoAP client or server that always remains
in a fully powered on state (i.e. always awake) where it has the
capability to perform full CoAP protocol communication. The general
operation of non-sleepy nodes is assumed to be well known and so
are not explicitly spelled out in this document except where
needed for clarity.</t>
</list>
</t>
</section>
<section anchor="Intro" title="Introduction">
<t>The current CoAP approach provides a minimal support of sleepy nodes as follows:
<list style="symbols">
<t><xref target="I-D.ietf-core-coap"/> defines CoAP proxies which can cache and service
requests for sleepy CoAP servers. A client explicitly sends a CoAP request (GET)
to a forward proxy (identified by its IP address) while indicating the URI (of the
resource of interest) associated to a sleepy CoAP origin server. If the proxy
has a valid representation of the resource in its cache it can then respond directly
to the client regardless of the current sleep state of the origin server.
Otherwise the proxy has to attempt to retrieve (GET) the resource from the sleepy origin
server. The attempt may or may not be successful depending on the sleep state of
the origin server.</t>
<t><xref target="RFC6690"/> and <xref target="I-D.ietf-core-resource-directory"/>
defines a Resource Directory (RD) mechanism where sleepy CoAP servers can
register/update (POST/PUT to "/.well-known/core") their list of resources on a
central (non-sleepy) RD server. This allows clients to discover the list of
resources from the RD (GET /rd-lookup/...) for a sleepy server, regardless
of its current sleep state. Unlike a proxy, the RD stores only the URIs for other nodes,
and not the actual resource representation <xref target="RFC6690"/> . The client
then may attempt to operate on (GET/PUT/POST/DELETE) the desired resource at the sleepy origin server.
This attempt may or may not be successful depending on the sleep state of the origin server.</t>
<t>Lower layer (i.e. below the IP layer) support for sleepy nodes exist in most wireless
technologies (e.g. IEEE 802.11 (WiFi), and IEEE 802.15.4 (ZigBee)). For
example, most wireless technologies support limited functionality such as
packet scheduling to account for sleepy nodes in their physical and MAC
layer protocols. This lower layer functionality is not aware of any
specific timing or operational aspects of application layer protocols like
CoAP.</t>
</list>
</t>
</section>
<section title="Proposal">
<section anchor="RD-Based" title="RD Based Sleep Tracking">
<t>The current CoAP approach to support sleepy nodes can be significantly improved
by introducing RD based mechanisms for a CoAP client to determine whether:
<list style="symbols">
<t>A targeted resource is located on a sleepy server.</t>
<t>A sleepy server is currently in sleep mode or not.</t>
</list>
</t>
<t>We define the following new parameters to characterize a sleepy node:
<list style="symbols">
<t>SleepState - Indicates whether the node is currently
in sleep mode or not (i.e. Sleeping or Awake).</t>
<t>SleepDuration - Indicates the maximum duration of time
that the node stays in sleep mode.</t>
<t>TimeSleeping - Indicates the length of time the node has
been sleeping (i.e. if Sleep State = Sleeping).</t>
<t>NextSleep - Indicates the next time the node will go to
sleep (i.e. if Sleep State = Awake).</t>
</list>
These parameters are all server (node) level and are new parameters
added to the RD URI Template Variables defined in
<xref target="I-D.ietf-core-resource-directory"/>.
</t>
<t> We also define a new lookup-type ("ss") for the RD lookup interface
specified in <xref target="I-D.ietf-core-resource-directory"/>.
This new lookup-type supports looking up the SleepState of a
specified end-point.</t>
<t>
The three time based parameters (SleepDuration, TimeSleeping, NextSleep) can be based
on either an absolute network time (for a time synchronized network) or a
relative local time (measured at the local node).
</t>
<t>Following the approach of <xref target="RFC6690"/>
and <xref target="I-D.ietf-core-resource-directory"/>, sleep
parameters for sleepy servers can be stored by the server in the RD and accessed by
all interested clients. Examples of using these parameters in a synchronous or
asynchronous manner are shown in the following sections.
</t>
</section>
<section anchor="Synch" title="Example of Synchronous RD Based Sleep Tracking">
<t> <xref target="fig-sync-RD"/> shows an example of using RD based sleep
tracking in a synchronous fashion:</t>
<t>(1) SleepyNode-1 is awake and having previously discovered the local RD,
stores its CORE link format in the RD (POST/rd) identified by its
entry point (?ep=SleepyNode-1). The sleep parameters are also updated
as part of this step.</t>
<t>(2)-(3) RD services the POST and stores the CORE link format and starts the sleep
timers for this node.</t>
<t>(4) SleepyNode-1 falls asleep.</t>
<t>(5) A client is interested in temperature sensors in this domain and does
a lookup on the RD.</t>
<t>(6) The RD does a lookup and finds that SleepyNode-1 is the only node meeting the match
and sends back the required info including the Sleep parameters.</t>
<t>(7) From the sleep parameters, the client knows that the node is currently asleep and so
internally schedules to send the GET request when the node wakes up (plus a small
safety hysteresis).</t>
<t>(8)-(9) Client sends GET request for temperature sensors and successfully receives the
content as SleepyNode-1 is awake.</t>
<figure anchor="fig-sync-RD" title="Synchronous Resource Directory Based Sleep Tracking" align="center">
<artwork>
<![CDATA[
SleepyNode-1 Resource
Server Directory Client
| | |
+----------+ | |
| Time = 0 | | |
+----------+ | |
| | |
|(1) CoAP POST | |
| /rd, | |
| ?ep="SleepyNode-1"; | |
| ?SleepDuration="30-Minutes"; | |
| ?SleepState="Awake"; | |
| ?NextSleep="5-Minutes"; | |
| PAYLOAD: | |
| "</sensors...>" | |
|---------------------------------- >| |
| | |
| (2) RD services the | |
| Registration | |
| Request and | |
| starts Sleep | |
| timers | |
| | |
|(3) 2.01 Created | |
| Location: /rd/4321 | |
|<-----------------------------------| |
| | |
+-------------------+ | |
| Time = 5 minutes | | |
+-------------------+ | |
| | |
|(4) SleepyNode-1 falls asleep | |
| | |
+-------------------+ | |
| Time = 15 minutes | | |
+-------------------+ | |
| | |
| |
| (5) CoAP GET |
| /rd-lookup/res?rt=Temperature |
| |<-------------------------|
| | |
| | |
| |
| (6) 2.05 Content |
| <coap://SleepyNode-1/temp>; |
| SleepDuration="30-Minutes"; |
| SleepState="Sleeping"; |
| TimeSleeping="10-Minutes"; |
| PAYLOAD: |
| rt="Temperature" |
| |------------------------->|
| | |
| | |
| | |
| | |
| |
| (7) Since node is asleep Client |
| waits 20 minutes until it awakes |
| | |
| | |
+-------------------+ | |
| Time = 31 minutes | | |
+-------------------+ | |
| | |
| |
| (8)CoAP GET |
| <coap://SleepyNode-1/temp> |
|<--------------------------------------------------------------|
| |
|-------------------------------------------------------------->|
| (9) 2.05 Content |
| | |
| | |
]]>
</artwork>
</figure>
</section>
<section title="Example of Asynchronous RD Based Sleep Tracking">
<t> <xref target="fig-async-RD"/> shows an example of using RD based sleep
tracking in an asynchronous fashion:</t>
<t>(1) SleepyNode-1 is awake and having previously discovered the local RD,
stores its CORE link format in the RD (POST/rd) identified by its
entry point (?ep=SleepyNode-1).</t>
<t>(2)-(3) RD services the POST and stores the CORE link format.</t>
<t>(4) A client is interested in temperature sensors in this domain and does
a lookup on the RD for all sensors that are currently awake.</t>
<t>(5) The RD does a lookup and finds that SleepyNode-1 is the only node
meeting the match and sends back the required info.</t>
<t>(6)-(7) Using the sleep state lookup functionality (lookup-type := "ss"),
the client adds itself to the list of observers to get SleepState updates
from RD for SleepyNode-1 <xref target="I-D.ietf-core-observe"/>.</t>
<t>(8)-(9) Client performs RD 'resource' lookup to find URI of temperature sensor
of resource hosted on SleepyNode-1.</t>
<t>(10)-(13) SleepyNode-1 prepares to goes to sleep and updates the SleepState
in the RD.</t>
<t>(14) RD notifies the client through previously established observe relationship.</t>
<t>(15) Client application wants to get the temperature now but does not send the request
as it knows SleepyNode-1 is currently sleeping.</t>
<t>(16)-(19) SleepyNode-1 wakes up and updates the SleepState in the RD.</t>
<t>(20)-(21) RD notifies the client through previously established observe
relationship.</t>
<t>(22)-(23) Client sends GET request for temperature sensors and successfully
receives the content as SleepyNode-1 is awake.</t>
<figure anchor="fig-async-RD" title="Asynchronous Resource Directory Based Sleep Tracking" align="center">
<artwork>
<![CDATA[
SleepyNode-1 Resource
Server Directory Client
| | |
| | |
|(1) CoAP POST | |
| /rd, | |
| ?ep=SleepyNode-1; | |
| ?SleepState=Awake; | |
| PAYLOAD: | |
| "</sensors...>" | |
|---------------------------------- >| |
| | |
| (2) RD services the | |
| Registration | |
| Request | |
| | |
|(3) 2.01 Created | |
| Location: /rd/4321 | |
|<-----------------------------------| |
| | |
| | |
| (4) Client performs RD |
| end-point lookup to |
| find endpoint that |
| has temperature |
| sensor and is awake |
| |
| CoAP GET |
| /rd-lookup/ep?rt=Temperature&SleepState=Awake|
| |<-------------------------|
| | |
| | |
| (5) 2.05 Content |
| <coap://{ip:port}>;ep="SleepyNode-1" |
| |------------------------->|
| | |
| | |
| (6) Client adds itself |
| to list of observers|
| to get SleepState |
| updates from RD for |
| SleepyNode-1 |
| |
| |
| CoAP GET |
| /rd-lookup/ss?ep=SleepyNode-1 |
| Observe: 0 |
| Token: 0x4a |
| |<-------------------------|
| | |
| | |
| (7) 2.05 Content |
| Observe: 1 |
| Token: 0x4a |
| SleepState="Awake" |
| |------------------------->|
| | |
| | |
| (8) Client performs RD |
| 'resource' lookup |
| to find URI of |
| temperature sensor |
| of resource hosted |
| on SleepyNode-1 |
| |
| CoAP GET |
| /rd-lookup/res?rt=Temperature&ep="SleepyNode-1"|
| |<-------------------------|
| | |
| | |
| (9) 2.05 Content |
| <coap://sleepyNode-1/temp>; |
| |------------------------->|
| | |
| | |
... ....
|(10) SleepyNode-1 prepares to go | |
| to sleep so it updates | |
| SleepState | |
| | |
| CoAP PUT | |
| /rd/4321, | |
| ?SleepState=Sleeping | |
|---------------------------------- >| |
| | |
| (11) RD updates | |
| SleepState of | |
| SleepyNode-1 | |
| | |
|(12) 2.04 Changed | |
|<-----------------------------------| |
| | |
|(13) SleepyNode-1 goes to sleep | |
| | |
| | |
| (14) RD sends notification to client |
| 2.05 Content |
| Observe: 2 |
| Token: 0x4a |
| SleepState="Sleeping" |
| |------------------------->|
... ....
| | |
| | (15) Client has GET |
| | request for |
| | SleepyNode-1 but |
| | cannot send it since|
| | SleepyNode-1 is not |
| | awake |
|(16) SleepyNode-1 wakes up | |
| | |
| | |
|(17) SleepyNode-1 updates | |
| SleepState | |
| | |
| CoAP PUT | |
| /rd/4321, | |
| ?SleepState=Awake; | |
|---------------------------------- >| |
| | |
| | |
| (18) RD updates | |
| sleep state | |
| | |
|(19) 2.04 Changed | |
|<-----------------------------------| |
| | |
| (20) 2.05 Content |
| Observe: 3 |
| Token: 0x4a |
| <coap://sleepyNode-1/temp>; |
| SleepState="Awake" |
| |------------------------->|
| | |
| | |
| | (21) Client detects |
| | SleepyNode-1 is |
| | awake |
| | |
| (22) CoAP GET |
| <coap://SleepyNode-1/temp> |
|<--------------------------------------------------------------|
| |
|-------------------------------------------------------------->|
| (23) 2.05 Content |
| |
]]>
</artwork>
</figure>
</section>
<section title="RD Caching Proxy">
<t>It would be useful for an RD to be able to indicate which proxy performs
caching for Sleepy CoAP nodes (see <xref target="Intro"/>). This would be
done through a new RD "CachingProxy" attribute for each device
(similiar to the attributes defined in <xref target="RD-Based"/>):
<list style="symbols">
<t>An RD may be co-located with a proxy that performs caching for CoAP
nodes. In this case, the RD automatically adds itself to each
CachingProxy entry.</t>
<t>The sleepy node itself could suggest the CachingProxy if it is peered to a
specific proxy.</t>
</list>
This parameter would be added to the RD URI Template Variables defined in
<xref target="I-D.ietf-core-resource-directory"/>.
</t>
</section>
</section>
<section title="Performance Results">
<section anchor="Prototype" title="Prototype Setup">
<t>A simple prototype was implemented to validate certain aspects of the performance of the proposed
CoAP sleepy node support protocol enhancement. The network for the prototype is shown in
<xref target="Configuration"/>.
</t>
<t>Key aspects of the prototype are as follows:
<list style="symbols">
<t>There are two modes of operation: "Caching Only" and "Caching and Sleep Aware"</t>
<t>In "Caching Only" mode the Reverse Proxy will cache responses and service new requests according to the "Max-Age"
parameter as defined in <xref target="I-D.ietf-core-coap"/>.</t>
<t>In "Caching and Sleep Aware" mode the Reverse Proxy will also cache responses and service new requests according to "Max-Age".
However, if the cache is empty (e.g. exceeded Max-Age) then there will be extra sleep aware functionality. Specifically,
the proxy will also be aware of the "SleepDuration", "NextSleep" and "SleepState" sleepy node parameters
as defined in <xref target="RD-Based"/>. Based on these sleep parameters:
<list style="symbols">
<t>For servers that are asleep but expected to wake up soon: The proxy will immediately send a
non-piggy backed ACK to the client. Then store-and-forward
the request to the server when it wakes up, and then return the non-piggybacked
response to the client thereafter.</t>
<t>For servers that are asleep but not expected to wake up soon: The proxy will
immediately send a "5.03 Service Unavailable (and retry after)" to the client.</t>
</list>
</t>
<t>The key variables in the experiment are: (1) Number of clients; (2) Number of sleepy servers; (3) Delay
between client requests; (4) MaxAge; (5) SleepDuration; (6) NextSleep; and (7) SleepState.</t>
<t>The target of the experiment will be to measure the amount of traffic over the network in the two modes
of operation (for the same input client requests profile). It is hypothesized that the
"Caching and Sleep Aware" mode will have the minimal amount of network traffic indicating
that the Sleep Aware network will be the most efficient.</t>
</list>
</t>
<figure title="Prototype Configuration" anchor="Configuration"><artwork>
<![CDATA[
Constrained Network
--------------------
/ \
--- +----------+ /-----\ \
/ \ | CoAP | CoAP \
| | | Reverse | server \
CoAP | | | Proxy | \-----/ ||
+------+ Request | | | | ||
|CoAP |-------------| |---->| +-----+ | Req /-----\ ||
|Client| | | | |Cache| |------->| CoAP ||
| |<------------| |-----| +-----+ |<-------|server ||
+------+ CoAP | | | | Resp \-----/ ||
Response | Corp| |------ | ||
| LAN | |RD | | ||
| | |Sleep| | ||
\ / |Param| | /
--- | | | /
+----------+ /-----\ /
\ CoAP /
\ server /
\ \-----/ /
----------------
]]>
</artwork></figure>
</section>
<section anchor="Initial" title="Initial Results">
<t>Baseline performance results of A CoAP system with Sleep Aware Proxy support
described in <xref target="Prototype"/> is given in <xref target="IETF86Results"/> (see pg. 65-95).
Key conclusions were:
<list style="symbols">
<t>If only GETs are considered, a cache based system is efficient as long as the cache is valid (i.e before Max-Age).</t>
<t>However, since the cache often expires, a Sleep Aware Proxy further minimizes the number of GET
transactions. Also, the Sleep Aware Proxy reduces number of transactions for other methods
(e.g. PUTs) where a cache does not help.</t>
</list>
</t>
</section>
<section anchor="Observe" title="Comparison with Observe">
<t>A comparison of the performance of a CoAP system with Sleep Aware Proxy
versus a CoAP system supporting Observe is given in <xref target="IETF87Results"/> (see pg. 150-182).
Key conclusions were:
<list style="symbols">
<t>If only GETs are considered, an Observe based system is quite efficient.</t>
<t>However, Observe in combination with Sleep Aware Proxy further minimizes the number of GET
transactions. Also, the Sleep Aware Proxy reduces number of transactions for other methods
(e.g. PUTs) where Observe does not help.</t>
</list>
</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Carsten Bormann, Esko Dijk, Thomas Fossati, Salvatore Loreto, Dale Seed, and Zach Shelby for valuable
discussions and feedback on this document.</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>TBD. (All drafts are required to have a security considerations section.
See <xref target="RFC3552">RFC 3552</xref> for a guide.)</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;
&I-D.ietf-core-observe;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC3552;
&I-D.ietf-core-resource-directory;
<reference anchor="IETF86Results" target="http://www.ietf.org/proceedings/86/slides/slides-86-core-1.pdf">
<front>
<title>IETF-86 Sleepy Node Performance Results</title>
<author initials="A." surname="Rahman" fullname="Akbar Rahman"/>
<date month="March" year="2013" />
</front>
</reference>
<reference anchor="IETF87Results" target="http://www.ietf.org/proceedings/87/slides/slides-87-core-0.pdf">
<front>
<title>IETF-87 Sleepy Node Performance Results</title>
<author initials="A." surname="Rahman" fullname="Akbar Rahman"/>
<date month="July" year="2013" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:42:20 |