# Reduced Overhead Routing in Short-Range Low-Power and Lossy Wireless Networks +
## 4 Reduced Overhead Routing Protocol
### Enhanced P2P Routing and Forwarding
#### 4.1.2 Proposed Enhancement  
To enhance RPL's P2P route construction and data packet forwarding algorithms, we present an enhancement to current algorithms with the objective to avoid extra transmissions when a destination node is a direct neighbor of a source node or the destination node is a direct neighbor of a node relaying a data packet. Our enhancement can satisfy the stated objective by avoiding RPL's \(M_{DAO}\) message. Figure 2: Point to Multi-Point (P2 MP) and Peer-to-Peer (P2P) Routing Using Multicast Destination Advertisement Object (DAO). Furthermore, no change is needed to RPL's control messages. Due to the stated features, our proposed solution can easily coexist with existing RPL implementations. The DIO control message is used by RPL to construct MP2P routes. Corresponding to different DODAGs, DIO messages are multicast in the network. If a node becomes part of a DODAG advertised in a DIO message, the node also multicasts the DIO message corresponding to that DODAG using RPL's trickle timer. If a node does not become part of a DODAG, it ignores the DIO message. The above explanation shows that in any case nodes in a network have to process the DIO message. Regardless of whether a node joins a DODAG or not, each node receives DIO messages mulitcasted by its direct neighbors due to the broadcast nature of the wireless channel. A node can use its neighbor's DIO message to discover its direct neighbors and it can also store forwarding table entries for them in its forwarding table. Thus, instead of using a \(M_{DAO}\) message to discover and maintain forwarding table entries for direct neighbors, the same can be achieved by using DIO messages and implementing the following modifications:  
1. If a DIO message is received at a node, the node extracts the multicasting node's address from the DIO message, and stores it in its forwarding table. This step is carried out without considering whether the node is interested in joining the DODAG or not. If an entry for the multicasting node is already present in the table then the entry is refreshed and the next hop field is set equal to the multicasting node's address. If a node has a packet to transmit, it searches the destination address in its forwarding table. If the corresponding entry is available in the forwarding table, the packet is transmitted to the destination node or to the next hop. Otherwise, RPL forwarding rules are followed. 2. The above algorithm works in storing MoP, but nodes do not maintain forwarding tables in the non-storing MoP. In non-storing MoP, whenever a node receives a DIO message, it searches the IPv6 neighbor table. If the DIO message's multicasting node is not present in the table, a new record for the multicasting node is created and stored in the neighbour table. In this case, a NULL value is stored in the neighbor table's field for the link-local address. This forces the MAC layer to obtain a link-local address for the neighbor node before transmitting a frame. In non-storing MoP, another approach can be used that can store the multicasting node's address at the networking layer. In the non-storing MoP, this is feasible as nodes only need to store their direct neigbours' network layer address. In a realistic scenario nodes typically have resources to store addresses of their direct neighbors. If a node requires to transmit a packet, the node searches the destination node's address in its neighbor table or the data structure holding addresses of the node's direct neighbors. If a match exists, the packet is forwarded to the destination node, otherwise the RPL's forwarding algorithm for non-storing MoP is followed. When the root forwards the packet, it uses source routing, hence the presented forwarding algorithm only works if source routing is not used, i.e., when a P2P communication packet has not reached the root. ERPL use of DIO message to maintain direct neighbors' information is shown Figure 2(a). Similarly, the process of P2 MP and P2P route construction is shown in Figure 2(b).