WTF is … Routing Protocol for Low-Power and Lossy Networks?
Billions of sensors need novel routing schemes and the IETF is on the job
Free ESG report : Seamless data management with Avere FXT
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.
