Skip to main content

1. Introduction

The work on Constrained RESTful Environments (CoRE) aims at realizing the Representational State Transfer (REST) architecture in a suitable form for the most constrained nodes (such as microcontrollers with limited RAM and ROM [RFC7228]) and networks (such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC4944]) [RFC7252]. The CoAP protocol is intended to provide RESTful [REST] services not unlike HTTP [RFC7230], while reducing the complexity of implementation as well as the size of packets exchanged in order to make these services useful in a highly constrained network of highly constrained nodes.

This objective requires restraint in a number of sometimes conflicting ways:

  • reducing implementation complexity in order to minimize code size,

  • reducing message sizes in order to minimize the number of fragments needed for each message (to maximize the probability of delivery of the message), the amount of transmission power needed, and the loading of the limited-bandwidth channel,

  • reducing requirements on the environment such as stable storage, good sources of randomness, or user-interaction capabilities.

Because CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS), the maximum size of resource representations that can be transferred without too much fragmentation is limited. 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) for the transport of larger representations would be possible up to the maximum size of the underlying datagram protocol (such as UDP), but the fragmentation/reassembly process burdens the lower layers with conversation state that is better managed in the application layer.

The present 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 the need for 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 property is not needed, there is no need to create server conversation state in this case, either.)

Block-wise transfers are realized as combinations of exchanges, each of which is performed according to the CoAP base protocol [RFC7252]. Each exchange in such a combination is governed by the specifications in [RFC7252], including the congestion control specifications (Section 4.7 of [RFC7252]) and the security considerations (Section 11 of [RFC7252]; additional security considerations then apply to the transfers as a whole, see Section 7). The present specification minimizes the constraints it adds to those base exchanges; however, not all variants of using CoAP are very useful inside a block-wise transfer (e.g., using Non-confirmable requests within block-wise transfers outside the use case of Section 2.8 would escalate the overall non-delivery probability). To be perfectly clear, the present specification also does not remove any of the constraints posed by the base specification it is strictly layered on top of. For example, back-to-back packets are limited by the congestion control described in Section 4.7 of [RFC7252] (NSTART as a limit for initiating exchanges, PROBING_RATE as a limit for sending with no response); block-wise transfers cannot send/solicit more traffic than a client could be sending to / soliciting from the same server without the block-wise mode.

In some cases, the present specification will RECOMMEND that a client perform a sequence of block-wise transfers "without undue delay". This cannot be phrased as an interoperability requirement, but is an expectation on implementation quality. Conversely, the expectation is that servers will not have to go out of their way to accommodate clients that take considerable time to finish a block-wise transfer. For example, for a block-wise GET, if the resource changes while this proceeds, the entity-tag (ETag) for a further block obtained may be different. To avoid this happening all the time for a fast-changing resource, a server MAY try to keep a cache around for a specific client for a short amount of time. The expectation here is that the lifetime for such a cache can be kept short, on the order of a few expected round-trip times, counting from the previous block transferred.

In summary, this specification adds a pair of Block options to CoAP that can be used for block-wise transfers. Benefits of using these options include:

  • Transfers larger than what can be accommodated in constrained-network link-layer packets can be performed in smaller blocks.

  • No hard-to-manage conversation state is created at the adaptation layer or IP layer for fragmentation.

  • The transfer of each block is acknowledged, enabling individual retransmission if required.

  • Both sides have a say in the block size that actually will be used.

  • The resulting exchanges are easy to understand using packet analyzer tools, and thus quite accessible to debugging.

  • If needed, the Block options can also be used (without changes) to provide random access to power-of-two sized blocks within a resource representation.

A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, see Section 4.6 of [RFC7252]. Even though the options are Critical, a server may decide to start using them in an unsolicited way in a response (Block2) to a request that did not contain a Block option.

Last updated on