Constrained Application Protocol (CoAP)

According to RFC7252, the Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes (e.g., sensors) and constrained networks (e.g., low-power, lossy). The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks (such as 6LoWPAN) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine (M2M) applications, such as smart energy and building automation.

Why do we need CoAP? HTTP is based on the Representational State Transfer (REST) architecture that makes resources available via unique uniform resource identifiers (URIs). While HTTP is a powerful protocol, it is expensive in terms of implementation code space and network resource usage. HTTP's evolution has resulted in a protocol with high implementation baggage that overwhelms small devices.

IETF's Constrained RESTful Environment (CoRE) working group aims to make the REST paradigm available for devices and networks that are too constrained to use HTTP. The CoRE working group is responsible for defining CoAP, which provides the same basic set of services in a very frugal manner.

HTTP headers incur too much overhead. At the core of CoAP's reduced complexity is the use of UDP instead of TCP. TCP's performance degrades over lossy links and it has no multicast support. Also, using UDP binding avoids TCP handshake overhead.

Within UDP packets, CoAP uses a four-byte binary header followed by a sequence of options (each with a one-byte header, extensible to two bytes for longer options value). This header is compact and easy to parse, enabling a total header size of 10 - 20 bytes for a typical request. Option types provides for future extensibility needs without burdening the simple implementation.

The REST architecture makes it possible for CoAP to interwork with HTTP, which is accomplished through the use of proxies. A proxy is an intermediary specifically configured on a client. A gateway acts as if it were the origin server. It is possible to build intermediaries that speak CoAP on one side and HTTP on the other without encoding specific application knowledge. New applications can be deployed without upgrading the intermediaries.

Like HTTP, CoAP identifies a resource using URI (coap://URI). Existing HTTP end points might be unaware of CoAP's URI scheme. A reverse-proxy-style intermediary can make a set of CoAP resources to look like regular http or https URIs so that older Web clients can access CoAP servers transparently.

In HTTP, TCP handles packet fragmentation by slicing large payloads into multiple packets and ensuring they arrive and are reassembled in the right order. CoAP takes a different approach - it adds a pair of "Block" option and transfers multiple blocks of information from a resource representation in multiple request-response pairs. This option allows the server to be stateless — the server handles each block transfer separately without needing a connection set up or memory of previous block transfers.

In HTTP, clients always initiate the transactions by using the GET operation. If a client wants to be kept updated about a resource status, it repeatedly executes the GET operation. This approach is expensive in a constrained environment, where nodes need to be in sleep mode most of the time.

CoAP uses an approach known as observation, where the client specifies the "Observe" option in a GET request to indicate interest to receive updates from a resource. If the server accepts this option, the client becomes an observer of the resource and receives an asynchronous notification message each time it changes. Each notification has identical structure to the response of the initial GET request.

In an environment of autonomous devices and embedded systems (M2M environment), it is even more important that there is a uniform, interoperable resource discovery. To ensure interoperability between end points, CoAP defines a technique for discovering and advertising resource descriptions. Because the descriptions are machine-interpreted, the description format is standardized.

CoAP servers provide a resource description using the well-known URI, i.e., /.well-known/core, for resource discovery. Clients access the description using a GET request.

For security purposes, HTTP is used with the Transport Layer Security (TLS) protocol. Likewise, CoAP is implemented on top of the Datagram Transport Layer Security (DTLS).

Other main features CoAP are:

• In addition to the GET operation, the other three operations are POST, PUT and DELETE. There are three types of responses, namely 2.xx (success), 4.xx (client error) and 5.xx (server error).

• There are four message types: Confirmable, Non Confirmable, Acknowledgement and Reset (i.e, Nack). Confrmable, Acknowledgement and Reset messages are use to provide reliable communications over UDP. Non Confirmable messages do not require acknowledgements.
• Support for unicast and multicast requests. Multicast requests are used to query several similar devices simultaneously.
• Simple proxy and caching capabilities.

CoAP is designed to provide simple, low overhead and machine-to-machine (M2M) communications that are required to enable the interaction and management of embedded devices. It takes a platform-independent approach that facilitates the integration of the embedded network with existing Web technologies, which makes it attractive for users and developers.

CoAP is likely to play an important role in supporting IoT applications. Because CoAP incurs lower overhead, it is more energy efficient than HTTP, and therefore, more suitable for embedded wireless networks. Combining EXI compression with CoAP makes it even more energy efficient compared to XML/CoAP combination.

The use of UDP makes it easier for CoAP to meet tighter delay requirements than HTTP. Despite using UDP, reliable communications can be achieved by implementing additional end-to-end reliability mechanisms.

Source:

• RFC7252: The Constrained Application Protocol (CoAP)
• C. Bormann, A.P. Castellani, Z. Shelby, "CoAP: An Application Protocol for Billions of Tiny Internet Nodes", IEEE Internet Computing, Vol. 16 Issue 2, March-April, 2012
• B.C.Villaverde, D. Persch, RD.P. Alberola, S. Fedor, M. Boubekeur, "Constrained Application Protocol for Low Power Embedded Networks: A Survey", Proc. of the 2012 Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing, 4-6 July, 2012