# Routing Protocols for Low Power and Lossy Networks in Internet of Things Applications
## 3 Routing Protocols for Low-Power and Lossy Networks
### LOADng  
The LOADng (Lightweight On-demand Ad hoc Distance-vector routing protocol-next generation) is a reactive routing protocol based on AODV and adapted for LLNs. LOADng was presented in an Internet-Draft to IETF in October 2011 [59]. Since then, LOADng has received various updates, and its last version was published in July 2016 [60]. Similar to AODV, LOADng only creates a route when a node needs to send a data message to another node. The process of route creation (also known as route discovery) is performed through the use of control messages adapted from AODV. The RREQ (Route Request) message is used during the route discovery process to find a path to the desired destination. The RREP (Route Reply) message is used by the destination of an RREQ to attend to the received route creation request. To allow the creation of bi-directional paths, an RREP can require a reception confirmation. In this case, an RREP_ACK (Route Reply Acknowledgment) message is used to answer the sender of the received RREP. Further, the LOADng also can use RERR (Route Error) messages to inform problems detected during the data message forwarding. In general, RERR is used when an intermediate node does not know the destination of a data message. During the route discovery process of LOADng, the nodes should store a set of information about the other nodes of the network. Thus, each node has a routing set, a pending acknowledgment set, and a blacklisted neighbor set. The routing set, which works as a routing table, is formed by a set of entries created during the route discovery process. Each entry of the routing set contains information such as the destination address of the route, the address of the next hop to the destination, and the number of hops to reach the destination. The pending acknowledgment set is used to store data about the RREP messages sent with the requirement of an acknowledgment. As a complement to this last, the blacklisted neighbor set is employed to maintain the address of the nodes that have not replied with an RREP that required a reply (an RREP_ACK). In the protocol functioning, when a node \(S\) needs to send a data message to a destination \(D\), it first verifies its routing set, seeking a path to the desired destination. If the route is found, the node should use it to send the message. Otherwise, \(S\) must start the route discovery process. Thus, \(S\) creates an RREQ message with the same destination as the data message (node \(D\)). In sequence, \(S\) broadcasts the RREQ message to all its neighbors. Each node that receives the RREQ should verify several fields to identify whether it is valid for processing. This verification also avoids the creation of loops. The information carried in the message is used to update the routing set of nodes. In the sequence, the node refreshes the message fields and, if necessary, forwards it to the other nodes using broadcast transmission. The RREQ message is forwarded by the intermediate nodes until reaching the destination \(D\) (Figure 3a). When \(D\) receives the RREQ, an RREP message is generated and sent to reply to the request originated by \(S\). The RREP is forwarded in unicast using the path stored in the routing set during the RREQ broadcasts. If required by \(D\), each intermediate node that receives the RREP should send an RREP_ACK to the previous hop to confirm the RREP reception (Figure 3b). When \(S\) receives the RREP, the route discovery process is finished and the data message can be sent through the created path (Figure 3c). The RREQ and RREP messages carry fields to inform about the hop count and hop limit. Thus, so that these messages are always received, the node should increment the hop count and decrement the hop limit. The hop count field is used to inform about the number of hops traveled by the message since its originator. The hop limit field is implemented to indicate the number of remaining transmissions of the message. Thus, when a message is received with the hop limit equal to zero, it should not be forwarded to other nodes.