Original URL: https://www.theregister.co.uk/2013/08/30/wtf_is_rpl/
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.
RPL: Layer 3 for sensor networks
While RPL only addresses part of the communication conundrum (Layer 3 challenges), the argument that treating sensor communication as a routing problem is sound, if for no other reason than one thing sensors have to do is take communications from each other and pass them on – a routing problem.
If power was no object and the radio path is unimpeded, you could simply force all the sensors to talk to a single controller. Even then, there's a problem: if you want millions of sensors, you can't just construct a flat Ethernet network and expect it to work. The network would have to be segmented somewhere, and you'll still need routing between segments.
So RPL assumes that:
- The sensors need to construct paths back to a control point of some kind;
- Some or all of the sensors are power-constrained; and
- Some sensors will lack a direct path to the control point, and will need other sensors to pass on their messages.
Yep, that's a routing question all right. It neatly reflects what your computer or phone needs to know when you try to connect to a server on the Internet: “which router is the closest to my destination?”, after which the tables held by intermediate systems provide the rest of the path, in part or in whole, until a session is established.
It would all be simpler if something like IS-IS was suitable for sensor networks, but it's not. Internet routing protocols are chatty, and would waste battery power in a sensor you hope will last for years. And anyhow: if we're talking about millions of sensors, you'd be asking some of them to hold inappropriately large routing tables.
Below is a simplified RPL diagram based on a Cisco presentation slide.
RPL allows system designers to set rules for how sensors communicate. Image: Cisco, The Register
The key concept here is the DODAG: Direction-Oriented Directed Acyclic Graph. The idea is to construct a non-looping table in which every sensor has someone to talk to, and in which a path is built for every sensor to reach the “node”.
And the DODAG is a quite simple hierarchical model. Any DODAG has only one “gateway” (by which I mean a device exposing an IPv6 address to the outside world. This gateway, referred to as the root, is number one in the hierarchy.
Next: anything that finds itself with a direct path to the root has Rank 2. Anything that can only see Rank 2 devices is a Rank 3 device, and so on. If you have Rank 5, you will regard the nearest Rank 4 device as your “parent” and direct communications to it, assuming that it will pass your communication on to its parent, and so on.
Two sensors of the same rank, as you can see from the image, can treat each other as peers (“siblings”). This helps keep the network robust: if a device's path is interrupted, it can use its sibling to deliver the message.
Wrapping all of this up is an RPL “instance”. Notice that the instance can extend beyond a single location – or rather, beyond a single sensor network. In the case above, we'd presume that the two sensor networks are connected by a secured tunnel.
The RPL instance defines DODAG networks that build their trees using the same rules. Hence, if you have two city networks – one either side of the Sydney Harbour Bridge, for example – they can be recognised as being part of the same RPL Instance.
What I've already described is a very simple and obvious way to build the RPL DODAG, based on hops between a sensor and its root. That assumes that all of the sensors are identical.
There are, however, reasons to want to build something more complex. For one thing, it's reasonable to assume that some sensor networks might need to consider QoS. Sensors that exist merely to relay ambient temperature back to the air-conditioning controller don't need to be treated the same as a medical sensors.
The rule by which the DODAG is built is called the Objective Function, and the example given above demonstrates the default Objective Function, OF Zero.
However, what if something other than only the hops needed to be considered to build the DODAG? What if – to consider the medical device example – the network needed to consider latency as well?
Hence the OFs, which allow other rules to be taken into account. Currently, the standard defines three node characteristics – node objects – and three link objects to be defined in building DODAGs.
Node Objects are:
- The Node State and Attributes Object – nodes can signal whether they have capacity to pass messages (the “A” flag, for available) or not (“O” flag, for overloaded);
- The Node Energy Object – indicating whether the node is on mains power, battery power, or “scavenger” power (solar or wind), along with flags to indicate remaining power, and whether this node can be included in networks; and
- The Hop Count Object – which is either a metric (how many hops) or a constraint (maximum number of hops).
Link Objects are:
- The Throughput Object;
- The Latency Object;
- The Link Reliability Object; and
- The Link Colour Object – for user-selectable link characteristics.
The upshot of applying these characteristics to the job of building the DODAG is that the table doesn't only reflect physical topology. The DODAG might reflect rules such as “avoiding overloaded nodes”, or “try to find nodes connected to AC power”.
- Avoid overloaded nodes;
- Prefer ac-powered nodes over battery-powered nodes;
RPL also allows vendors to create their own OFs, and bake them into devices at manufacture. When installed into a network, a device would determine if its OF is available – and if not, it will simply default to OF Zero. New OFs can also be submitted to the IETF, allowing them to be shared between vendors.
Speaking of the IETF, it hosts the RPL spec here. ®