Why Reactive Protocols are Ill-Suited for LLNs

In 2008, the IETF chartered a Working Group called ROLL (Routing Over Low power and Lossy networks) with the objective of specifying routing requirements of Low power and Lossy Networks (LLN), and then either select an existing routing protocol or specify and design a new routing protocol in light of the unique requirements of these networks. This led to the specification of a new routing protocol called RPL (see ) along with other specifications related to RPL. Despite the existence of a standard track routing protocol for LLN, discussions have been taken place as to whether other routing approaches could be suitable, such as deploying reactive routing protocols in LLNs, such as in smart metering networks, industrial automation, water management networks, etc.. The aim of this document is not to discuss a specific reactive routing protocol but why reactive routing protocols in general are ill-suited for LLNs. For the sake of illustration, we will refer to a reactive protocol called LOADng () which was introduced at the IETF, with results seeming to indicate performance improvement over the standard AODV protocol in the context of LLNs (). The aim of this document is to highlight the number of shortcomings and technical issues in using reactive routing in such networks. Note that reactive protocols are perfectly applicable to several types of mobile ad-hoc networks (MANETs), which are not LLNs. Specifically, LLNs exhibit constrained characteristics such as very low data rate (a few Kbps), lossy physical links where the packet delivery ratio can be poor (below 50%) and the links exhibit highly dynamic properties (high variation of Packet Delivery Ratio (PDR) with respect to time).

Please refer to for terminology. Additionally, the following terms are used throughout the document. Urban Low-Power Lossy Network. Packet Delivery Ratio. Route Request. Route Reply. Advanced Metering Infrastructure.

An LLN often has a more demanding traffic pattern than simple traffic between two peer nodes (P2P traffic). The nature of deployments and applications running over an LLN often requires a given node to send the same data to multiple recipients, requiring multicasting or point-to-multipoint (P2MP) support from the routing protocol. These destinations may be several hops away, therefore necessitating an efficient dissemination method. Examples of such traffic include: management information multicasted to all nodes belonging to a certain region in a landscape, certain part of the manufacturing pipeline in an industrial automation setting, upgrade of a new firmware, new tariff notification to a group of users in a smart grid deployment, a single node providing sensed data to multiple servers. Indeed, necessitates the support of P2MP traffic for a protocol to be suitable for U-LLN deployment. It describes - "Thus, the protocol(s) should be optimized to support a large number of unicast flows from the sensing nodes or sensing clusters towards a LBR, or highly directed multicast or anycast flows from the nodes towards multiple LBRs." and "A U-LLN may also need to support efficient large-scale messaging to groups of actuators.", which represents a massive critical need for a reliable P2MP mechanism. This requirement also necessitates a valid MP2P traffic support as well, which will be described in the next section. While a reactive routing protocol may be altered to support an on-demand bi-directional route between any two nodes in the network as provided by LOADng (see ), the protocol does not define a way to build and maintain an always usable multicast topology. It is worth mentioning here that the AODV protocol in mentions provision for nodes to join a multicast tree and RREQs to use multicast IP address as their destination address. However, no such methods or provisions are available in the lightweight versions of the AODV protocol, namely AODVv2 (formerly DYMO) or LOADng (). A naive and very costly solution would be to create a copy of the same message/application data to send for each destination. Also, to find the route to each destination, the node may have to create separate route request (RREQ) messages and broadcast them. This broadcast event creates a huge control overhead. Number of intended destinations for this P2MP traffic can reach an order of hundreds or thousands, which is very common in an LLN deployed in urban area, or for a number of Advanced Metering Infrastructure (AMI) meters in a particular region in a smart grid deployment. If such is the case, the protocol does not scale well with the network size in terms of control overhead. Hence, reactive routing protocols in general may become unsuitable to be deployed in a large scale LLN such as a U-LLN where P2MP traffic needs to be supported and be maintained, even if for 1-2 times a day. Simulation studies, such as the on in have verified that a reactive protocol suffers from high (over hundred seconds) end-to-end delay and large control overhead when P2MP traffic exists in the network.

Likewise P2MP traffic, MP2P traffic needs to be supported by a routing protocol intended for an LLN. This traffic pattern arises when multiple nodes may try to send data to a single sink at the same time. As describes, "A U-LLN should support occasional large-scale traffic flows from sensing nodes through LBRs (to nodes outside the U-LLN), such as system-wide alerts." By nature, this kind of traffic may be time-critical, and the alerts may need to be delivered within a small time-frame. Similar traffic may include critical scenarios in an industrial automation LLN deployment, where all nodes in one area may need to report malfunction, fire, or other emergency in that part of the manufacturing plant. Since, by default, reactive routing does not provide any efficient MP2P routing paradigm, all nodes will create their own route request (RREQ) in order to find the route to the LBR or server, if the route is expired or not cached. This situation will create separate broadcast control messages from each node, which may lead to a broadcast storm in the network, similar to the P2MP traffic scenario. The broadcast storm may result in individual RREPs reaching the initiator node much later, yielding a high delay for the time-critical alert packets. Routing for MP2P traffic is therefore not efficient or optimized, and does not follow an aggregation tree neither any such hierarchy is maintained in reactive protocols. As a result, it is difficult to devise a data aggregation algorithm compatible to AODV or any of its derivatives.

