One document matched: draft-castellani-core-alive-00.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-coap-09.xml">
<!ENTITY I-D.arkko-core-sleepy-sensors SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-arkko-core-sleepy-sensors-00.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc strict="no"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-castellani-core-alive-00" ipr="trust200902">
<front>
<title abbrev="CoAP Alive Message">
CoAP Alive Message
</title>
<author initials="A.P." surname="Castellani" fullname="Angelo P. Castellani">
<organization>University of Padova</organization>
<address>
<postal>
<street>Via Gradenigo 6/B</street>
<code>35131</code>
<city>Padova</city>
<country>Italy</country>
</postal>
<email>angelo@castellani.net</email>
</address>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>salvatore.loreto@ericsson.com</email>
</address>
</author>
<date year="2012" />
<area>APP</area>
<workgroup>CoRE Working Group</workgroup>
<keyword>CoAP</keyword>
<keyword>Alive</keyword>
<abstract>
<t>In the context of a Constrained RESTful Environment (CoRE),
hosts could frequently be energy-constrained
and be turned off the vast majority of time
for energy-saving purposes.</t>
<t>In the case of a CoAP server, while it is offline,
it is neither available to serve requests.
Clients desiring to access its resources
have no way to understand when they will find it up again.</t>
<t>This specification provides a simple new message
that gives to a CoAP server the ability to signal
its current availability in the network.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In the context of a Constrained RESTful Environment (CoRE),
hosts could frequently be energy-constrained
and be turned off the vast majority of time
for energy-saving purposes.</t>
<t>In the case of a CoAP server, while it is offline,
it is neither available to serve requests.
Clients desiring to access its resources
have no way to understand when they will find it up again.</t>
<t>This specification provides a simple new message
that gives to a CoAP server the ability to signal
its current availability in the network.</t>
<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"/>.</t>
</section>
<section title="Alive (ALV) Message Type">
<t>This specification defines a new message type for the CoAP message-layer
(see Section 4.4 of <xref target="I-D.ietf-core-coap"/>).
The type of a message is specified by the T field of the CoAP header.</t>
<t>An "Alive" message (ALV) indicates that a CoAP server is up and ready to serve requests.
Alive shares T value with the Non-Confirmable (NON) message type,
but is univocally distinguishable by the fact that it MUST be empty.</t>
<t>When a client receives an ALV message from a server,
if it is interested in any resource served by it,
the client SHOULD try sending a request to it
since the Alive message provides an indication of its current availability.</t>
</section>
<section title="Examples">
<t><xref target="ex-alive"/> shows a sample use case
where a server notifies its wake up to clients using multicast.</t>
<figure title="Alive usage example" anchor="ex-alive"><artwork>
<![CDATA[
C1 C2 C3 S
| | | . server is sleeping
| | | .
| | | .
| | | .
| | | . server wakes up
|<--|<--|<----| ALV MID=0xfefe
| | | |
| | | | CON MID=0x1234
|------------>| GET /a
| | | |
| | | | ACK MID=0x1234
|<------------| 2.05 "A"
| | | .
| | | . server goes sleeping again
| | | .
| | | .
| | | .
]]>
</artwork></figure>
<t><xref target="ex-alive-with-observe"/> shows a sample application
on how the Alive message can fix the "Observer Model" problem
discussed in Section 4.2.3 of <xref target="I-D.arkko-core-sleepy-sensors"/>.</t>
<figure title="Alive with Observe" anchor="ex-alive-with-observe"><artwork>
<![CDATA[
C1 C2 C3 P S
| | | | . server is sleeping
| | | | .
| | | | . CON MID=0x1234
| | | | . GET
| | | | . Proxy-URI: coap://S/temp
|------------>| . Observe: 0
| | | | .
|<------------| . ACK MID=0x1234
| | | | .
| | | | . (time passes..)
| | | | .
| | | | . server wakes up
| | | |<---| ALV MID=0xfefe
| | | | |
| | | | | CON MID=0xabcd
| | | | | GET /temp
| | | |--->| Observe:0
| | | | |
| | | | | ACK MID=0xabcd
| | | | | 2.05 "22.5 C"
| | | |<---| Observe: 789
| | | | .
| | | | . CON MID=0xabce
| | | | . 2.05 "22.5 C"
|<------------| . Observe: 3013
| | | | .
|------------>| . ACK MID=0xabce
| | | | .
| | | | . (time passess..)
| | | | .
| | | | . resource state changes
| | | | . NON MID=0xfeff
| | | | . 2.05 "21.5 C"
| | | |<---| Observe: 1384
| | | | .
| | | | .
| | | | . NON MID=0xabcf
| | | | . 2.05 "22.5 C"
|<------------| . Observe: 3013
...
]]>
</artwork></figure>
<!--
<t>Note: The Alive message could be used by a server
to signal an expiring Observe session.
When an Observe session has been up for Max-Age seconds
without any change in the resource state,
it MAY send to the client an ALV message,
to indicate that it is available to setup a new Observe session
for that resource.</t>
-->
</section>
<section title="Acknowledgements">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&I-D.ietf-core-coap;
</references>
<references title="Informative References">
&I-D.arkko-core-sleepy-sensors;
</references>
</back>
</rfc>
<!-- Change log
-->
<!-- LocalWords: xref CDATA exploders BUA -->
| PAFTECH AB 2003-2026 | 2026-04-23 10:15:07 |