Constrained Application Protocol (CoAP)
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained networks in the Internet of Things.
The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.
It enables those constrained devices called “nodes” to communicate with the wider Internet using similar protocols.
CoAP is designed for use between devices on the same constrained network (e.g., low-power, lossy networks), between devices and general nodes on the Internet, and between devices on different constrained networks both joined by an internet.
CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.
What is CoAP Protocol exactly?
CoAP is a service layer protocol that is intended for use in resource-constrained internet devices, such as wireless sensor network nodes.
CoAP is designed to easily translate to HTTP for simplified integration with the web, while also meeting specialized requirements such as multicast support, very low overhead, and simplicity.
Multicast, low overhead, and simplicity are extremely important for Internet of Things (IoT) and Machine-to-Machine (M2M) devices, which tend to be deeply embedded and have much less memory and power supply than traditional internet devices have. Therefore, efficiency is very important.
CoAP can run on most devices that support UDP or a UDP analogue. From a developer point of view, CoAP feels very much like HTTP. Obtaining a value from a sensor is not much different from obtaining a value from a Web API.
Since HTTP and CoAP share the REST model, they can easily be connected using application-agnostic cross-protocol proxies. A Web client may not even notice that it just accessed a sensor resource.
See also: MQTT and HTTP : Comparison between two IoT Protocols
Functions of CoAP (CoAP IoT)
Like HTTP, CoAP can carry different types of payloads, and can identify which payload type is being used. CoAP integrates with XML, JSON, CBOR, or any data format of your choice.
The Internet of Things will need billions of nodes, many of which will need to be inexpensive. CoAP has been designed to work on microcontrollers with as low as 10 KiB of RAM and 100 KiB of code space.
CoAP is designed to use minimal resources, both on the device and on the network. Instead of a complex transport stack, it gets by with UDP on IP.
A 4-byte fixed header and a compact encoding of options enables small messages that cause no or little fragmentation on the link layer.
Many servers can operate in a completely stateless fashion. The Internet of Things cannot spread as long as it can be exploited by hackers willy-nilly.
CoAP does not just pay lip service to security, it actually provides strong security.
CoAP’s default choice of DTLS parameters is equivalent to 3072-bit RSA keys, yet still runs fine on the smallest nodes.
The smallest CoAP message is 4 bytes in length, if omitting Token, Options and Payload. CoAP makes use of two message types, requests and responses, using a simple, binary, base header format.
The base header may be followed by options in an optimized Type-Length-Value format. CoAP is by default bound to UDP and optionally to DTLS, providing a high level of communications security.
Any bytes after the headers in the packet are considered the message body. The length of the message body is implied by the datagram length. When bound to UDP, the entire message must fit within a single datagram.
See also: MQTT and HTTP : Comparison between two IoT Protocols
CoAP Protocol Applications
In many CoAP application domains it is essential to have the ability to address several CoAP resources as a group, instead of addressing each resource individually (e.g. to turn on all the CoAP-enabled lights in a room with a single CoAP request triggered by toggling the light switch).
To address this need, the IETF has developed an optional extension for CoAP in the form of an experimental RFC: Group Communication for CoAP – RFC 7390. This extension relies on IP multicast to deliver the CoAP request to all group members.
The use of multicast has certain benefits such as reducing the number of packets needed to deliver the request to the members.
However, multicast also has its limitations such as poor reliability and being cache-unfriendly.
An alternative method for CoAP group communication that uses unicasts instead of multicasts relies on having an intermediary where the groups are created.
Clients send their group requests to the intermediary, which in turn sends individual unicast requests to the group members, collects the replies from them, and sends back an aggregated reply to the client.
Although the protocol standard includes provisions for mitigating the threat of DDoS amplification attacks these provisions are not implemented in practice.
The protocol supports the caching of responses in order to efficiently fulfill requests. Simple caching is enabled using freshness and validity information carried with CoAP responses. A cache could be located in an endpoint or an intermediary.
See also: MQTT and CoAP: IoT Developers dilemma
Conclusion
As CoAP was designed according to the REST architecture [REST], and thus exhibits functionality similar to that of the HTTP protocol, it is quite straightforward to map from CoAP to HTTP and from HTTP to CoAP.
Such a mapping may be used to realize an HTTP REST interface using CoAP or to convert between HTTP and CoAP. Some messages do not require an acknowledgement.
This is particularly true for messages that are repeated regularly for application requirements, such as repeated readings from a sensor where eventual success is sufficient.
CoAP servers generally reply to a request packet with a response packet. This response packet may be significantly larger than the request packet.
An attacker might use CoAP nodes to turn a small attack packet into a larger attack packet, an approach known as amplification.
There is therefore a danger that CoAP nodes could become implicated in denial-of-service (DoS) attacks by using the amplifying properties of the protocol: an attacker that is attempting to overload a victim but is limited in the amount of traffic it can generate and use amplification to generate a larger amount of traffic.
See also: Understanding IP, TCP, UDP protocols. Difference between TCP and UDP
Let us know what you think about” CoAP Protocol in IoT” in the comment section below.
If you like this article subscribe our YouTube Channel for IoT video Tutorials. You can also find us on Twitter, Facebook, and Instagram for more updates.
