Internet Engineering Task Force T. Fossati
Internet-Draft KoanLogic
Intended status: Standards Track P. Giacomin
Expires: September 1, 2012 Freelance
S. Loreto
Ericsson
M. Rossini
CS Dept. University of Bologna
February 29, 2012
Sleepy Option for CoAP
draft-giacomin-core-sleepy-option-00
Abstract
This memo defines a framework for allowing asynchronous communication
between sleepy sensors mediated by a supporting Proxy node. The
Proxy acts as a store-and-forward agent that handles requests on
behalf of a sleepy client, and buffers responses coming from the
target origin until the requesting client wakes up and get the
computation results.
A new CoAP option, Sleepy, is defined to initiate and control the
asynchronous exchange.
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 September 1, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Fossati, et al. Expires September 1, 2012 [Page 1]
Internet-Draft Sleepy Option for CoAP February 2012
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Message Flows . . . . . . . . . . . . . . . . . . . . . 4
3.1. Basic Message Flow with CON Semantics . . . . . . . . . . 4
3.2. Basic Message Flow with NON Semantics . . . . . . . . . . 6
4. Optimized Message Flow . . . . . . . . . . . . . . . . . . . . 6
5. Sleepy Option . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Limiting Network Congestion . . . . . . . . . . . . . . . . . 10
7. New Link-Format Attributes . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Fossati, et al. Expires September 1, 2012 [Page 2]
Internet-Draft Sleepy Option for CoAP February 2012
1. Introduction
The proposal described in this memo covers the following use case:
a node A, displaying a very short duty-cycle, needs to interact
with one or more resources hosted at another sleepy node B. The
probability of an empty intersection between their respective wake
periods is quite high, making it hard for the two to synchronize.
The proposal is to arm the Proxy with the ability to act as a store-
and-forward agent mediating the request/response exchange between A
and B.
A declares the will to act onto a given resource hosted at B to the
Proxy, and gives a "get back" indication that tells the Proxy the
time at which it is going to be on duty again, and willing to
retrieve the response from B.
The Proxy is in charge of making the request on behalf of A, using an
appropriate poll interval for a time span upper bounded by the "get
back" value, and to buffer the response from B until A wakes up
again.
This draft defines a new CoAP elective option, Sleepy, targeted
specifically at proxies and used to signal a Proxy the will to
initiate an asynchronous request/response exchange. The Sleepy
option is partitioned in three subfields indicating: the remaining
time before sleep, the expected sleep interval, and (optionally) the
on-duty interval.
1.1. Terminology
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 [RFC2119]. Additional
privileged words are described below.
Sleepy Device: a sensor/actuator (usually battery operated) that
switches off its radio beyond the normal radio duty cycle in order to
save energy.
Store-and-Forward Proxy: a CoAP proxy that is able to act as an
intermediate agent where CoAP PDUs are received, kept, and sent at a
later time to the final destination or to another intermediate
station. Its use may be especially helpful in networks with
intermittent connectivity, such those hosting a significant amount of
sleepy devices.
Fossati, et al. Expires September 1, 2012 [Page 3]
Internet-Draft Sleepy Option for CoAP February 2012
2. Motivation
This memo focuses on the requirement REQ3 of
[I-D.shelby-core-coap-req]:
REQ3: The ability to deal with sleeping nodes. Devices may be
powered off at any point in time but periodically "wake up"
for brief periods of time.
3. Basic Message Flows
In the most general scenario both A and B are sleepy endpoints
showing empty intersection as to their wake intervals, while the
Proxy cache is empty.
3.1. Basic Message Flow with CON Semantics
A typical flow of communication involving the Sleepy option using CON
messaging is shown in Figure 1.
Fossati, et al. Expires September 1, 2012 [Page 4]
Internet-Draft Sleepy Option for CoAP February 2012
A P B
. | .
. CON (0x7a10) | .
(1) +----------------------->| .
| Method | .
| Proxy-Uri: B/res | .
| Sleepy: {2,58,0} | .
| | .
| ACK (0x7a10) | .
(2) |<-----------------------+ .
. | Method .
(3) . +------------------X .
. | Uri-Path: /res .
. | .
. | Method .
(4) . +------------------X .
. | Uri-Path: /res .
. | .
. | Method |
(5) . +------------------------>|
. | Uri-Path: /res |
. | |
. | Response Code |
(6) . |<------------------------+
. | [Content] |
. | .
. | .
. CON (0xfa10) | .
(7) |<-----------------------+ .
| Response Code | .
| [Content] | .
| | .
| ACK (0xfa10) | .
(8) +----------------------->+ .
. | .
Figure 1
In message (1) a sleepy node, A, asks the Proxy to act upon the
resource identified by the Proxy-Uri Option in a possibly
asynchronous way by supplying the Sleepy Option indicating a time at
which A thinks it may be ready (i.e. awake) to retrieve the response
message. The Sleepy Option in the message (1) tells the Proxy that A
will go off-duty in 2 milliseconds, and it will be off-duty for 58
milliseconds, but it does not provide any information about the
optional on-duty interval.
In case the Proxy understands the Sleepy Option, it replies (2) with
Fossati, et al. Expires September 1, 2012 [Page 5]
Internet-Draft Sleepy Option for CoAP February 2012
a separate ACK.
From now on A can get back to sleep while the Proxy sends
periodically the request to the target node, B -- messages (3-5) --
and eventually gets a response back (6).
The stored response is kept by the Proxy until A is on duty again.
(The seeming on-duty time is computed using the quantities previously
supplied by A through the Sleepy Option.) The Proxy sends the
separate response back, operating with the usual rules of CON
retransmission, until an ACK from A is received, or the transmission
retries are exhausted.
Please note that, generally speaking, the framework is completely
agnostic as to the transported message type and method. Further, the
Proxy may rearrange any implied block-wise transfer
[I-D.ietf-core-block] or separate acknowledgment in an optimal way.
[[OPEN ISSUE 1: What if message (2) is lost ?]]
3.2. Basic Message Flow with NON Semantics
In case the sleepy sensor uses NON semantics, the resulting exchange
is the basically the same as the one depicted in Figure 1 with
messages (2) and (8) removed.
4. Optimized Message Flow
The Proxy/Cache, in charge of making the request on behalf of A, MUST
try to immediately satisfy a request by searching the Cache.
Figure 2 shows a request from A which can be satisfied from the cache
(i.e. cache hit) without interrogating B.
Fossati, et al. Expires September 1, 2012 [Page 6]
Internet-Draft Sleepy Option for CoAP February 2012
A P B
. | .
. | .
. CON (0x7a10) | .
(1) +----------------------->| .
| Method | .
| Proxy-Uri: B/res | .
| Sleepy: {2,58,0} | .
| | .
| [cache hit] .
| | .
| ACK (0x7a10) | .
(7) |<-----------------------+ .
. Response Code | .
. [Content] | .
. | .
. | .
Figure 2
In case a request from A can not be satisfied from the Cache (i.e.
cache miss), the Proxy, in charge of making the request on behalf of
A, sends periodically the request to the target node and eventually
gets a response back.
Figure 3 shows a cache miss scenario where the Proxy, knowing that
the target node is awake, forwards the request to B (5) and sends the
response to A (7) within the "time left before sleeping" indication
supplied by A with the request (1). The latter exchange SHALL
concurrently arm a timeout for sending the ACK message to A before it
goes to sleep (in case CON is in use).
Fossati, et al. Expires September 1, 2012 [Page 7]
Internet-Draft Sleepy Option for CoAP February 2012
A P B
. | .
. | .
. CON (0x7a10) | .
(1) +----------------------->| .
| Method | .
| Proxy-Uri: B/res | .
| Sleepy: {5,58,5} | .
| | .
| [cache miss] .
| | |
(5) | +------------------------>|
| | Uri-Path: /res |
| | |
| | Response Code |
(6) | |<------------------------+
| | [Content] |
| ACK (0x7a10) | .
(7) |<-----------------------+ .
. Response Code | .
. [Content] | .
. | .
. | .
Figure 3
In any case, if the Proxy has previously received an indication from
the same target about its on/off-duty behavior via the Sleepy Option
(Section 5), or by any other means (e.g. Section 7), it MUST use it
to devise the most efficient poll strategy, thus avoiding unnecessary
messaging which would just aggravate the constrained network
congestion.
5. Sleepy Option
+-----+----------+---------+--------+--------+---------+
| No. | C/E | Name | Format | Length | Default |
+-----+----------+---------+--------+--------+---------+
| XX | Elective | Sleepy | uint | 8-12 B | (none) |
+-----+----------+---------+--------+--------+---------+
The Sleepy Option in a request is used to signal a Proxy the will to
initiate an asynchronous request/response exchange.
The Sleepy option is elective. If the Proxy does not recognize it,
it will try to serve a fresh representation of the requested
resource, or forward the request to the intended origin; depending on
Fossati, et al. Expires September 1, 2012 [Page 8]
Internet-Draft Sleepy Option for CoAP February 2012
the availability of the endpoints at the time the Proxy tries to
contact them, the usual proxied transaction may succeed, partially
fail, or completely fail.
The Sleepy Option MAY be discretionarily piggybacked by a sleepy node
on response messages to inform the network about the sleepy pattern
in use at the endpoint. This knowledge MAY be used by sleepy-
friendly Proxies to reduce the overall network congestion that is
implied by resorting to blind polling in order to maximize the chance
to get a response from the target.
The value of the Sleepy option is partitioned in three subfields
indicating: the remaining time before sleep, the expected sleep
interval, and (optionally) the on-duty interval.
Two formats are available, a long format (Figure 4), and a short one
(Figure 5) which are easily distinguished from the Length field of
the encoded option: 8 and 12 respectively.
+-------+-------+-------+
| LEFT | SLEEP | WAKE |
+-------+-------+-------+
Figure 4
+-------+-------+
| LEFT | SLEEP |
+-------+-------+
Figure 5
LEFT: 32-bit uint encoding the number of milliseconds that the
sending node is left before going off-duty. The maximum value is
0xFFFFFFFF, which allows for 71582 minutes.
SLEEP: 32-bit uint encoding the number of milliseconds that the
sending node is off-duty. The maximum value allows for 71582
minutes (i.e. approx. 50 days).
WAKE: optional 32-bit uint encoding the number of milliseconds
that the sending node is on-duty.
[[OPEN ISSUE 2: shrink to 24-bit uint LEFT and WAKE (i.e. max ~4
hours) ?]]
[[OPEN ISSUE 3: change milli to seconds ?]]
Fossati, et al. Expires September 1, 2012 [Page 9]
Internet-Draft Sleepy Option for CoAP February 2012
6. Limiting Network Congestion
The retransmit function at the Proxy is conflicting with the overall
requirement of congestion avoidance on the constrained network.
Therefore the proxy SHOULD try to learn as much as possible about the
on/off-duty behavior of the nodes that it is trying to reach, and
keep the gained knowledge to inform future message exchanges with
these endpoints.
Missing an explicit signaling at the network/transport layer,
endpoints that have a predictable sleep/awake pattern SHOULD try to
inform the other entities in the network by piggybacking, whenever
possible, the Sleepy Option in the messages (both requests and
responses) they are exchanging with other peers.
A further possibility is to distribute the information regarding the
sleep/awake pattern by extending the resource attributes available
through the Resource Directory with a link-format
[I-D.ietf-core-link-format] version of the Sleepy option (see
Section 7).
7. New Link-Format Attributes
This specification defines the following new attributes for use in
the CoRE Link Format:
link-extension = ( "sleep" "=" 1*DIGIT )
link-extension = ( "wake" "=" 1*DIGIT )
link-extension = ( "start" "=" 1*DIGIT ) ; in seconds since Epoch
The sleep and wake attributes have the same semantics and format as
the SLEEP and WAKE subfields of the Sleepy Option respectively
(Section 5). The start attribute sets the base time from which the
offsets indicated by sleep and wake must be computed.
8. Acknowledgements
[TBD]
9. IANA Considerations
The following entries are added to the CoAP Option Numbers registry:
Fossati, et al. Expires September 1, 2012 [Page 10]
Internet-Draft Sleepy Option for CoAP February 2012
.------------------------------.
| Number | Name | Reference |
:--------:---------:-----------:
| 2k | Sleepy | RFC XXXX |
`------------------------------'
The "start", "wake" and "sleep" attributes need to be registered when
a future Web Linking attribute is created.
10. Security Considerations
The same considerations as those highlighted in Section 10.3.2 and
10.3.3 of [I-D.ietf-core-coap] apply, and are somewhat amplified by
the possible congestion induced by the tentative setup of
communication with the target node (messages 3-5 in Figure 1). The
Proxy SHOULD try to send as little messages as possibile in order to
contact the requested endpoint and MUST make use of the wake/sleep
indication in case they have been previously made available by the
target node through the Sleepy Option.
11. References
11.1. Normative References
[I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
draft-ietf-core-block-08 (work in progress),
February 2012.
[I-D.ietf-core-coap]
Frank, B., Bormann, C., Hartke, K., and Z. Shelby,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-08 (work in progress), October 2011.
[I-D.ietf-core-link-format]
Shelby, Z., "CoRE Link Format",
draft-ietf-core-link-format-11 (work in progress),
January 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[I-D.shelby-core-coap-req]
Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R.
Fossati, et al. Expires September 1, 2012 [Page 11]
Internet-Draft Sleepy Option for CoAP February 2012
Kelsey, "CoAP Requirements and Features",
draft-shelby-core-coap-req-02 (work in progress),
October 2010.
Authors' Addresses
Thomas Fossati
KoanLogic
Via di Sabbiuno, 11/5
Bologna 40100
Italy
Email: tho@koanlogic.com
Pierpaolo Giacomin
Freelance
Email: yrz@anche.no
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
Mirko Rossini
CS Dept. University of Bologna
Email: mirko.rossini@ymail.com
Fossati, et al. Expires September 1, 2012 [Page 12]