Cisco Logo


Internet of Everything

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?

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.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 90 days. Please visit the Cisco Blogs hub page for the latest content.

9 Comments.


  1. I would like you to include AMQP as well in the comparison. I would like to see how it stacks with the others.

       1 like

  2. Dwight Wheeler

    I would like to see AMQP added as well.

       0 likes

  3. 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

       0 likes

    • 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).

         0 likes

      • 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.

           0 likes

        • 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).

             0 likes

          • 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

               0 likes

          • @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.

               0 likes

  4. 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.

       0 likes

  1. Return to Countries/Regions
  2. Return to Home
  1. All Internet of Everything
  2. Return to Home