--- 1/draft-ietf-core-block-05.txt 2012-01-21 16:13:59.890721604 +0100 +++ 2/draft-ietf-core-block-06.txt 2012-01-21 16:13:59.934671659 +0100 @@ -1,19 +1,19 @@ CoRE Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Standards Track Z. Shelby, Ed. -Expires: July 16, 2012 Sensinode - January 13, 2012 +Expires: July 24, 2012 Sensinode + January 21, 2012 Blockwise transfers in CoAP - draft-ietf-core-block-05 + draft-ietf-core-block-06 Abstract CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive @@ -45,21 +45,21 @@ 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 July 16, 2012. + This Internet-Draft will expire on July 24, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 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 @@ -113,21 +113,21 @@ CoAP is based on datagram transports such as UDP, which limit the maximum size of resource representations that can be transferred without creating unreasonable levels of IP fragmentation. In addition, not all resource representations will fit into a single link layer packet of a constrained network, which may cause adaptation layer fragmentation even if IP layer fragmentation is not required. Using fragmentation (either at the adaptation layer or at the IP layer) to enable the transport of larger representations is 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 application layer. This specification defines a pair of CoAP options to enable _block- wise_ access to resource representations. The Block options provide a minimal way to transfer larger resource representations in a block- wise fashion. The overriding objective is to avoid creating conversation state at the server for block-wise GET requests. (It is impossible to fully avoid creating conversation state for POST/PUT, if the creation/replacement of resources is to be atomic; where that @@ -166,49 +166,49 @@ In this document, the term "byte" is used in its now customary sense as a synonym for "octet". Where bit arithmetic is explained, this document uses the notation familiar from the programming language C, except that the operator "**" stands for exponentiation. 2. Block-wise transfers 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 desire to avoid IP fragmentation (MTU of 1280 for IPv6) 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 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 sent both with requests and with responses, this specification provides two separate options for each direction of payload transfer. In the following, the term "payload" will be used for the actual content of a single CoAP message, i.e. a single block being transferred, while the term "body" will be used for the entire resource representation that is being transferred in a block-wise fashion. 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 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 (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 - block; still this size will be given as the block size even for the - final block. + block (but even for the final block, the chosen power-of-two size + will still be indicated in the block size field of the Block option). 2.1. The Block Options +------+----------+--------+--------+--------+---------------+ | Type | C/E | Name | Format | Length | Default | +------+----------+--------+--------+--------+---------------+ | 19 | Critical | Block1 | uint | 1-3 B | 0 (see below) | | | | | | | | | 17 | Critical | Block2 | uint | 1-3 B | 0 (see below) | +------+----------+--------+--------+--------+---------------+ @@ -332,22 +332,22 @@ 2.05 response for GET), or a Block1 Option in a request (e.g., PUT or POST): * The NUM field in the option value describes what block number is contained in the payload of this message. * The M bit indicates whether further blocks are required to complete the transfer of that body. * 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 - irrelevant if M is unset). For Block2, if the request + in bytes, if the M bit is set. (SZX does not govern the + payload size if M is unset). For Block2, if the request suggested a larger value of SZX, the next request MUST move SZX down to the size given here. (The effect is that, if the server uses the smaller of its preferred block size and the one requested, all blocks for a body use the same block size.) 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 payload that is being requested to be returned in the response. @@ -863,21 +863,22 @@ amplification provided. 7. Acknowledgements 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. Tokens were suggested by Gilman Tolle and refined by Klaus Hartke. Charles Palmer provided extensive editorial comments to a previous 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.1. Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-08 (work in progress), October 2011. @@ -886,20 +887,25 @@ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 8.2. Informative References [REST] Fielding, R., "Architectural Styles and the Design of 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 (This appendix to be deleted by the RFC editor.) An earlier version of this draft used a single option: +------+----------+-------+--------+--------+---------------+ | Type | C/E | Name | Format | Length | Default | +------+----------+-------+--------+--------+---------------+ | 13 | Critical | Block | uint | 1-3 B | 0 (see below) |