CoAP is taking the place of older, ‘heavy’ protocols and helping bring the promise of the internet of things to constrained, low-power devices.
22 June 2016, by Sally Johnson, TechTarget – Bringing the web to constrained devices that lack the capabilities of computers or smartphones requires a special sort of IoT protocol, and CoAP is one such protocol that fits that bill.
A newer protocol than most, the Internet Engineering Task Force (IETF) standardized the Constrained Application Protocol or CoAP as RFC 7252 in 2014 — essentially as HTTP designed specifically for constrained devices.
The Constrained Application Protocol was necessary because traditional protocols are considered “too heavy” for IoT applications involving constrained devices. Networks of IoT end nodes tend to be “lossy,” but the low-power devices that rely on them are expected to continue functioning — powered by batteries or energy harvesting — for many years and need to expend as little energy as possible.
CoAP is a software protocol that enables simple constrained “things” such as low-power sensors and actuators to communicate interactively via the internet. It runs on devices that support the User Datagram Protocol (UDP), and implements a lightweight” application layer that features small message sizes, message management and lightweight message overhead ideally suited for low-power, low-memory devices.
The IoT realm is widely using CoAP as a protocol for home automation and in numerous industrial applications. It’s also used for managing devices using The Open Mobile Alliance’s (OMA) Lightweight Machine-to-Machine (LWM2M) protocol, and other organizations — including The Open Connectivity Foundation and ZigBee — are tapping CoAP as a core protocol for their frameworks and product implementations.
To keep pace with the Cambrian-like explosion of growth of connected “things” ahead, an IoT protocol designed specifically for constrained devices, such as CoAP, has a critical role to play.
Sierra Wireless, among the early adopters, is using CoAP for its IoT cloud. “We’re mainly using it to connect legato.io-based devices to our cloud using OMA LWM2M, which is based on CoAP,” said Julien Vermillard, principal engineer of software development for Sierra Wireless.
There are myriad other IoT applications for CoAP, and Chris Matthieu, director of IoT engineering at Citrix Octoblu, is seeing it “most commonly used for low-bandwidth scenarios such as satellite communication and smaller energy-efficient sensors.”
CoAP vs. other IoT protocols
When designing the Constrained Application Protocol, IETF’s goal was to ensure that it would scale well and offer extensibility — and it does, thanks to the communication paradigm it’s based upon.
Other IoT protocols include well-known HTTP, WebSocket, Extensible Messaging and Presence Protocol (XMPP) and MQ Telemetry Transport (MQTT) — most of which have been around for at least a decade or two.
Some of these other protocols still do remote procedure calls or promote plain publish/subscribe like MQTT, according to Carsten Bormann and Jaime Jimenez, chairs of IETF’s Constrained RESTful Environments (CoRE) Working Group.
While at first glance these other alternatives often sound appealing, “they scale poorly and don’t offer the extensibility of RESTful-based ones like CoAP,” Bormann and Jimenez pointed out.
It’s important to note that CoAP and other IoT protocols can play nicely together. Matthieu is seeing a shift to CoAP for controlling drones and streaming live sensor data for agriculture IoT applications, and “both of these use cases depend more on energy efficiency and faster communications than the guaranteed delivery of messages,” he noted. Octoblu’s platform “allows CoAP devices to ‘talk’ to MQTT, HTTP, WebSocket, XMPP and AMQP devices — and vice versa — so it’s easy to mix and match devices and protocols based on the requirements of each use case.”
Ultimately, since CoAP uses the well-known web RESTful model for constrained devices and networks, “it’s best suited for applications in which the device is kept as dumb as possible — only exposing sensors’ values and actuator endpoints,” Vermillard said.
Key CoAP benefits
One of the main benefits provided by the Constrained Application Protocol is that the protocol is designed to seamlessly map to existing web protocols such as HTTP, according to Bormann and Jimenez. It also “provides simple resources discovery, security, and maintains key concepts used on the web such as uniform resource identifiers, methods and media types,” they said. Perhaps as important, “it’s very simple and based on RESTful.”
Being able to send many messages quickly is something that can come in handy. One of Octoblu’s developers used CoAP to control a robot at a BattleBot competition and was able to send three times more messages to his robot than the other competitors were able to do — ultimately allowing him to win the competition.
Constrained Application Protocol security
IETF designed CoAP to “derive its full-strength security from using Datagram Transport Layer Security (DTLS), a version of the same protocol Transport Layer Security (TLS) that secures the big web — without compromising on the security parameters,” Bormann and Jimenez said.
Since CoAP security is based on the solid DTLS standard, Vermillard said he isn’t concerned. “If you want a key management mechanism on top of CoAP, it can be handled by LWM2M,” he added.
For additional security, Octoblu chose to implement its REST API into each protocol supported. “Our CoAP API relies on device unique identifiers (UUIDs) and secret tokens,” Matthieu explained. “This is the same practice as our HTTP REST API. Octoblu’s IoT role management subsystem allows you to specify which UUIDs have access to discover, subscribe, message or configure other UUIDs.”
The Constrained Application Protocol does have some rather interesting quirks regarding encrypting traffic, as Matthieu pointed out. Since CoAP is an UDP-based protocol, unlike other IoT protocols, it can’t use TLS encryption. “CoAP must use DTLS, which is intentionally similar to TLS,” he said. “Except that DTLS has to solve two problems: packet loss and reordering. DTLS implements packet retransmission, assigning sequence number within the handshake and replay detection.” See RFC 6347 for details.
CoAP evolving rapidly
As with all new protocol deployments, work is underway to continue improving CoAP. IETF’s future CoAP work includes “new security modes other than DTLS, group communication, management and interaction models,” Bormann and Jimenez said. IETF’s CoRE working group is tackling these issues and participation is encouraged.
In terms of issues encountered by early adopters of the Constrained Application Protocol, Vermillard cautioned that CoAP transmission facilities can be a bit of a performance hog. “So be careful and performance-test your CoAP application with high packet loss to avoid discovering issues later,” he advised.
A CoAP-related challenge Octoblu ran into with its IoT stack, which is currently running in Amazon Web Services, is that AWS’ Elastic Load Balancing service works great for supporting IPv6 for TCP traffic — but not UDP. “To extend IPv6 support to CoAP, we deployed a UDP-based IPv6 service outside of AWS,” Matthieu noted. “While supporting CoAP had some initial challenges … it’s a very modern IoT protocol with many new benefits.”