WTF is … Routing Protocol for Low-Power and Lossy Networks?

Billions of sensors need novel routing schemes and the IETF is on the job


Whether you consider the Internet of Things (all the way up to the Internet of Everything) to be the Way of The FutureTM or just This Year's Buzzword® something of an exaggeration, there's a good chance some of you will run into some of its real-world manifestations in the near future.

After all, the building you work in is already wired up with sensors and right now, they're using proprietary protocols that make them hard to wire into applications. The industry's long-term vendor vision is that these critters will soon all be talking IP to make connection easier and more useful.

Existing sensors will also be joined by many, many, millions more, so that anything worth measuring can be measured ... and then managed.

To make that and other happen, the boffins in charge of creating a world of sensor-based stuff using IP to communicate have had to re-think connectivity pretty much from the bottom up.

With the assistance of Cisco distinguished engineer Jeff Apcar, The Register has taken a dive under the skin of the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL, pronounced “ripple”), a key emerging IETF standard for routing Internet of Everything messages.

Some parts of the hypothesised Internet of Things/Internet of Everything – for the rest of this article we'll stick to IoE – don't look that much different to any Internet client. Take a connected car, for example. Give it an IP interface of some kind, give it mobile connectivity, and hey presto! the car is connected to the Internet (with the attendant risks that may involve, but that's another story).

The imagined future collections of sensors are different. Computing power is cheap, and so are are “real-world” interfaces like microphones, accelerometers, gyroscopes, thermometers and so on.

Connectivity, it turns out, can be non-trivial thanks to various wireless standards.

But routing messages from huge numbers of devices is very complex, which is why outfits like Cisco are working up new routing protocols to serve the sensor-based Internet.

To understand the need for new routing techniques, consider a city-wide network of sound sensors. Such a network is posited as being able to identify the noise profile of a nearby car accident so an Ambulance can be despatched before the drivers have stopped arguing and called the police. Traffic management centres could also start to re-route cars seconds after the sounds of bumper striking bumper and glass hitting tarmac are registered.

The model only works if you have a lot of sensors around, and that poses practical problems because it's not worth collecting that data if you have to replace sensors every few weeks. Sensor designs therefore imagine devices that are completely stand-alone, communicate wirelessly and can go years between battery replacements (or are "scavenger-class" devices that work on solar or wind power). Sensor designs of this sort mean you can simply affix them to a handy solid object and forget them; having to connect power to every single device would destroy any business case such a sensor network could support.

Similar topics


Other stories you might like

  • What if ransomware evolved to hit IoT in the enterprise?
    Proof-of-concept lab work demos potential future threat

    Forescout researchers have demonstrated how ransomware could spread through an enterprise from vulnerable Internet-of-Things gear.

    The security firm's Vedere Labs team said it developed a proof-of-concept strain of this type of next-generation malware, which they called R4IoT. After gaining initial access via IoT devices, the malware moves laterally through the IT network, deploying ransomware and cryptocurrency miners while also exfiltrating data, before taking advantage of operational technology (OT) systems to potentially physically disrupt critical business operations, such as pipelines or manufacturing equipment.

    In other words: a complete albeit theoretical corporate nightmare.

    Continue reading
  • DeadBolt ransomware takes another shot at QNAP storage
    Keep boxes updated and protected to avoid a NAS-ty shock

    QNAP is warning users about another wave of DeadBolt ransomware attacks against its network-attached storage (NAS) devices – and urged customers to update their devices' QTS or QuTS hero operating systems to the latest versions.

    The latest outbreak – detailed in a Friday advisory – is at least the fourth campaign by the DeadBolt gang against the vendor's users this year. According to QNAP officials, this particular run is encrypting files on NAS devices running outdated versions of Linux-based QTS 4.x, which presumably have some sort of exploitable weakness.

    The previous attacks occurred in January, March, and May.

    Continue reading
  • Ubuntu releases Core 22: Its IoT and edge distro
    A tougher nut to crack than the regular flavor, some will find it very tasty

    Canonical's Linux distro for edge devices and the Internet of Things, Ubuntu Core 22, is out.

    This is the fourth release of Ubuntu Core, and as you might guess from the version number, it's based on the current Long Term Support release of Ubuntu, version 22.04.

    Ubuntu Core is quite a different product from normal Ubuntu, even the text-only Ubuntu Server. Core has no conventional package manager, just Snap, and the OS itself is built from Snap packages. Snap installations and updates are transactional: this means that either they succeed completely, or the OS automatically rolls them back, leaving no trace except an entry in a log file.

    Continue reading

Biting the hand that feeds IT © 1998–2022