A core part of Cisco’s Internet of Everything narrative is the Internet of Things—what we view as the latest wave of the Internet – connecting physical objects in ways that help us analyze and control our environment to provide better safety, comfort, and efficiency.
This is not a new concept—RFID was introduced in the late 1960s—but it has reached a tipping point for IP connectivity, driven by advances in sensor technology, IPv6, and electronics miniaturization.
Amid this move toward IP, Cisco is continuing its long-standing participation in OASIS (Organization for the Advancement of Structured Information Standards) by participating in the effort to produce an MQTT standard.
So where does MQTT fit in with other popular IoT messaging stacks that Cisco is helping to develop?
- CoAP (Constrained Application Protocol) over UDP is used for resource constrained, low-power sensors and devices connected via lossy networks, especially when there is a high number of sensors and devices within the network. Soon to be released as a suite of IETF RFCs, CoAP has already found success as a key enabling technology for electric utility AMI (advanced metering infrastructure) and DI (distributed intelligence) applications within Cisco’s Field Area Network.
- XMPP (Extensible Messaging and Presence Protocol) has its roots in instant messaging and is a contender for mass scale management of consumer white goods, such as washers, dryers, refrigerators, and so on. But because it assumes a persistent TCP connection and lacks an efficient binary encoding, it’s typically not been practical over LLNs (Low-power and Lossy Networks). But the recent work of XEP-0322, XEP-323, and XEP-324 aim to make XMPP suited for IoT.
- RESTful HTTP over TCP is particularly attractive for connecting consumer premise devices, given the near universal availability of HTTP stacks for various platforms. The RESTful HTTP approach has found success in smaller scale LLNs requiring message latencies of several seconds (home energy management, etc.).
The table below explains how we view the IoT protocol landscape.
| Protocol | CoAP | XMPP | RESTful HTTP | MQTT |
| Transport | UDP | TCP | TCP | TCP |
| Messaging | Request/Response | Publish/Subscribe Request/Response | Request/Response | Publish/Subscribe Request/Response |
| 2G, 3G, 4G Suitability (1000s nodes) |
Excellent | Excellent | Excellent | Excellent |
| LLN Suitability (1000s nodes) |
Excellent | Fair | Fair | Fair |
| Compute Resources |
10Ks RAM/Flash | 10Ks RAM/Flash | 10Ks RAM/Flash | 10Ks RAM/Flash |
| Success Storied | Utility Field Area Networks | Remote management of consumer white goods | Smart Energy Profile 2 (premise energy management/home services) | Extending enterprise messaging into IoT applications |
Connecting sensors and objects opens up an entirely new world of possible use cases—and it’s precisely those use cases that will determine when to use the right protocols for the right applications.
I would like you to include AMQP as well in the comparison. I would like to see how it stacks with the others.
I would like to see AMQP added as well.
Hello Paul
Interesting post. It has attracted some attention, for instance in this thread:
http://www.linkedin.com/groupItem?view=&gid=108418&item=239593910&type=member&commentID=138229614&trk=hb_ntf_COMMENTED_ON_GROUP_DISCUSSION_YOU_COMMENTED_ON
As part of this discussion, I found that the comparisons you’ve made in your blog piece would do good to include a couple of important categories: (Part of a longer response in a longer discussion.)
Security (securing against attacks and exploits):
CoAP: MEDIUM. It has security mechanism, but they are optional. [2]
XMPP: HIGH. Encryption + Client Authentication + Client Authorization mandatory. It is the only solution that has a Client Authorization mechanism. The others cannot implement this, even if they do it as an application specific extension. The protocols simply do not allow it.
REST/HTTP: MEDIUM. It has security mechanism, but they are optional.
MQTT: Low. Sends passwords in clear text. The SSL/TLS solution does not remote the man-in-the-middle attack threat, making it possible to extract passwords in clear text even if communication is encrypted. Since it is done for constrained devices, the probability that safeguards against this is implemented is low.
Provisioning (Configuring IoT networks):
CoAP: Low. No privisioning support is defined for CoAP.
XMPP: HIGH: Ability for operators to provision who can talk to who, what they can see or do, what services are accessible to whom, etc, is available through XEP.0324 [3].
REST/HTTP: Low. Non-existant.
MQTT: Low. Non-existant.
Interoperability (Making things from different vendors understand each other):
CoAP: Low. Content is binary, and proprietary. To make things interoperate, further work has to be done. Limited such work is available in the SENML initiative, but it covers only a very small fraction of use cases for IoT.
XMPP: HIGH. Through XEP-0323 (Sensor Data) [4], XEP-0325 (Control) [5] and XEP-0326 (Concentrators) [6] important use cases for interoperability has already been defined. More extensions in this field is being worked on, and will be published shortly.
REST/HTTP: Low. Non-existant.
MQTT: Low. Non-existant.
So, as a base for Internet of Things, I would say MQTT is a very poor choice. That doesn’t mean it’s a bad protocol or bad technology. It has its obvious advantages, when it comes to transporting and routing messages using a publish/subscribe architecture in secure and controlled environments. I understand why large corporations want to use it, in settings where they control everything, from sensor, gateways, networks, servers, etc. But, it is simply not suited to be a standard for IoT.
Sincerely,
Peter Waher
[1]: http://xmpp.org/extensions/xep-0322.html
[2]: http://datatracker.ietf.org/doc/draft-ietf-core-coap/
[3]: http://xmpp.org/extensions/xep-0324.html
[4]: http://xmpp.org/extensions/xep-0323.html
[5]: http://xmpp.org/extensions/xep-0325.html
[6]: http://xmpp.org/extensions/xep-0326.html
Thanks all for your thoughtful feedback.
@Peter
Some of the comparisons you’ve provided are not quite apples to apples.
Rating CoAP and RESTful approaches as MEDIUM security because they do not inline security details or refer to external specs is a bit of a slippery slope. I can assure you that Cisco is currently deploying million node CoAP based Field Area Networks which implement best-of-breed, standards based, critical-infrastructure-grade security for node authentication, authorization, encryption, etc.
Same point re: provisioning. Zero touch node deployment is built into the Cisco Field Area Networks. One simply can not practically deploy a million node network without this capability.
Interoperability. You have rated most of the options as LOW on the point of payload interoperability. CoAP, HTTP etc are application protocols which, by design, do not specify payload semantics or encoding. That is left to various organizations which will build their interoperability profiles atop these app protocols. A recent example is the Smart Energy Profile 2 specification, which defines a full stack interop profile (based on a RESTful approach) for premises energy management. And Cisco (amongst others) is moving to do same for the FAN within the Wi-SUN Alliance.
Cisco does applaud the XEP work you’ve mentioned re: XMPP support for IoT/M2M. I hope that bears results soon.
@James and Dwight
AMQP got its start as a “wire level” messaging standard (versus, say, JMS … which is API definition) for high speed transaction processing for the financial industry. One could say AMQP long ago supported M2M applications.
All that said, its important to note that there will be no “one size fits all” solution for IoT/M2M. Your technology selections will depend upon the requirements of your application (messaging patterns, network capabilities, security, currently deployed infrastructure, etc).
Hello Paul
Thanks for your response.
And I agree with you: Comparing these protocols is not comparing apples to apples.
Now CoAP, REST & MQTT are all excelent transport protocols, CoAP & REST being request/response, and MQTT being publish/subscribe. Very good transport protocols one might add.
But the topic was IoT-protocols, not transport protocols, and IoT is more than simple transport. It is as you say with regards to CoAP: The rest has to be added on-top. The same applies to REST & MQTT. Of course you can build good IoT applications using these techniques, but it needs skills, which obviously Cisco has.
But it is not sufficient that one large actor has these skills. True IoT interoperability comes when there are standards enabling everybody to publish their devices on the Internet and they can interact with each other seamlessly, regardless of manufacturer.
Therefore, in my opinion, to be a successful “IoT-protocol” you need to solve more than just simple transport. This is what I wanted to illustrate using the additional categories.
BTW, good post and interesting subject.
Actually, the title should have been IoT Application Protocols.
ANY of the options discussed requires application specific addition of payload definitions and encodings to be “added on top” (and this work is indeed underway within various organizations).
Hello Paul.
Actually no. Unless you consider implementing a XEP application specific.
Using the proposed XEP’s and one which is to be published in a couple of weeks (Interoperability), you don’t need a single line of “application specific” code (that is, apart from the XEPs if you consider that application specific) for Things to operate securely with each other, in a multi-vendor, multi-manufacturer, multi-operator open environment (IoT).
And also, apart from being published XMPP extensions (XEPs), which in itself makes them open, they form part of the IEEE/ISO/IEC P21451, which will make them proper standards.
We therefore invite interested parties to partake in this interesting and very important work, to create a proper IoT protocol.
You can preview the interoperability XEP here:
https://github.com/joachimlindborg/XMPP-IoT/
Sincerely,
Peter Waher
@Peter
“Actually no. Unless you consider implementing a XEP application specific.”
I do. They call these (XEP) XMPP Extension Protocols for a reason 😉
“We therefore invite interested parties to partake in this interesting and very important work, to create a proper IoT protocol.”
Implying the others are not? This is not a pragmatic view.
But we are now debating into the noise. Cisco looks forward to the completion of the XEPs we’ve discussed. They will extend the reach of XMPP into more resource constrained applications and networks.
Paul;
Regardign cardinality level for XMPP, Coversant has optimized its platform to allow 240,000 concurrent connections on
2x4core, 16gb mem box, I submit that the level is raised to high in the column.