# Dynamic-RPL: Enhancing RPL-Based IoT Networks with Effective Support of Dynamic Topology Management
## 2 RPL Overview  
IoT networks can be characterized as being formed with a varying number of resource-limited embedded devices over wireless LLNs. These are typically small-sized devices of constrained capabilities with respect to computation, energy, and storage. The establishment of LLN connectivity among these devices is achieved with low-cost wireless links and without incurring high complexity and energy. A common technology that is adopted at the LLN link layer is IEEE 802.15.4. However, these are scarce wireless links that come at the prices of no high performance and reliability guarantees. For reliable end-to-end IP communications, additional networking support is maintained for the LLN architecture. An additional IP adaptation layer is incorporated to implement header compression and fragmentation. This is achieved using IPv6 over Low Power Wireless Personal Area Networks (6 LowPAN) as specified in RFC 4944 [6] and RFC 6282 [7]. 6 LowPAN enables simple integration of LLNs with traditional IPv6 networks. At the network layer, addressing effective network routing is a challenging functionality. This is more evident in IoT deployments of strict networking requirements. The IETF ROLL working group has defined a set of LLN routing requirements for various IoTapplications. These include urban, industrial, home automation, and building automation applications, which are specified in RFC 5548 [8], RFC 5673 [9], RFC 5826 [10], and RFC 5867 [11], respectively. Taking such requirement diversity into consideration, an IETF-standardized routing protocol referred to as the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL) is specified in RFC 6550 [12]. RPL enables loop-free and customizable IPv6 routing functionality over restricted LLN connectivity. The development of RPL is oriented toward addressing routing challenges in the LLN environment. It works as a distance-vector routing protocol with a proactive operational mode. In addition to adhering to LLN characteristics, the protocol design of RPL is based on a routing framework that can be customized to achieve objective-oriented routing optimization. Different application-specific routing objectives can be implemented in RPL networks using single or composite routing metrics. Therefore, RPL can be effectively adopted to fulfill the distinct network requirements of different IoT applications. RPL structures an LLN network as a Directed Acyclic Graph (DAG) that is formed with single or multiple RPL instances. An instance is constructed as one or more Destinations-Oriented DAGs (DODAGs). The network topology of each DODAG incorporates a designated RPL sink node to which multiple non-sink RPL nodes are interconnected. As presented in Figure 1, an RPL network can have a multi-instanced RPL setup with each instance having a varying number of DODAGs. Ins-1 is an instance formed with three DODAGs whereas Ins-2 is a single-DODAG RPL instance. Each one of the sink nodes (S1-S4) can act as an Internet gateway to the nodes in its respective DODAG. Note that having some nodes such as N13 and N14 attached to both instances complies with the RPL standard. However, it is not allowed for a node to join more than one DODAG in a single instance. For the successful establishment of a DODAG topology, upward and downward network paths need to be constructed across the DODAG. At the initial stage, the sink node initiates this process by periodically broadcasting DODAG Information Object (DIO) messages. Recipients keep forwarding the messages after being updated with their relevant RPL information. Having the process repeated across the DODAG would eventually allow the successful establishment of the upward routes. The routing information necessary for successful DODAG discovery and maintenance is contained in the DIO messages. This includes the RPL Instance ID, DODAG ID, and version number. DODAG identification is realized using both the instance and DODAG IDs whereas the version number is important for tracking topological updates.