Block-wise transfers in CoAP
draft-ietf-core-block-17

The information below is for an old version of the document
Document Type Expired Internet-Draft (core WG)
Authors Carsten Bormann  , Zach Shelby 
Last updated 2015-09-10 (latest revision 2015-03-09)
Replaces draft-bormann-core-coap-block
Stream Internet Engineering Task Force (IETF)
Formats
Expired & archived
pdf htmlized bibtex
Reviews
Additional Resources
- Mailing list discussion
Stream WG state WG Consensus: Waiting for Write-Up
Document shepherd Matthias Kovatsch
Shepherd write-up Show (last changed 2015-09-06)
IESG IESG state Expired (IESG: Dead)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Barry Leiba
Send notices to core-chairs@ietf.org, draft-ietf-core-block@ietf.org, "Matthias Kovatsch" <kovatsch@inf.ethz.ch>

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-ietf-core-block-17.txt

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 and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.

Authors

Carsten Bormann (cabo@tzi.org)
Zach Shelby (zach.shelby@arm.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)