Constrained Application Protocol
Internet protocol suite |
---|
Application layer |
Transport layer |
Internet layer |
Link layer |
Constrained Application Protocol (CoAP) is a specialized Internet Application Protocol for constrained devices, as defined in RFC 7252. 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.
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.[1][2] 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.
The Internet Engineering Task Force (IETF) Constrained RESTful Environments Working Group (CoRE) has done the major standardization work for this protocol. In order to make the protocol suitable to IoT and M2M applications, various new functionalities have been added. The core of the protocol is specified in RFC 7252; important extensions are in various stages of the standardization process.
Features
The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) 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.
The CoRE group has designed CoAP with the following features in mind:
- Overhead and parsing complexity.
- URI and content-type support.
- Support for the discovery of resources provided by known CoAP services.
- Simple subscription for a resource, and resulting push notifications.
- Simple caching based on max-age.
The mapping of CoAP with HTTP is also defined, allowing proxies to be built providing access to CoAP resources via HTTP in a uniform way.[3]
With the introduction of CoAP, a complete networking stack of open-standard protocols that are suitable for constrained devices and environments becomes available.[4]
From the architecture point of view, the CoAP server will be installed on the end node, which could be a sensor. On the other hand, the CoAP client should be installed on the controller, which manages several end nodes.
Registration of the meanings behind CoAP Code, Options and Content Type is handled by IANA, shown in
Message formats
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—if any. 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. When used with 6LoWPAN as defined in RFC 4944, messages SHOULD fit into a single IEEE 802.15.4 frame to minimize fragmentation.
CoAP Request/Response Code
The response code takes the form of
Byte | |||||||
---|---|---|---|---|---|---|---|
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
CLASS | CODE |
And in documentation is usually referred to in this format of `<class>`.`<code>`
CoAP Registered Codes
You can find all the latest CoAP registered code in: https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#codes
* Method: 0.XX
- 0 : EMPTY
- 1 : GET
- 2 : POST
- 3 : PUT
- 4 : DELETE
- 5 : FETCH
- 6 : PATCH
- 7 : iPATCH
* Success : 2.XX
- 1 : Created
- 2 : Deleted
- 3 : Valid
- 4 : Changed
- 5 : Content
- 31 : Continue
* Client Error : 4.XX
- 0 : Bad Request
- 1 : Unauthorized
- 2 : Bad Option
- 3 : Forbidden
- 4 : Not Found
- 5 : Method Not Allowed
- 6 : Not Acceptable
- 8 : Request Entity Incomplete
- 9 : Conflict
- 12 : Precondition Failed
- 13 : Request Entity Too Large
- 15 : Unsupported Content-Format
* Server Error : 5.XX
- 0 : Internal Server Error
- 1 : Not Implemented
- 2 : Bad Gateway
- 3 : Service Unavailable
- 4 : Gateway Timeout
- 5 : Proxying Not Supported
* Signaling Codes : 7.XX
- 0 : Unassigned
- 1 : CSM
- 2 : Ping
- 3 : Pong
- 4 : Release
- 5 : Abort
CoAP Message Structure
Byte | Byte | Byte | Byte | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
VER | TYPE | TKL (Token Length) | CoAP Request/Response Code | Message ID | |||||||||||||||||||||||||||
Token (If any in TKL bytes) (Maximum of 8 bytes) | |||||||||||||||||||||||||||||||
Options (If Available) (Options Numbers: https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers) | |||||||||||||||||||||||||||||||
1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | Payload (If Available) |
The CoAP fixed header is the first 4 bytes. This allows for the smallest CoAP messages to be 4 bytes in length, if omitting Token, Options and Payload.
You can easily extract the information from the fixed header in C via these macros:
#define COAP_HEADER_VERSION(data) ( (0xC0 & data[0])>>6 )
#define COAP_HEADER_TYPE(data) ( (0x30 & data[0])>>4 )
#define COAP_HEADER_TKL(data) ( (0x0F & data[0])>>0 )
#define COAP_HEADER_CLASS(data) ( ((data[1]>>5)&0x07) )
#define COAP_HEADER_CODE(data) ( ((data[1]>>0)&0x1F) )
#define COAP_HEADER_MID(data) ( (data[2]<<8)|(data[3]) )
Implementations
Name | Programming Language | Implemented CoAP version | Client/Server | Implemented CoAP features | License | Link |
---|---|---|---|---|---|---|
aiocoap | Python 3 | RFC 7252 | Client + Server | Blockwise Transfers, Observe (partial) | MIT | https://pypi.python.org/pypi/aiocoap |
Californium | Java | RFC 7252 | Client + Server | Observe, Blockwise Transfers, DTLS | EPL+EDL | https://www.eclipse.org/californium |
cantcoap | C++/C | RFC 7252 | Client + Server | BSD | https://github.com/staropram/cantcoap | |
Canopus | Go | RFC 7252 | Client + Server | Core | Apache License 2.0 | https://github.com/zubairhamed/canopus |
CoAP implementation for Go | Go | RFC 7252 | Client + Server | Core + Draft Subscribe | MIT | https://github.com/dustin/go-coap |
CoAP.NET | C# | RFC 7252, coap-13, coap-08, coap-03 | Client + Server | Core, Observe, Blockwise Transfers | 3-clause BSD | https://github.com/smeshlink/CoAP.NET |
CoAPSharp | C#, .NET | RFC 7252 | Client + Server | Core, Observe, Block, RD | LGPL | http://www.coapsharp.com |
CoAPthon | Python | RFC 7252 | Client + Server + Forward Proxy + Reverse Proxy | Observe, Multicast server discovery, CoRE Link Format parsing, Block-wise | MIT | https://github.com/Tanganelli/CoAPthon |
CoAP Shell | Java | RFC 7252 | Client | Observe, Blockwise Transfers, DTLS | Apache License 2.0 | https://github.com/tzolov/coap-shell |
Copper | JavaScript (Browser Plugin) | RFC 7252 | Client | Observe, Blockwise Transfers | 3-clause BSD | https://github.com/mkovatsc/Copper https://addons.mozilla.org/firefox/addon/copper-270430/ |
eCoAP | C | RFC 7252 | Client + Server | Core | MIT | https://gitlab.com/jobol/ecoap |
Erbium for Contiki | C | RFC 7252 | Client + Server | Observe, Blockwise Transfers | 3-clause BSD | http://www.contiki-os.org/ (er-rest-example) |
iCoAP | Objective-C | RFC 7252 | Client | Core, Observe, Blockwise Transfers | MIT | https://github.com/stuffrabbit/iCoAP |
jCoAP | Java | RFC 7252 | Client + Server | Observe, Blockwise Transfers | Apache License 2.0 | https://code.google.com/p/jcoap/ |
libcoap | C | RFC 7252 | Client + Server | Observe, Blockwise Transfers, DTLS | BSD/GPL | https://github.com/obgm/libcoap |
LibNyoci | C | RFC 7252 | Client + Server | Core, Observe, Block, DTLS | MIT | https://github.com/darconeous/libnyoci |
lobaro-coap | C | RFC 7252 | Client + Server | Observe, Blockwise Transfers | MIT | http://www.lobaro.com/lobaro-coap |
microcoap | C | RFC 7252 | Client + Server | MIT | https://github.com/1248/microcoap | |
nCoap | Java | RFC 7252 | Client + Server | Observe, Blockwise Transfers, CoRE Link Format, Endpoint-ID-Draft | BSD | https://github.com/okleine/nCoAP |
node-coap | Javascript | RFC 7252 | Client + Server | Core, Observe, Block | MIT | https://github.com/mcollina/node-coap |
Ruby coap | Ruby | RFC 7252 | Client + Server (david) | Core, Observe, Block, RD | MIT, GPL | https://github.com/nning/coap https://github.com/nning/david |
Sensinode C Device Library | C | RFC 7252 | Client + Server | Core, Observe, Block, RD | Commercial | https://silver.arm.com/browse/SEN00 |
Sensinode Java Device Library | Java SE | RFC 7252 | Client + Server | Core, Observe, Block, RD | Commercial | https://silver.arm.com/browse/SEN00 |
Sensinode NanoService Platform | Java SE | RFC 7252 | Cloud Server | Core, Observe, Block, RD | Commercial | https://silver.arm.com/browse/SEN00 |
SwiftCoAP | Swift | RFC 7252 | Client + Server | Core, Observe, Blockwise Transfers | MIT | https://github.com/stuffrabbit/SwiftCoAP |
TinyOS CoapBlip | nesC/C | coap-13 | Client + Server | Observe, Blockwise Transfers | BSD | http://docs.tinyos.net/tinywiki/index.php/CoAP |
txThings | Python (Twisted) | RFC 7252 | Client + Server | Blockwise Transfers, Observe (partial) | MIT | https://github.com/mwasilak/txThings/ |
FreeCoAP | C | RFC 7252 | Client + Server + HTTP/CoAP Proxy | Core, DTLS, Blockwise Transfers | BSD | https://github.com/keith-cullen/FreeCoAP |
coap-rs | Rust | RFC 7252 | Client + Server | MIT | https://github.com/Covertness/coap-rs | |
YaCoAP | C | MIT | https://github.com/RIOT-Makers/YaCoAP |
Proxy implementations
- Squid 3.1.9 with transparent HTTP-CoAP mapping module http://telecom.dei.unipd.it/pages/read/90/
- jcoap Proxy https://code.google.com/p/jcoap/
- Californium cf-proxy https://github.com/mkovatsc/Californium
- CoAPthon https://github.com/Tanganelli/CoAPthon
- FreeCoAP https://github.com/keith-cullen/FreeCoAP
CoAP group communication
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[5] 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.[6]
See also
References
- ↑ RFC 7252, Constrained Application Protocol (CoAP)
- ↑ "Integrating Wireless Sensor Networks with the Web" , Walter, Colitti 2011
- ↑ RFC 8075, Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)
- ↑ IETF Standardization in the Field of the Internet of Things (IoT): A Survey
- ↑ RFC 7390, Group Communication for CoAP
- ↑ "Flexible Unicast-Based Group Communication for CoAP-Enabled Devices" , Ishaq, I.; Hoebeke, J.; Van den Abeele, F.; Rossey, J.; Moerman, I.; Demeester, P. Sensors 2014