Routing Protocol for Low power and Lossy networks
In this article we shall take a high-level look at an IoT protocol called RPL (pronounced ripple). The long-winded name is Routing Protocol for low power and lossy networks (LLN). Candidates sitting any CCIE Written exam should have some exposure to this protocol as part of the Evolving Technologies section that was added to all CCIE Written exams in July 2016.
Imagine a network of sensors monitoring noise or heat inside a building. All these sensors are continuously transmitting data wirelessly. It doesn’t make sense if you have to replace the battery or sensor every few weeks. Sensor designs should last years before needing to be replaced. They should also be standalone and not connected to any power source. Hence the term Low-Power and Lossy Networks (LLN).
If power was no problem and wireless/radio path unimpeded, you could force all the sensors to talk to a single controller. Sadly this is not the case.
RPL assumes that:
- The sensors need to construct paths back to a controller of some kind.
- Some or all of the sensors are power-constrained
- Some sensors lack a direct path to the controller and will need other sensors to pass on their data to the controller.
Traditional routing protocols are chatty and would waste battery power.
RPL is a distance-vector IPv6 routing protocol that caters for much higher packet loss than traditional routing protocols can handle. RPL is optimized for the many-to-one traffic pattern where many nodes send data towards a border router.
RPL organizes its topology as a Direction-Oriented Directed Acyclic Graph (DODAG). 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 a “node” (basically an IoT routing device).
The DODAG uses a simple hierarchical model that is similar to any distance-vector protocol you may have come across. Any DODAG will have a “gateway” through which communication to the outside world will traverse (LLN internet router). This gateway, referred to as the DODAG root, is number one in the hierarchy.
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.
An RPL instance defines multiple a topology containing multiple DODAG networks that build their trees using the same rules (e.g. two buildings in a campus with temperature sensors).
The RPL topology is built using control messages that are transmitted as ICMPv6 messages. The three key RPL control messages are:
- DODAG information solicitation (DIS): The DIS solicits a DODAG information object (DIO) from an RPL node.
- DODAG information object (DIO): The DIO carries information that allows a node to discover a RPL Instance, learn its configuration parameters, select a DODAG parent set, and maintain the DODAG.
- Destination advertisement object (DAO): The DAO is used to propagate destination information upward (to the root) along the DODAG.
To construct the DODAG topology, nodes may use a DIS message to solicit a DIO, or they may periodically send link-local multicast DIO messages. Nodes then listen for DIOs and use their information to join a new DODAG or to maintain an existing DODAG. Based on information in the DIOs, the node chooses parents that minimize the path cost to the DODAG root.
References: Cisco RPL Configuration Guide (https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/rpl/configuration/15-mt/rpl-15-mt-book.html#concept_442C4259376346D5958C3A812412967D)