# Dynamic-RPL: Enhancing RPL-Based IoT Networks with Effective Support of Dynamic Topology Management
## 5 Design
### Multi-DODAG Inter-Routing  
More effective use of the proposed approach can be further recognized by facilitating inter-routing among the different local-DODAGs in an RPL network. The network is administratively configured with a global-prefix for the global-DODAG in addition to a different local-prefix for each local-DODAG. During the global topology formation stage, the local-prefixes are exchanged over the global-DODAG. After a global attachment, only local-sinks initiate the global advertisements of their respective local-prefix. Potential-sinks need to participate in this process by only forwarding these advertisements globally. If it is the global-parent of its local-sink, a potential-sink also locally forwards the global advertisement to its local-sink. This is performed to ensure that all local-sinks maintain the required routing information to route data traffic among the different local-DODAGs. These considerations are important to avoid routing redundancy and stop creating potential routing loops or inconsistencies. Considering the example in Figure 5, N5 is the global-parent of N6 and N8 is the global-parent of S3. However, both N5 and N8 share the same global-parent of S2. If we let N6 and S3 exchange their local-prefix (P3), S2 would eventually receive different routing information regarding P3. This is a non-preferable situation that would result in routing inefficiency. Avoiding potential routing issues while maintaining full inter-routing is realized by limiting the initiation of local-prefix exchange to local-sinks. Only S3 advertises P3 to N8 whereas N6 is restrained from the exchange of P4 information. N8 then forwards the P3 advertisement globally to S2 as well as locally to S4 in a similar way. Figure 5: An example Dynamic-RPL inter-routing setup. Each local-sink includes its local-prefix in the standard RPL Target Option (TO), which is added to its global-DAO messages. TO has an unused flag field of which one bit is set to signal that this is the local-prefix of the global-sender. By receiving such information, its global-parent (whether a local-sink or potential-sink) stores the learned local-prefix in the relevant entry of the sender in the global multi-DODAG list. It then updates its routing table accordingly before forwarding such information further up to its global-parent using a new global-DAO message. This process keeps running to enable the global-sink to maintain an updated routing table entry for each local-DODAG in the network. A data packet transmitted from a source in one of the local-DODAGs to a destination in another local-DODAG is processed normally in the first one. It is routed over the established local-default-routes up to the local-sink of the source's local-DODAG. Then, the local-sink uses the global routing information in its routing table to forward the packet over the global-DODAG. If the local-sink is at an upper level in the global-DODAG compared to the destination's local-DODAG, it then would have a relevant routing entry that can be used to correctly forward the packet. Otherwise, it uses the global-default-route to forward the packet to its global-parent. Eventually, the packet would arrive at the relevant global-node in the destination's local-DODAG, which then routes it locally to the destination. In Figure 5, a packet is routed locally in LD3 if it is destined from N17 to N15 for example. It first arrives at S3 after having local-recipients in LD4 use their local-default-routes for packet forwarding. Then, S3 uses its global-default-route to forward the packet to its global-parent, N8, which also repeats the same procedure to forward the packet to S2. Having a local-entry in its routing table for N15, S2 is then able to forward the packet locally to N4, which also uses its local routing information to forward the packet to its final destination. If a reply packet is then destined to N18, it would indicate a global-packet destined to LD3 as this can be learned from the destination prefix.