# Constrained Application Protocol

HTTP is a widely used web protocol but it's not suited for the Internet-of-Things (IoT). IoT is composed of constrained nodes running on 8-bit microcontrollers with small amounts of ROM and RAM. IoT networks have low bandwidth and low availability. IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs), used in IoT, often have high packet error rates and a typical throughput of tens of kilobits per second. Given these constraints, IETF's CoRE (Constrained RESTful Environments) Working Group defined Constrained Application Protocol (CoAP).

Whereas HTTP packets might take up thousands of bytes, CoAP packets are only tens of bytes. CoAP handshaking is also lighter since it uses UDP instead of TCP. CoAP focuses on being lightweight and cost effective. It supports networks with billions of nodes. CoAP uses the REST (Representational State Transfer) architectural style.

## Discussion

• What are the main features of CoAP?

Since IoT uses the internet, CoAP has been designed very much in the spirit of HTTP that powers the internet. Like HTTP, CoAP is a document transfer protocol. A client requests a resource at a URI (Uniform Resource Identifier) and the server responds. Moreover, RESTful principles are followed; verbs GET, POST, PUT, DELETE are used. Protocol is indicated with coap://.

Where CoAP differs from HTTP is that UDP is used for transport instead of TCP. UDP handshaking is lighter and easier to implement on microcontrollers. CoAP header is only 4 bytes. CoAP can also use UDP's broadcast and multicast features. CoAP communication is using connectionless datagrams. Because datagrams are used, SMS and other packet-based protocols may be used. CoAP uses a subset of MIME types and HTTP response codes. There's also a built-in discovery mechanism. For security, Datagram TLS (DTLS) is used.

Since there's no TCP, CoAP takes care of message acknowledgements, retries with congestion control and duplicate detection. To keep things simple, these features are optional.

• Could you describe the architecture of CoAP?

The CoAP protocol is closely aligned to the traditional web stack based on HTTP. UDP is used instead of TCP at the transport layer. CoAP uses binary encoding unlike the textual encoding of HTTP but otherwise both are based on RESTful APIs and request-response method. This one-to-one mapping between the two stacks makes it possible to interwork the two protocols via a proxy. Within the constrained network, CoAP is used but elsewhere CoAP messages can be translated into HTTP. Such proxies may reside in the edge of a cloud. It's also possible to bypass such a proxy and deploy CoAP end to end if cloud platforms support this.

We can also think of CoAP as being composed of two logical sub-layers: a lower messaging layer to deal with UDP and asynchronous interactions; an upper request/response layer that deals with the semantics using message codes and response codes.

• What's a typical message flow in CoAP?

It may be tempting to think of sensor nodes as CoAP clients but in fact they are typically CoAP servers. But they could also be CoAP clients consuming information available at other devices on the network. In a typical CoAP flow, clients discover resources available at the server by asking for URI path GET /.well-known/core. Server will reply with content of type application/link-format. Now that the client knows what resources are available, it can request the content of a specific resource (such as temperature) by calling GET /temperature. Server will respond with the value of that resource.

CoAP specifies four message types: Confirmable (CON), Non-confirmable (NON), Acknowledgement (ACK), and Reset (RST). Requests and responses are carried as part of these message types. If reliable transmission is required, CON and ACK are used with timeout and exponential back-off. If unreliable transmission in sufficient, then NON is used. When ACK is used, response may be piggybacked with ACK or sent separately in a CON.

• Where should I use CoAP?

If you have an existing system that is web service-based, then adding in CoAP is a good option. It's good in resource-constrained environments: energy-limited devices, low-bandwidth links, and lossy or congested networks. On congested networks, CoAP/UDP would work but MQTT/TCP may not even manage a complete handshake. CoAP can be used where broadcast and multicast is needed.

CoAP is suited for building something where a device is deployed in "report only" mode. Once deployed, device simply reports data back to a server. Information appliance, control equipment and communication equipment in Smart Home networks need to be low cost and lightweight. Thus, CoAP is suitable for home communication networks.

When deploying on third-party networks where we don't have control over firewalls and blocked ports, CoAP may not be suitable. In this case, HTTP/REST is a good option. Since sensor nodes are CoAP servers, there could be issues with Network Address Translation (NAT). LWM2M, which is based on CoAP, overcomes this by requiring clients to send a probe packet first so that router can make the association. Although CoAP does not require IPv6, it's easiest to deploy on IP networks.

• What's the security protocol used for CoAP?

CoAP uses Datagram Transport Layer Security (DTLS) for security. The DTLS-secured CoAP protocol is termed CoAPs. DTLS is based on PSK, RPK and certificate security. There are three main elements when considering security, namely integrity, authentication and confidentiality. DTLS can achieve all of them. DTLS solves two problems: reordering and packet lost. It adds three implements:

• Packet retransmission
• Assigning sequence number within the handshake
• Replay detection

Unlike network layer security protocols, DTLS in application layer protects end-to-end communication. No end-to-end communication protection will make it easy for attacker to access to all text data that passes through a compromised node. DTLS also avoids cryptographic overhead problems that occur in lower layer security protocols.

It's been shown that DTLS adds 11% overhead compared to communication without any security. Moreover, since DTLS is error tolerant, it's more vulnerable to be hacked compared to using TLS.

• What are the alternatives to CoAP for IoT messaging?

