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

RPL: Layer 3 for sensor networks

Hence RPL – the IPv6 Routing Protocol for Low-power and Lossy 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.

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.

Objective Functions

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