# Routing Protocols for Low Power and Lossy Networks in Internet of Things Applications
## 4 Enhanced Routing Solutions for Internet of Things Networks
### P2P Communication Support
Although P2P-RPL can allow improved P2P data traffic for RPL networks, it still lacks in some areas. The protocol admits that the links among the nodes are symmetric, i.e., the quality of the linkage from Node A to Node B is the same (or almost the same) from B to A. Hence, the P2P messages exchanged between these nodes use a single path. However, in a practical environment, this symmetry may not be reached and, consequently, may not satisfy the routing requirements of a large variety of IoT applications. Thus, the Ad hoc On-demand Distance Vector routing-based RPL (AODV-RPL) [66] emerges as an improvement of RPL to support the P2P traffic pattern considering both the symmetric and asymmetric link during the path discovery process. As P2P-RPL, the peer-to-peer routes in AODV-RPL are constructed on-demand. A source node begins the route creation process to a destination when the current path does not fulfill the application requirements or the desired path does not exist. Thus, the source node must send DIO-RREQ (DIO with Route Request content) messages to create an RREQ-instance (DODAG created by the originator of an RREQ message) and find a path to the desired destination node. DIO-RREQ has a field to carry information about whether the route is symmetric or asymmetric (\(S\) field). Each node that receives the DIO-RREQ must verify the condition of the bidirectional link, update the \(S\) field, if necessary, and choose whether to join in the RREQ-instance. In this case, if a link is set as asymmetric, all routes that use this link are considered asymmetric. When DIO-RREQ reaches its destination, the node, based on the \(S\) field, must choose how to answer the route creation request. The destination node can also wait for a predefined period to receive DIO-RREQs through other routes. If the \(S\) field of the message indicates that the route created is symmetric, the destination node should unicast a DIO-RREP (DIO with Route Reply content) to the DIO-RREQ originator through the created path. Therefore, due to being symmetric, this single path can be used for data transportation in both directions. Otherwise, in case the route created is asymmetric, the destination node should start the creation of an RREP-instance (DODAG created by the destination of an RREQ message) multicasting DIO-RREP to its neighbors. DIO-RREPs are forwarded realizing the link symmetry verification, similarly to DIO-RREQs, until reaching the DIO-RREQ originator that, after receiving it, should initiate the sending of data messages through the path created by the DIO-RREP. Notice that when AODV-RPL does not find a symmetric path between two nodes, it can create a pair of DODAGs (RREQ-instance and RREP-instance) with a single-route discovery process. Thus, the P2P data message exchange can be performed using two different paths: a route from A to B and another from B to A. However, AODV-RPL is still an IETF Internet-Draft and can suffer modifications until its complete definition. Furthermore, to the best of the authors' knowledge, no other paper in the literature realizes a performance evaluation study about the efficiency of AODV-RPL. Table 1 presents a summary of the above-described routing solutions. \begin{table}
\begin{tabular}{l l l l l l l l} \hline \hline