Among the alternatives to CoAP are Data Distribution Service (DDS), Advanced Message Queuing Protocol (AMQP), MQTT, HTTP/REST, and eXtensible Messaging and Presence Protocol (XMPP). DDS is from Object Management Group. AMQP and MQTT are OASIS standards. XMPP is defined by IETF.

DDS offers a rich set of QoS and can prioritize traffic based on content. It can use either TCP or UDP. It's model is also flexible: publish-subscribe (like MQTT) or request-response (like CoAP).

A study comparing these protocols concluded that MQTT and RESTful HTTP are popular, possibly because they are stable and mature. MQTT is suitable for constrained devices and RESTful HTTP can fit into fog and cloud computing systems. CoAP is also gaining maturity.

• In terms of performance, how does CoAP compare against its alternatives?

A survey that studied the performance of different messaging protocols concluded that CoAP and MQTT show best latency performance. CoAP performs better for high packet losses. CoAP messages can be transferred three times faster than HTTP messages. However, when comparing HTTP/2 with CoAP, HTTP/2 performed better in high congestion scenarios.

CoAP required less bandwidth compared to MQTT. In a network under heavy load, CoAP used less bandwidth than MQTT whereas DDS took up twice the bandwidth of MQTT. CoAP also had higher efficiency, calculated as a ratio of useful information bytes to total bytes at application and transport layers.

In terms of energy consumption, both MQTT and CoAP are efficient.

We should note that MQTT is based on TCP. There's also a variant of MQTT called MQTT-SN that runs on UDP. Comparing CoAP against MQTT-SN may be more appropriate. Likewise, CoAP running on top of TCP (RFC 8323) can be compared against MQTT.

• Could you compare some implementations of CoAP?

There are plenty of open source implementations of CoAP. In Java, we have Californium and jCoAP. In C we have, Erbium, libCoAP, and OpenCoAP. Some OS support CoAP: mbed, TinyOS and Contiki. When looking at implementations, we need to consider if it's for client or server; for constrained devices or server side; for browsers; or for smartphones. Carsten Bormann maintains a rich list of CoAP implementations. A similar list is available on Wikipedia.

A comparison of some implementations in C, Java, JavaScript and Python has looked at feature support, targeted platforms and developer usability. It found that CoAPy did not interoperate with any other implementation. On the server side, C implementations (libcoap, smcp and microcoap) are fast. It also compared CPU and memory usage. For example, sharedlib/client/server ROM in bytes are 296K/33K/22K for libcoap and 383K/23K/18K for smcp. Peak RAM usage for C implementations is typically 3.2KB.

• What are CoAP standards that developers must read?

Among the standards relevant to CoAP are the following:

• RFC 7252: This is main CoAP standard.
• RFC 7959: CoAP is for transferring small payloads but if firmware upgrades are needed block-wise transfers option becomes useful. Information blocks are sent without maintaining any state.
• RFC 7641: What if we want to get notified when resource state changes on the CoAP server? This will save clients from polling the server on a regular basis. Observing resources is an option that makes this possible.
• RFC 8323: CoAP over UDP supports reliable delivery, simple congestion control and flow control. What if we want reliable transport? This RFC talks about CoAP over TCP, TLS and WebSockets.
• RFC 6690: Defines a simple format for exposing resources as a basis for a resource directory.
• RFC 7390: Using the multicast feature of CoAP, this RFC details how to use CoAP for group communication.

Latest developments of the CoRE Working Group are on IETF website. CoRE parameters, including CoAP method and response codes, are registered with IANA. IANA has assigned port numbers 5683 and 5684 for CoAP and CoAPs.

• What are some useful resources for CoAP developers?

For interoperability testing, coap.me is useful. Wireshark v1.12 has support to decode CoAP packets. To translate CoAP to HTTP and vice versa, such as done on a proxy, crosscoap can be used. There's also a handy CoAP cheatsheet.

## Milestones

Jun
2014

Internet Engineering Task Force (IETF) standardizes the Constrained Application Protocol (CoAP) as RFC 7252.

Oct
2014

OASIS approves MQTT Version 3.1.1 as an OASIS Standard.

Feb
2015

Internet Engineering Steering Group (IESG) approves HTTP/2 as a proposed standard.

Feb
2017

Using CoAP as the underlying stack, Lightweight Machine to Machine (LWM2M) technical standard is approved by Open Mobile Alliance. LWM2M defines interfaces Bootstrap, Client Registration, Device management and service enablement, and Information Reporting. It gives details on resource identifiers, security procedures, and transport layer binding and encodings.

Feb
2018

IETF publishes RFC 8323 titled "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets" as a Proposed Standard.

Apr
2018

Eclipse Foundation publishes results of a survey on IoT developers. For messaging, more than 60% of respondents use MQTT. CoAP is in the fifth place with only 20% of respondents using it.

Author
No. of Edits
No. of Chats
DevCoins
3
1
1411
6
0
372
12
0
305
1895
Words
4
Likes
7832
Hits

## Cite As

Devopedia. 2019. "Constrained Application Protocol." Version 21, September 23. Accessed 2022-09-23. https://devopedia.org/constrained-application-protocol
Contributed by
3 authors

Last updated on
2019-09-23 11:40:48
• Datagram Transport Layer Security
• MQTT