draft-ietf-core-block-05.txt   draft-ietf-core-block-06.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: July 16, 2012 Sensinode Expires: July 24, 2012 Sensinode
January 13, 2012 January 21, 2012
Blockwise transfers in CoAP Blockwise transfers in CoAP
draft-ietf-core-block-05 draft-ietf-core-block-06
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 July 16, 2012. This Internet-Draft will expire on July 24, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 4, line 37 skipping to change at page 4, line 37
CoAP is based on datagram transports such as UDP, which limit the CoAP is based on datagram transports such as UDP, which limit the
maximum size of resource representations that can be transferred maximum size of resource representations that can be transferred
without creating unreasonable levels of IP fragmentation. In without creating unreasonable levels of IP fragmentation. In
addition, not all resource representations will fit into a single addition, not all resource representations will fit into a single
link layer packet of a constrained network, which may cause link layer packet of a constrained network, which may cause
adaptation layer fragmentation even if IP layer fragmentation is not adaptation layer fragmentation even if IP layer fragmentation is not
required. Using fragmentation (either at the adaptation layer or at required. Using fragmentation (either at the adaptation layer or at
the IP layer) to enable the transport of larger representations is the IP layer) to enable the transport of larger representations is
possible up to the maximum size of the underlying datagram protocol possible up to the maximum size of the underlying datagram protocol
(such as UDP), but the fragmentation/reassembly process loads the (such as UDP), but the fragmentation/reassembly process burdens the
lower layers with conversation state that is better managed in the lower layers with conversation state that is better managed in the
application layer. application layer.
This specification defines a pair of CoAP options to enable _block- This specification defines a pair of CoAP options to enable _block-
wise_ access to resource representations. The Block options provide wise_ access to resource representations. The Block options provide
a minimal way to transfer larger resource representations in a block- a minimal way to transfer larger resource representations in a block-
wise fashion. The overriding objective is to avoid creating wise fashion. The overriding objective is to avoid creating
conversation state at the server for block-wise GET requests. (It is conversation state at the server for block-wise GET requests. (It is
impossible to fully avoid creating conversation state for POST/PUT, impossible to fully avoid creating conversation state for POST/PUT,
if the creation/replacement of resources is to be atomic; where that if the creation/replacement of resources is to be atomic; where that
skipping to change at page 6, line 8 skipping to change at page 6, line 8
In this document, the term "byte" is used in its now customary sense In this document, the term "byte" is used in its now customary sense
as a synonym for "octet". as a synonym for "octet".
Where bit arithmetic is explained, this document uses the notation Where bit arithmetic is explained, this document uses the notation
familiar from the programming language C, except that the operator familiar from the programming language C, except that the operator
"**" stands for exponentiation. "**" stands for exponentiation.
2. Block-wise transfers 2. Block-wise transfers
As discussed in the introduction, there are good reasons to limit the As discussed in the introduction, there are good reasons to limit the
size datagrams in constrained networks: size of datagrams in constrained networks:
o by the maximum datagram size (~ 64 KiB for UDP) o by the maximum datagram size (~ 64 KiB for UDP)
o by the desire to avoid IP fragmentation (MTU of 1280 for IPv6) o by the desire to avoid IP fragmentation (MTU of 1280 for IPv6)
o by the desire to avoid adaptation layer fragmentation (60-80 bytes o by the desire to avoid adaptation layer fragmentation (60-80 bytes
for 6LoWPAN) for 6LoWPAN [RFC4919])
When a resource representation is larger than can be comfortably When a resource representation is larger than can be comfortably
transferred in the payload of a single CoAP datagram, a Block option transferred in the payload of a single CoAP datagram, a Block option
can be used to indicate a block-wise transfer. As payloads can be can be used to indicate a block-wise transfer. As payloads can be
sent both with requests and with responses, this specification sent both with requests and with responses, this specification
provides two separate options for each direction of payload transfer. provides two separate options for each direction of payload transfer.
In the following, the term "payload" will be used for the actual In the following, the term "payload" will be used for the actual
content of a single CoAP message, i.e. a single block being content of a single CoAP message, i.e. a single block being
transferred, while the term "body" will be used for the entire transferred, while the term "body" will be used for the entire
resource representation that is being transferred in a block-wise resource representation that is being transferred in a block-wise
fashion. fashion.
In most cases, all blocks being transferred for a body will be of the In most cases, all blocks being transferred for a body will be of the
same size. The block size is not fixed by the protocol. To keep the same size. The block size is not fixed by the protocol. To keep the
implementation as simple as possible, the Block options support only implementation as simple as possible, the Block options support only
a small range of power-of-two block sizes, from 2**4 (16) to 2**10 a small range of power-of-two block sizes, from 2**4 (16) to 2**10
(1024) bytes. As bodies often will not evenly divide into the power- (1024) bytes. As bodies often will not evenly divide into the power-
of-two block size chosen, the size need not be reached in the final of-two block size chosen, the size need not be reached in the final
block; still this size will be given as the block size even for the block (but even for the final block, the chosen power-of-two size
final block. will still be indicated in the block size field of the Block option).
2.1. The Block Options 2.1. The Block Options
+------+----------+--------+--------+--------+---------------+ +------+----------+--------+--------+--------+---------------+
| Type | C/E | Name | Format | Length | Default | | Type | C/E | Name | Format | Length | Default |
+------+----------+--------+--------+--------+---------------+ +------+----------+--------+--------+--------+---------------+
| 19 | Critical | Block1 | uint | 1-3 B | 0 (see below) | | 19 | Critical | Block1 | uint | 1-3 B | 0 (see below) |
| | | | | | | | | | | | | |
| 17 | Critical | Block2 | uint | 1-3 B | 0 (see below) | | 17 | Critical | Block2 | uint | 1-3 B | 0 (see below) |
+------+----------+--------+--------+--------+---------------+ +------+----------+--------+--------+--------+---------------+
skipping to change at page 9, line 41 skipping to change at page 9, line 41
2.05 response for GET), or a Block1 Option in a request (e.g., PUT 2.05 response for GET), or a Block1 Option in a request (e.g., PUT
or POST): or POST):
* The NUM field in the option value describes what block number * The NUM field in the option value describes what block number
is contained in the payload of this message. is contained in the payload of this message.
* The M bit indicates whether further blocks are required to * The M bit indicates whether further blocks are required to
complete the transfer of that body. complete the transfer of that body.
* The block size given by SZX MUST match the size of the payload * The block size given by SZX MUST match the size of the payload
in bytes, if the M bit is set. (The block size given is in bytes, if the M bit is set. (SZX does not govern the
irrelevant if M is unset). For Block2, if the request payload size if M is unset). For Block2, if the request
suggested a larger value of SZX, the next request MUST move SZX suggested a larger value of SZX, the next request MUST move SZX
down to the size given here. (The effect is that, if the down to the size given here. (The effect is that, if the
server uses the smaller of its preferred block size and the one server uses the smaller of its preferred block size and the one
requested, all blocks for a body use the same block size.) requested, all blocks for a body use the same block size.)
o A Block2 Option in control usage in a request (e.g., GET): o A Block2 Option in control usage in a request (e.g., GET):
* The NUM field in the Block2 Option gives the block number of * The NUM field in the Block2 Option gives the block number of
the payload that is being requested to be returned in the the payload that is being requested to be returned in the
response. response.
skipping to change at page 24, line 13 skipping to change at page 24, line 13
amplification provided. amplification provided.
7. Acknowledgements 7. Acknowledgements
Much of the content of this draft is the result of discussions with Much of the content of this draft is the result of discussions with
the [I-D.ietf-core-coap] authors, and via many CoRE WG discussions. the [I-D.ietf-core-coap] authors, and via many CoRE WG discussions.
Tokens were suggested by Gilman Tolle and refined by Klaus Hartke. Tokens were suggested by Gilman Tolle and refined by Klaus Hartke.
Charles Palmer provided extensive editorial comments to a previous Charles Palmer provided extensive editorial comments to a previous
version of this draft, some of which the authors hope to have covered version of this draft, some of which the authors hope to have covered
in this version. in this version. Esko Dijk reviewed a more recent version, leading
to a number of further editorial improvements.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank, Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)", "Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-08 (work in progress), October 2011. draft-ietf-core-coap-08 (work in progress), October 2011.
skipping to change at page 26, line 5 skipping to change at page 25, line 26
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
8.2. Informative References 8.2. Informative References
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000. Network-based Software Architectures", 2000.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.
Appendix A. Historical Note Appendix A. Historical Note
(This appendix to be deleted by the RFC editor.) (This appendix to be deleted by the RFC editor.)
An earlier version of this draft used a single option: An earlier version of this draft used a single option:
+------+----------+-------+--------+--------+---------------+ +------+----------+-------+--------+--------+---------------+
| Type | C/E | Name | Format | Length | Default | | Type | C/E | Name | Format | Length | Default |
+------+----------+-------+--------+--------+---------------+ +------+----------+-------+--------+--------+---------------+
| 13 | Critical | Block | uint | 1-3 B | 0 (see below) | | 13 | Critical | Block | uint | 1-3 B | 0 (see below) |
 End of changes. 10 change blocks. 
12 lines changed or deleted 18 lines changed or added

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