An LLN that is provisioned to be used for data gathering purpose today may include additional application layer modules in the future. Smart grid deployments may need to implement new modules of management traffic from the base stations to AMI meters, in addition to what is envisioned at present. LLNs are evolving and therefore it is expected that new applications and requirements will be part of its future (an LLN may also be re-purposed). Reactive protocols discover route to destination on an on-demand basis. If communication between same source-destination pair are spaced far apart in time, the protocol tends to discover the routes every time communication is requested by the application layer. With reactive routing protocols, adding a new application module which requires more data communication in between the existing data traffic pattern will incur control overhead. Hence, if a network is designed to operate within bounds in terms of maximum control overhead load, adding new application modules may well force the control overhead to surpass the designed maximum limit. For example, a deployment requiring both MP2P and P2P application may incur more overhead than a deployment which is currently working with only data aggregation. Since LLNs will undoubtedly require more application modules and management modules to be augmented in future, a suitable routing protocol should be able to cope with the added traffic. For the sake of illustration, many smart grid networks, which were originally designed for the purpose of advanced metering, now require a multi-service networks in support of a variety of applications including meter reading, use of meters of alarms, distribution automation and electric vehicles, leading to a variety of traffic patterns each with different quality of service requirements. As we observed in , even for a smaller network with less than 100 nodes, if the application data rate is increased from once in 12 hours to once an hour, the control overhead for a reactive protocol such as LOADng gets magnified by about 10 times.

A reactive protocol is well-suited for a traffic pattern where data transfer is not very frequent. However, if the traffic pattern includes periodic data reporting, even as low as a few times in a day, the traffic pattern will induce periodic broadcast of route request throughout the network. A simple example scenario can clarify this: assume an application in a U-LLN requires periodic data reporting every 6 hours or 4 times in a day - morning, noon, evening and night. If the network consists of 2000 nodes, which is a very conservative number in a typical U-LLN, the application alone will create a route request broadcast for each sensor node every 11 seconds, on average. Thus, over the life of the sensor network, a reactive protocol will use more control overhead than a proactive protocol. The amount of flooding to discover routes may also be controlled via tweaking the route expiry time or route validity time. If a route is active, nodes should not waste network resources trying to find out the route to the same destination. Keeping a high expiry time for the routes, on the other hand may prevent flooding the next time data is generated for the same destination. However, the path may well have been invalid by the route expiry time. Considering LLN link characteristics, link flapping is a very frequent event. Hence, high route expiry time may lead a node to find out invalidity of a path, thus forcing to flood the network again for route discovery. Thus, increasing route expiry time or route validity time for an AODV-based reactive protocol may not prove to control flooding in LLN. Proactively choosing a back-up path proves to be an effective way to ensure valid routing path in presence of link flaps, whereas reactive routing approaches are not able to cope with link dynamics, thus preventing its usage for LLNs. Furthermore, if traffic is sent along a broken path, a new request would consequently be generated, thus increasing the control traffic load, in addition to incurring additional delays for the user data.

Note that there is a lot of evidences supporting the claim that using flooding or scoped flooding to discover routes is ill-suited to power constrained Low-power and Lossy Networks (LLNs) in general. This is due to the low-power requirement. In low-power wireless networks, broadcast packets usually cost much more energy by the hardware to transmit than unicast ones due to implementations of sleeping mechanisms. As pointed out in , supporting broadcast transmission is difficult while implementing Low Power Listening (LPL) due to asynchronous duty-cycles of nodes. As the wake up time for each node in a neighborhood is independent, often multiple transmissions of a single frame are required to emulate one broadcast transmission. These multiple transmissions may consist of unicast transmissions to each of the neighbor (RI-MAC, see ), or repeated transmition of the frame during the whole sleep interval as done in X-MAC-UPMA (). Otherwise a really long preamble would be required, thus increasing power consumption more for broadcasts packets in either case. Ad-hoc networks which are normally always on, will not face this problem. Hence, reactive routing methods that use flooding mechanism for route discovery often, are more suited for Mobile Ad-hoc networks, but not for LLNs in general. LLNs should limit use of flooding or broadcasting packets as much as possible via algorithms such as Trickle . However, at this point, we would exclude consideration of such hardware dependent energy expense from our discussion.

