Constrained Application Protocol
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol, as defined in RFC 7252, 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.
Features
The work on Constrained Environments aims at realizing the REST architecture in a suitable form for the most constrained nodes and networks. The nodes usually consist of 8-bit microcontrollers with limited amounts of RAM and ROM.
CoAP has the following main features:
- Web protocol fulfilling M2M requirements in constrained environments
- UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests
- Asynchronous message exchanges
- Low header overhead and parsing complexity
- URI and Content-type support
- Simple proxy and caching capabilities
- Stateless HTTP mapping
- Security binding to Datagram Transport Layer Security (DTLS)
The Protocol
CoAP is similar to the client/server model of HTTP. M2M interactions typically result in a CoAP implementation acting in both client and server roles. A request is sent by a client to request an action on a resource (identified by a URI) on a server. The server then sends a response with a response code (equivalent to that of HTTP). Therefore, efficiency is very important, so CoAP uses UDP, a datagram-oriented transport.
CoAP is however a single protocol, with messaging and request/response as just features of the CoAP header
+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+
Message Format
By default, the messages are encoded in a simple binary format and transported over UDP. The message format starts with a fixed-size 4-byte header, followed by a variable-length Token value, which can be between 0 and 8 bytes long. Following the Token value comes a sqeu
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| T | TKL | Code | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (Ver) (2 bits) Indicates the CoAP Version number. This must set this field to 1 (binary 01). Other values are reserved for future versions.
Type (T) (2 bits) Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).
Token Length (TKL) (4 bits) Indicates the length of the variable-length Token field, which may be 0-8 bytes in length.
CoAP Request/Response Code (8 bits) Splits into a 3-bit class and 5-bit detail.
Message ID (16 bits) Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable.
Courses
References
- RFC 7252: https://tools.ietf.org/html/rfc7252
- CoAP: RFC 7252 Constrained Application Protocol https://coap.technology/
- Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/