Block-wise transfers in CoAP
draft-ietf-core-block-17
| 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
plain text
htmlized
pdfized
bibtex
|
||
| Reviews |
GENART Telechat review
(of
-19)
Ready with Nits
|
||
| 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 | (None) | ||
| Responsible AD | Barry Leiba | ||
| Send notices to | core-chairs@ietf.org, draft-ietf-core-block@ietf.org, "Matthias Kovatsch" <kovatsch@inf.ethz.ch> |
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
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)