draft-ietf-core-block-16.txt   draft-ietf-core-block-17.txt 
CoRE Working Group C. Bormann CoRE Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track Z. Shelby, Ed. Intended status: Standards Track Z. Shelby, Ed.
Expires: April 30, 2015 ARM Expires: September 10, 2015 ARM
October 27, 2014 March 09, 2015
Blockwise transfers in CoAP Block-wise transfers in CoAP
draft-ietf-core-block-16 draft-ietf-core-block-17
Abstract Abstract
CoAP is a RESTful transfer protocol for constrained nodes and CoAP is a RESTful transfer protocol for constrained nodes and
networks. Basic CoAP messages work well for the small payloads we networks. Basic CoAP messages work well for the small payloads we
expect from temperature sensors, light switches, and similar expect from temperature sensors, light switches, and similar
building-automation devices. Occasionally, however, applications building-automation devices. Occasionally, however, applications
will need to transfer larger payloads -- for instance, for firmware will need to transfer larger payloads -- for instance, for firmware
updates. With HTTP, TCP does the grunt work of slicing large updates. With HTTP, TCP does the grunt work of slicing large
payloads up into multiple packets and ensuring that they all arrive payloads up into multiple packets and ensuring that they all arrive
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 36 skipping to change at page 2, line 36
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Block-wise transfers . . . . . . . . . . . . . . . . . . . . 5 2. Block-wise transfers . . . . . . . . . . . . . . . . . . . . 5
2.1. The Block2 and Block1 Options . . . . . . . . . . . . . . 5 2.1. The Block2 and Block1 Options . . . . . . . . . . . . . . 5
2.2. Structure of a Block Option . . . . . . . . . . . . . . . 6 2.2. Structure of a Block Option . . . . . . . . . . . . . . . 6
2.3. Block Options in Requests and Responses . . . . . . . . . 8 2.3. Block Options in Requests and Responses . . . . . . . . . 8
2.4. Using the Block2 Option . . . . . . . . . . . . . . . . . 10 2.4. Using the Block2 Option . . . . . . . . . . . . . . . . . 10
2.5. Using the Block1 Option . . . . . . . . . . . . . . . . . 12 2.5. Using the Block1 Option . . . . . . . . . . . . . . . . . 12
2.6. Combining Blockwise Transfers with the Observe Option . . 13 2.6. Combining Block-wise Transfers with the Observe Option . 13
2.7. Combining Block1 and Block2 . . . . . . . . . . . . . . . 14 2.7. Combining Block1 and Block2 . . . . . . . . . . . . . . . 14
2.8. Combining Block2 with Multicast . . . . . . . . . . . . . 14 2.8. Combining Block2 with Multicast . . . . . . . . . . . . . 14
2.9. Response Codes . . . . . . . . . . . . . . . . . . . . . 14 2.9. Response Codes . . . . . . . . . . . . . . . . . . . . . 14
2.9.1. 2.31 Continue . . . . . . . . . . . . . . . . . . . . 15 2.9.1. 2.31 Continue . . . . . . . . . . . . . . . . . . . . 15
2.9.2. 4.08 Request Entity Incomplete . . . . . . . . . . . 15 2.9.2. 4.08 Request Entity Incomplete . . . . . . . . . . . 15
2.9.3. 4.13 Request Entity Too Large . . . . . . . . . . . . 15 2.9.3. 4.13 Request Entity Too Large . . . . . . . . . . . . 15
2.10. Caching Considerations . . . . . . . . . . . . . . . . . 15 2.10. Caching Considerations . . . . . . . . . . . . . . . . . 15
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Block2 Examples . . . . . . . . . . . . . . . . . . . . . 16 3.1. Block2 Examples . . . . . . . . . . . . . . . . . . . . . 16
3.2. Block1 Examples . . . . . . . . . . . . . . . . . . . . . 20 3.2. Block1 Examples . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 12, line 32 skipping to change at page 12, line 32
To counter the effects of adaptation layer fragmentation on packet To counter the effects of adaptation layer fragmentation on packet
delivery probability, a client may want to give up retransmitting a delivery probability, a client may want to give up retransmitting a
request with a relatively large payload even before MAX_RETRANSMIT request with a relatively large payload even before MAX_RETRANSMIT
has been reached, and try restating the request as a block-wise has been reached, and try restating the request as a block-wise
transfer with a smaller payload. Note that this new attempt is then transfer with a smaller payload. Note that this new attempt is then
a new message-layer transaction and requires a new Message ID. a new message-layer transaction and requires a new Message ID.
(Because of the uncertainty whether the request or the (Because of the uncertainty whether the request or the
acknowledgement was lost, this strategy is useful mostly for acknowledgement was lost, this strategy is useful mostly for
idempotent requests.) idempotent requests.)
In a blockwise transfer of a request payload (e.g., a PUT or POST) In a block-wise transfer of a request payload (e.g., a PUT or POST)
that is intended to be implemented in an atomic fashion at the that is intended to be implemented in an atomic fashion at the
server, the actual creation/replacement takes place at the time the server, the actual creation/replacement takes place at the time the
final block, i.e. a block with the M bit unset in the Block1 Option, final block, i.e. a block with the M bit unset in the Block1 Option,
is received. In this case, all success responses to non-final blocks is received. In this case, all success responses to non-final blocks
carry the response code 2.31 (Continue, Section 2.9.1). If not all carry the response code 2.31 (Continue, Section 2.9.1). If not all
previous blocks are available at the server at the time of processing previous blocks are available at the server at the time of processing
the final block, the transfer fails and error code 4.08 (Request the final block, the transfer fails and error code 4.08 (Request
Entity Incomplete, Section 2.9.2) MUST be returned. A server MAY Entity Incomplete, Section 2.9.2) MUST be returned. A server MAY
also return a 4.08 error code for any (final or non-final) Block1 also return a 4.08 error code for any (final or non-final) Block1
transfer that is not in sequence; clients that do not have specific transfer that is not in sequence; clients that do not have specific
skipping to change at page 13, line 24 skipping to change at page 13, line 24
The Block1 option provides no way for a single endpoint to perform The Block1 option provides no way for a single endpoint to perform
multiple concurrently proceeding block-wise request payload transfer multiple concurrently proceeding block-wise request payload transfer
(e.g., PUT or POST) operations to the same resource. Starting a new (e.g., PUT or POST) operations to the same resource. Starting a new
block-wise sequence of requests to the same resource (before an old block-wise sequence of requests to the same resource (before an old
sequence from the same endpoint was finished) simply overwrites the sequence from the same endpoint was finished) simply overwrites the
context the server may still be keeping. (This is probably exactly context the server may still be keeping. (This is probably exactly
what one wants in this case - the client may simply have restarted what one wants in this case - the client may simply have restarted
and lost its knowledge of the previous sequence.) and lost its knowledge of the previous sequence.)
2.6. Combining Blockwise Transfers with the Observe Option 2.6. Combining Block-wise Transfers with the Observe Option
The Observe Option provides a way for a client to be notified about The Observe Option provides a way for a client to be notified about
changes over time of a resource [I-D.ietf-core-observe]. Resources changes over time of a resource [I-D.ietf-core-observe]. Resources
observed by clients may be larger than can be comfortably processed observed by clients may be larger than can be comfortably processed
or transferred in one CoAP message. The following rules apply to the or transferred in one CoAP message. The following rules apply to the
combination of blockwise transfers with notifications. combination of block-wise transfers with notifications.
Observation relationships always apply to an entire resource; the Observation relationships always apply to an entire resource; the
Block2 option does not provide a way to observe a single block of a Block2 option does not provide a way to observe a single block of a
resource. resource.
As with basic GET transfers, the client can indicate its desired As with basic GET transfers, the client can indicate its desired
block size in a Block2 Option in the GET request establishing or block size in a Block2 Option in the GET request establishing or
renewing the observation relationship. If the server supports renewing the observation relationship. If the server supports block-
blockwise transfers, it SHOULD take note of the block size and apply wise transfers, it SHOULD take note of the block size and apply it as
it as a maximum size to all notifications/responses resulting from a maximum size to all notifications/responses resulting from the GET
the GET request (until the client is removed from the list of request (until the client is removed from the list of observers or
observers or the entry in that list is updated by the server the entry in that list is updated by the server receiving a new GET
receiving a new GET request for the resource from the client). request for the resource from the client).
When sending a 2.05 (Content) notification, the server only sends the When sending a 2.05 (Content) notification, the server only sends the
first block of the representation. The client retrieves the rest of first block of the representation. The client retrieves the rest of
the representation as if it had caused this first response by a GET the representation as if it had caused this first response by a GET
request, i.e., by using additional GET requests with Block2 options request, i.e., by using additional GET requests with Block2 options
containing NUM values greater than zero. (This results in the containing NUM values greater than zero. (This results in the
transfer of the entire representation, even if only some of the transfer of the entire representation, even if only some of the
blocks have changed with respect to a previous notification.) blocks have changed with respect to a previous notification.)
As with other dynamically changing resources, to ensure that the As with other dynamically changing resources, to ensure that the
blocks being reassembled are from the same version of the blocks being reassembled are from the same version of the
skipping to change at page 17, line 19 skipping to change at page 17, line 19
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 | | <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| | | |
| CON [MID=1235], GET, /status, 2:1/0/128 ------> | | CON [MID=1235], GET, /status, 2:1/0/128 ------> |
| | | |
| <------ ACK [MID=1235], 2.05 Content, 2:1/1/128 | | <------ ACK [MID=1235], 2.05 Content, 2:1/1/128 |
| | | |
| CON [MID=1236], GET, /status, 2:2/0/128 ------> | | CON [MID=1236], GET, /status, 2:2/0/128 ------> |
| | | |
| <------ ACK [MID=1236], 2.05 Content, 2:2/0/128 | | <------ ACK [MID=1236], 2.05 Content, 2:2/0/128 |
Figure 2: Simple blockwise GET Figure 2: Simple block-wise GET
In the second example (Figure 3), the client anticipates the In the second example (Figure 3), the client anticipates the block-
blockwise transfer (e.g., because of a size indication in the link- wise transfer (e.g., because of a size indication in the link-format
format description [RFC6690]) and sends a block size proposal. All description [RFC6690]) and sends a block size proposal. All ACK
ACK messages except for the last carry 64 bytes of payload; the last messages except for the last carry 64 bytes of payload; the last one
one carries between 1 and 64 bytes. carries between 1 and 64 bytes.
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], GET, /status, 2:0/0/64 ------> | | CON [MID=1234], GET, /status, 2:0/0/64 ------> |
| | | |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/64 | | <------ ACK [MID=1234], 2.05 Content, 2:0/1/64 |
| | | |
| CON [MID=1235], GET, /status, 2:1/0/64 ------> | | CON [MID=1235], GET, /status, 2:1/0/64 ------> |
| | | |
| <------ ACK [MID=1235], 2.05 Content, 2:1/1/64 | | <------ ACK [MID=1235], 2.05 Content, 2:1/1/64 |
skipping to change at page 17, line 47 skipping to change at page 17, line 47
: ... : : ... :
: : : :
| CON [MID=1238], GET, /status, 2:4/0/64 ------> | | CON [MID=1238], GET, /status, 2:4/0/64 ------> |
| | | |
| <------ ACK [MID=1238], 2.05 Content, 2:4/1/64 | | <------ ACK [MID=1238], 2.05 Content, 2:4/1/64 |
| | | |
| CON [MID=1239], GET, /status, 2:5/0/64 ------> | | CON [MID=1239], GET, /status, 2:5/0/64 ------> |
| | | |
| <------ ACK [MID=1239], 2.05 Content, 2:5/0/64 | | <------ ACK [MID=1239], 2.05 Content, 2:5/0/64 |
Figure 3: Blockwise GET with early negotiation Figure 3: Block-wise GET with early negotiation
In the third example (Figure 4), the client is surprised by the need In the third example (Figure 4), the client is surprised by the need
for a blockwise transfer, and unhappy with the size chosen for a block-wise transfer, and unhappy with the size chosen
unilaterally by the server. As it did not send a size proposal unilaterally by the server. As it did not send a size proposal
initially, the negotiation only influences the size from the second initially, the negotiation only influences the size from the second
message exchange onward. Since the client already obtained both the message exchange onward. Since the client already obtained both the
first and second 64-byte block in the first 128-byte exchange, it first and second 64-byte block in the first 128-byte exchange, it
goes on requesting the third 64-byte block ("2/0/64"). None of this goes on requesting the third 64-byte block ("2/0/64"). None of this
is (or needs to be) understood by the server, which simply responds is (or needs to be) understood by the server, which simply responds
to the requests as it best can. to the requests as it best can.
CLIENT SERVER CLIENT SERVER
| | | |
skipping to change at page 18, line 32 skipping to change at page 18, line 32
| <------ ACK [MID=1236], 2.05 Content, 2:3/1/64 | | <------ ACK [MID=1236], 2.05 Content, 2:3/1/64 |
| | | |
| CON [MID=1237], GET, /status, 2:4/0/64 ------> | | CON [MID=1237], GET, /status, 2:4/0/64 ------> |
| | | |
| <------ ACK [MID=1237], 2.05 Content, 2:4/1/64 | | <------ ACK [MID=1237], 2.05 Content, 2:4/1/64 |
| | | |
| CON [MID=1238], GET, /status, 2:5/0/64 ------> | | CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| | | |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 | | <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
Figure 4: Blockwise GET with late negotiation Figure 4: Block-wise GET with late negotiation
In all these (and the following) cases, retransmissions are handled In all these (and the following) cases, retransmissions are handled
by the CoAP message exchange layer, so they don't influence the block by the CoAP message exchange layer, so they don't influence the block
operations (Figure 5, Figure 6). operations (Figure 5, Figure 6).
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], GET, /status ------> | | CON [MID=1234], GET, /status ------> |
| | | |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 | | <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
skipping to change at page 19, line 25 skipping to change at page 19, line 25
| CON [MID=1235], GET, /status, 2:2/0/64 ------> | | CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| | | |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 | | <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
: : : :
: ... : : ... :
: : : :
| CON [MID=1238], GET, /status, 2:5/0/64 ------> | | CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| | | |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 | | <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
Figure 5: Blockwise GET with late negotiation and lost CON Figure 5: Block-wise GET with late negotiation and lost CON
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], GET, /status ------> | | CON [MID=1234], GET, /status ------> |
| | | |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 | | <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| | | |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> | | CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| | | |
| //////////////////////////////////tent, 2:2/1/64 | | //////////////////////////////////tent, 2:2/1/64 |
skipping to change at page 19, line 49 skipping to change at page 19, line 49
| CON [MID=1235], GET, /status, 2:2/0/64 ------> | | CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| | | |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 | | <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
: : : :
: ... : : ... :
: : : :
| CON [MID=1238], GET, /status, 2:5/0/64 ------> | | CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| | | |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 | | <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
Figure 6: Blockwise GET with late negotiation and lost ACK Figure 6: Block-wise GET with late negotiation and lost ACK
3.2. Block1 Examples 3.2. Block1 Examples
The following examples demonstrate a PUT exchange; a POST exchange The following examples demonstrate a PUT exchange; a POST exchange
looks the same, with different requirements on atomicity/idempotence. looks the same, with different requirements on atomicity/idempotence.
Note that, similar to GET, the responses to the requests that have a Note that, similar to GET, the responses to the requests that have a
more bit in the request Block1 Option are provisional and carry the more bit in the request Block1 Option are provisional and carry the
response code 2.31 (Continue); only the final response tells the response code 2.31 (Continue); only the final response tells the
client that the PUT did succeed. client that the PUT did succeed.
skipping to change at page 20, line 28 skipping to change at page 20, line 28
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 | | <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| | | |
| CON [MID=1235], PUT, /options, 1:1/1/128 ------> | | CON [MID=1235], PUT, /options, 1:1/1/128 ------> |
| | | |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 | | <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| | | |
| CON [MID=1236], PUT, /options, 1:2/0/128 ------> | | CON [MID=1236], PUT, /options, 1:2/0/128 ------> |
| | | |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 | | <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |
Figure 7: Simple atomic blockwise PUT Figure 7: Simple atomic block-wise PUT
A stateless server that simply builds/updates the resource in place A stateless server that simply builds/updates the resource in place
(statelessly) may indicate this by not setting the more bit in the (statelessly) may indicate this by not setting the more bit in the
response (Figure 8); in this case, the response codes are valid response (Figure 8); in this case, the response codes are valid
separately for each block being updated. This is of course only an separately for each block being updated. This is of course only an
acceptable behavior of the server if the potential inconsistency acceptable behavior of the server if the potential inconsistency
present during the run of the message exchange sequence does not lead present during the run of the message exchange sequence does not lead
to problems, e.g. because the resource being created or changed is to problems, e.g. because the resource being created or changed is
not yet or not currently in use. not yet or not currently in use.
skipping to change at page 21, line 19 skipping to change at page 21, line 19
| <------ ACK [MID=1234], 2.04 Changed, 1:0/0/128 | | <------ ACK [MID=1234], 2.04 Changed, 1:0/0/128 |
| | | |
| CON [MID=1235], PUT, /options, 1:1/1/128 ------> | | CON [MID=1235], PUT, /options, 1:1/1/128 ------> |
| | | |
| <------ ACK [MID=1235], 2.04 Changed, 1:1/0/128 | | <------ ACK [MID=1235], 2.04 Changed, 1:1/0/128 |
| | | |
| CON [MID=1236], PUT, /options, 1:2/0/128 ------> | | CON [MID=1236], PUT, /options, 1:2/0/128 ------> |
| | | |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 | | <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |
Figure 8: Simple stateless blockwise PUT Figure 8: Simple stateless block-wise PUT
Finally, a server receiving a blockwise PUT or POST may want to Finally, a server receiving a block-wise PUT or POST may want to
indicate a smaller block size preference (Figure 9). In this case, indicate a smaller block size preference (Figure 9). In this case,
the client SHOULD continue with a smaller block size; if it does, it the client SHOULD continue with a smaller block size; if it does, it
MUST adjust the block number to properly count in that smaller size. MUST adjust the block number to properly count in that smaller size.
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], PUT, /options, 1:0/1/128 ------> | | CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
| | | |
| <------ ACK [MID=1234], 2.04 Changed, 1:0/1/32 | | <------ ACK [MID=1234], 2.31 Continue, 1:0/1/32 |
| | | |
| CON [MID=1235], PUT, /options, 1:4/1/32 ------> | | CON [MID=1235], PUT, /options, 1:4/1/32 ------> |
| | | |
| <------ ACK [MID=1235], 2.04 Changed, 1:4/1/32 | | <------ ACK [MID=1235], 2.31 Continue, 1:4/1/32 |
| | | |
| CON [MID=1236], PUT, /options, 1:5/1/32 ------> | | CON [MID=1236], PUT, /options, 1:5/1/32 ------> |
| | | |
| <------ ACK [MID=1235], 2.04 Changed, 1:5/1/32 | | <------ ACK [MID=1235], 2.31 Continue, 1:5/1/32 |
| | | |
| CON [MID=1237], PUT, /options, 1:6/0/32 ------> | | CON [MID=1237], PUT, /options, 1:6/0/32 ------> |
| | | |
| <------ ACK [MID=1236], 2.04 Changed, 1:6/0/32 | | <------ ACK [MID=1236], 2.04 Changed, 1:6/0/32 |
Figure 9: Simple atomic blockwise PUT with negotiation Figure 9: Simple atomic block-wise PUT with negotiation
3.3. Combining Block1 and Block2 3.3. Combining Block1 and Block2
Block options may be used in both directions of a single exchange. Block options may be used in both directions of a single exchange.
The following example demonstrates a blockwise POST request, The following example demonstrates a block-wise POST request,
resulting in a separate blockwise response. resulting in a separate block-wise response.
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], POST, /soap, 1:0/1/128 ------> | | CON [MID=1234], POST, /soap, 1:0/1/128 ------> |
| | | |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 | | <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| | | |
| CON [MID=1235], POST, /soap, 1:1/1/128 ------> | | CON [MID=1235], POST, /soap, 1:1/1/128 ------> |
| | | |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 | | <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
skipping to change at page 22, line 33 skipping to change at page 22, line 33
| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/128 | | <------ ACK [MID=1237], 2.04 Changed, 2:1/1/128 |
| | | |
| CON [MID=1238], POST, /soap, 2:2/0/128 ------> | | CON [MID=1238], POST, /soap, 2:2/0/128 ------> |
| | | |
| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/128 | | <------ ACK [MID=1238], 2.04 Changed, 2:2/1/128 |
| | | |
| CON [MID=1239], POST, /soap, 2:3/0/128 ------> | | CON [MID=1239], POST, /soap, 2:3/0/128 ------> |
| | | |
| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/128 | | <------ ACK [MID=1239], 2.04 Changed, 2:3/0/128 |
Figure 10: Atomic blockwise POST with blockwise response Figure 10: Atomic block-wise POST with block-wise response
This model does provide for early negotiation input to the Block2 This model does provide for early negotiation input to the Block2
blockwise transfer, as shown below. block-wise transfer, as shown below.
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], POST, /soap, 1:0/1/128 ------> | | CON [MID=1234], POST, /soap, 1:0/1/128 ------> |
| | | |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 | | <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| | | |
| CON [MID=1235], POST, /soap, 1:1/1/128 ------> | | CON [MID=1235], POST, /soap, 1:1/1/128 ------> |
| | | |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 | | <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
skipping to change at page 23, line 32 skipping to change at page 23, line 32
| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/64 | | <------ ACK [MID=1237], 2.04 Changed, 2:1/1/64 |
| | | |
| CON [MID=1238], POST, /soap, 2:2/0/64 ------> | | CON [MID=1238], POST, /soap, 2:2/0/64 ------> |
| | | |
| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/64 | | <------ ACK [MID=1238], 2.04 Changed, 2:2/1/64 |
| | | |
| CON [MID=1239], POST, /soap, 2:3/0/64 ------> | | CON [MID=1239], POST, /soap, 2:3/0/64 ------> |
| | | |
| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/64 | | <------ ACK [MID=1239], 2.04 Changed, 2:3/0/64 |
Figure 11: Atomic blockwise POST with blockwise response, early Figure 11: Atomic block-wise POST with block-wise response, early
negotiation negotiation
3.4. Combining Observe and Block2 3.4. Combining Observe and Block2
In the following example, the server first sends a direct response In the following example, the server first sends a direct response
(Observe sequence number 62350) to the initial GET request (the (Observe sequence number 62350) to the initial GET request (the
resulting blockwise transfer is as in Figure 4 and has therefore been resulting block-wise transfer is as in Figure 4 and has therefore
left out). The second transfer is started by a 2.05 notification been left out). The second transfer is started by a 2.05
that contains just the first block (Observe sequence number 62354); notification that contains just the first block (Observe sequence
the client then goes on to obtain the rest of the blocks. number 62354); the client then goes on to obtain the rest of the
blocks.
CLIENT SERVER CLIENT SERVER
| | | |
+----->| Header: GET 0x41011636 +----->| Header: GET 0x41011636
| GET | Token: 0xfb | GET | Token: 0xfb
| | Uri-Path: status-icon | | Uri-Path: status-icon
| | Observe: (empty) | | Observe: (empty)
| | | |
|<-----+ Header: 2.05 0x61451636 |<-----+ Header: 2.05 0x61451636
| 2.05 | Token: 0xfb | 2.05 | Token: 0xfb
skipping to change at page 24, line 46 skipping to change at page 24, line 47
| GET | Token: 0xfc | GET | Token: 0xfc
| | Uri-Path: status-icon | | Uri-Path: status-icon
| | Block2: 2/0/128 | | Block2: 2/0/128
| | | |
|<-----+ Header: 2.05 0x61451638 |<-----+ Header: 2.05 0x61451638
| 2.05 | Token: 0xfc | 2.05 | Token: 0xfc
| | Block2: 2/0/128 | | Block2: 2/0/128
| | ETag: 6f00f392 | | ETag: 6f00f392
| | Payload: [53 bytes] | | Payload: [53 bytes]
Figure 12: Observe sequence with blockwise response Figure 12: Observe sequence with block-wise response
(Note that the choice of token 0xfc in this examples is arbitrary; (Note that the choice of token 0xfc in this examples is arbitrary;
tokens are just shown in this example to illustrate that the requests tokens are just shown in this example to illustrate that the requests
for additional blocks cannot make use of the token of the Observation for additional blocks cannot make use of the token of the Observation
relationship. As a general comment on tokens, there is no other relationship. As a general comment on tokens, there is no other
mention of tokens in this document, as blockwise transfers handle mention of tokens in this document, as block-wise transfers handle
tokens like any other CoAP exchange. As usual the client is free to tokens like any other CoAP exchange. As usual the client is free to
choose tokens for each exchange as it likes.) choose tokens for each exchange as it likes.)
In the following example, the client also uses early negotiation to In the following example, the client also uses early negotiation to
limit the block size to 64 bytes. limit the block size to 64 bytes.
CLIENT SERVER CLIENT SERVER
| | | |
+----->| Header: GET 0x41011636 +----->| Header: GET 0x41011636
| GET | Token: 0xfb | GET | Token: 0xfb
skipping to change at page 27, line 30 skipping to change at page 27, line 30
+-----+---+---+---+---+-------+--------+--------+---------+ +-----+---+---+---+---+-------+--------+--------+---------+
| 60 | | | x | | Size1 | uint | 0-4 | (none) | | 60 | | | x | | Size1 | uint | 0-4 | (none) |
| | | | | | | | | | | | | | | | | | | |
| 28 | | | x | | Size2 | uint | 0-4 | (none) | | 28 | | | x | | Size2 | uint | 0-4 | (none) |
+-----+---+---+---+---+-------+--------+--------+---------+ +-----+---+---+---+---+-------+--------+--------+---------+
Table 2: Size Option Numbers Table 2: Size Option Numbers
Implementation Notes: Implementation Notes:
o As a quality of implementation consideration, blockwise transfers o As a quality of implementation consideration, block-wise transfers
for which the total size considerably exceeds the size of one for which the total size considerably exceeds the size of one
block are expected to include size indications, whenever those can block are expected to include size indications, whenever those can
be provided without undue effort (preferably with the first block be provided without undue effort (preferably with the first block
exchanged). If the size estimate does not change, the indication exchanged). If the size estimate does not change, the indication
does not need to be repeated for every block. does not need to be repeated for every block.
o The end of a blockwise transfer is governed by the M bits in the o The end of a block-wise transfer is governed by the M bits in the
Block Options, _not_ by exhausting the size estimates exchanged. Block Options, _not_ by exhausting the size estimates exchanged.
o As usual for an option of type uint, the value 0 is best expressed o As usual for an option of type uint, the value 0 is best expressed
as an empty option (0 bytes). There is no default value for as an empty option (0 bytes). There is no default value for
either Size Option. either Size Option.
o The Size Options are neither critical nor unsafe, and are marked o The Size Options are neither critical nor unsafe, and are marked
as No-Cache-Key. as No-Cache-Key.
5. HTTP Mapping Considerations 5. HTTP Mapping Considerations
skipping to change at page 30, line 25 skipping to change at page 30, line 25
adversary sends a Block1 (e.g., PUT) block with a high block number: adversary sends a Block1 (e.g., PUT) block with a high block number:
A naive implementation might exhaust its resources by creating a huge A naive implementation might exhaust its resources by creating a huge
resource representation. resource representation.
Misleading size indications may be used by an attacker to induce Misleading size indications may be used by an attacker to induce
buffer overflows in poor implementations, for which the usual buffer overflows in poor implementations, for which the usual
considerations apply. considerations apply.
7.1. Mitigating Resource Exhaustion Attacks 7.1. Mitigating Resource Exhaustion Attacks
Certain blockwise requests may induce the server to create state, Certain block-wise requests may induce the server to create state,
e.g. to create a snapshot for the blockwise GET of a fast-changing e.g. to create a snapshot for the block-wise GET of a fast-changing
resource to enable consistent access to the same version of a resource to enable consistent access to the same version of a
resource for all blocks, or to create temporary resource resource for all blocks, or to create temporary resource
representations that are collected until pressed into service by a representations that are collected until pressed into service by a
final PUT or POST with the more bit unset. All mechanisms that final PUT or POST with the more bit unset. All mechanisms that
induce a server to create state that cannot simply be cleaned up induce a server to create state that cannot simply be cleaned up
create opportunities for denial-of-service attacks. Servers SHOULD create opportunities for denial-of-service attacks. Servers SHOULD
avoid being subject to resource exhaustion based on state created by avoid being subject to resource exhaustion based on state created by
untrusted sources. But even if this is done, the mitigation may untrusted sources. But even if this is done, the mitigation may
cause a denial-of-service to a legitimate request when it is drowned cause a denial-of-service to a legitimate request when it is drowned
out by other state-creating requests. Wherever possible, servers out by other state-creating requests. Wherever possible, servers
skipping to change at page 30, line 48 skipping to change at page 30, line 48
untrusted sources, e.g. by using stateless approaches. untrusted sources, e.g. by using stateless approaches.
Performing segmentation at the application layer is almost always Performing segmentation at the application layer is almost always
better in this respect than at the transport layer or lower (IP better in this respect than at the transport layer or lower (IP
fragmentation, adaptation layer fragmentation), for instance because fragmentation, adaptation layer fragmentation), for instance because
there is application layer semantics that can be used for mitigation there is application layer semantics that can be used for mitigation
or because lower layers provide security associations that can or because lower layers provide security associations that can
prevent attacks. However, it is less common to apply timeouts and prevent attacks. However, it is less common to apply timeouts and
keepalive mechanisms at the application layer than at lower layers. keepalive mechanisms at the application layer than at lower layers.
Servers MAY want to clean up accumulated state by timing it out (cf. Servers MAY want to clean up accumulated state by timing it out (cf.
response code 4.08), and clients SHOULD be prepared to run blockwise response code 4.08), and clients SHOULD be prepared to run block-wise
transfers in an expedient way to minimize the likelihood of running transfers in an expedient way to minimize the likelihood of running
into such a timeout. into such a timeout.
7.2. Mitigating Amplification Attacks 7.2. Mitigating Amplification Attacks
[RFC7252] discusses the susceptibility of CoAP end-points for use in [RFC7252] discusses the susceptibility of CoAP end-points for use in
amplification attacks. amplification attacks.
A CoAP server can reduce the amount of amplification it provides to A CoAP server can reduce the amount of amplification it provides to
an attacker by offering large resource representations only in an attacker by offering large resource representations only in
skipping to change at page 31, line 44 skipping to change at page 31, line 44
some of the text describing the interaction of Block2 with Observe. some of the text describing the interaction of Block2 with Observe.
Matthias Kovatsch provided a number of significant simplifications of Matthias Kovatsch provided a number of significant simplifications of
the protocol. the protocol.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-core-observe] [I-D.ietf-core-observe]
Hartke, K., "Observing Resources in CoAP", draft-ietf- Hartke, K., "Observing Resources in CoAP", draft-ietf-
core-observe-14 (work in progress), June 2014. core-observe-16 (work in progress), December 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014. Application Protocol (CoAP)", RFC 7252, June 2014.
9.2. Informative References 9.2. Informative References
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
 End of changes. 35 change blocks. 
51 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/