Reactive routing protocols usually rely on route caching for discovered destination. Hence, if any node participates in multiple active flows in the network, the node needs to store next hop (and validity) information for each source and destination node in the network. Thus, depending on the user traffic, some nodes tend to increase their routing table size proportional to the number of flows passing through themselves. Hence, the nodes require more memory storage to operate successfully in these networks, depending on the traffic pattern. However, characteristics of LLNs never guarantee enough storage space in any node for storing routing tables. In LLNs, thus it is always advantageous to store route to a subset of nodes and still be able to find a path to any destination in the network. Reactive routing protocols, in their current specification or any variant, fail to achieve low memory requirement in nodes in the context of large scale LLNs. Destination oriented flooding in LLN, tends to worsen this situation. Multiple route requests may reach the same node at the same time for different destinations. Even though the destination may never be reached through the concerned node, the node still has to process and re-broadcast each request, along with its neighbors. Vital memory is consumed in RREQ/RREP processing and buffering in this method. As we observed during simulation study and in , the memory requirement in a reactive protocol such as LOADng grows with the network scale considerably. More specifically, they depend on number of active flows through a node, or number of destinations a node serves for which the routes have not expired yet. For a large network of over 2000 nodes, the total memory occupancy for a node, including route tables and buffered packets, for a reactive protocol may reach over 200 KB, as observed during simulation. Even for a small home automation network, the authors in pointed out, that the number of route entries and thus memory consumption depends on route expiry time for a reactive protocol. With increase in the route expiry time or route hold time, average number of route entries in a node increases. If the route expiry time is higher, the number of entries increases more sharply with increase in network size. However, at the same time, the study in agrees with the study conducted in that with decrease in route expiry time in order to save memory, control overhead increases as predicted in section 5.

Apart from providing a route between any two nodes in the network, a routing protocol suitable for LLN should be able to handle additional constraints. An LLN mainly consists of constrained devices, both functionality and memory-wise, and inherently heterogeneous in nature. Hence, any routing protocol suitable for LLNs should support node constraint based routing. This requirement is mandated in as follows: " the routing protocol MUST be able to advertise node capabilities that will be exclusively used by the routing protocol engine for routing decision". For example, the routing protocol should avoid a node with less battery power while routing to reach a server. Similarly, for industrial automation requirements, also needs a routing protocol to provide device-aware routing, as it describes "The routing algorithm MUST support node-constrained routing (e.g., taking into account the existing energy state as a node constraint). Node constraints include power and memory, as well as constraints placed on the device by the user, such as battery life". For home routing automation, specifies, "The routing protocol SHOULD route via mains-powered nodes if possible. The routing protocol MUST support constraint-based routing taking into account node properties (CPU, memory, level of energy, sleep intervals, safety/convenience of changing battery)". Clearly, recognizing a node's capability and routing accordingly is an important aspect for any routing protocol designed to be suitable for LLNs. However, any AODV-based protocol (such as AODVv2, formerly DYMO and LOADng), in their current specification, fail to provide routes based on any such constraint. Currently known reactive routing protocols do not have any provision to determine whether the next-hop node in a route has enough battery power to sustain the route, or whether the next-hop node is main powered or provides a particular functionality. Thus, these protocols fail to provide requirements mandated by , and for routing in an LLN.

Some data in an LLN are delay sensitive by nature. While data generated for periodic reporting can be delivered even up to few seconds later, emergency alarms, fault notification and alert packets need to be delivered as quickly as possible. According to , in an industrial automation setting, "Non-critical closed-loop applications have a latency requirement that can be as low as 100 milliseconds but many control loops are tolerant of latencies above 1 second". Clearly, these types of alert packets need a path to the destination beforehand as soon as they are generated. However, reactive protocols depend on finding a path when data is generated. Since the receipt of an RREP packet can take up to the network traversal time, for large networks the delivery of an emergency packet may take more than few hundred milliseconds. Also, if this emergency situation initiates a system wide alert from all nodes in the region to one or multiple servers outside the LLN, each node will create their own broadcast to reach the destination. Similar to the condition in section 3, the broadcast storm may lead to huge delay in receipt of RREP packets, and thus delay in delivering the emergency packet. The broadcast will lead to high control overhead, clogging the network, as well as loss of some RREQ/RREP packets. Indeed, reactive protocols provide a very high unreliability in delay bound for any number of hop distance to the destination. The delay is small when an active path is available, but high when the source has to issue a route request. The delay is a few magnitudes larger when multiple route requests/replies are simultaneously active. As observed during simulation and in , a reactive protocol as LOADng may take from tens of seconds to hundreds of seconds to deliver the data, depending on the network size and whether multiple RREQs/RREPs are active. Unreliability in delay bound has been found to be as high as 95% confidence interval in average end-to-end delay for the data packets. Also in , the authors pointed out how reactive protocols, even for a small home automation network presents large delay in order of a few seconds which increases with decrease in route expiry time.

TBD