[Roll] Issue with multiple instances in RPL

["Sehgal, Anuj" <[e-mail]>]

Hi,

We are working on an application that would require the use of multiple RPL instances. For implementation purposes we adopted Contiki 2.7, since it has at least rudimentary support for multiple DODAGs and multiple instances already built-in. However, during our development of the multi-instance code in Contiki we discovered a problem that seems to stem from RFC 6550 itself.

The RFC 6550 states that during preferred parent discovery "nodes that decide to join a DODAG MUST provision at least one DODAG parent as a default route for the associated instance." Even though the RFC states that the default route should be for the associated instance, while building a routing table in the IP layer there is no ability to select multiple default routes. Furthermore, an IP routing table does not allow for marking which default route applies to which instance. In fact, since IP packets do not carry any information as to which instance originated the packet, even special markup associated with IP routes cannot be used for making an appropriate routing decision.

This essentially means that when a node is part of two instances, it can only have one default route, which either belongs to DODAG from instance A, or DODAG from instance B. Consequentially, whichever is the currently the "active" instance, i.e. the DODAG for which the last DIO message was received, occupies the default route within the IP routing table. Another side effect of this is that each time a DIO message is received from the other instance, the default route changes. Of course, this leads to non-decisive routing of packets; the main problem being that instance A might try to route packets for instance B and vice-versa, while this should not occur.

Since the IP routing table does not support the ability to have two default routes, a simple solution appears to be that instead of configuring a default route upon receiving a DIO message, the node should just add a simple routing table entry for the prefixes announced in the message. This should solve the problem with multiple default routes, and even the constantly changing default route issue.

The only shortcoming of not having a default route is that packets that are intended for being routed outside of the RPL instance(s) will not find a valid route. This could be solved by the intended border router also advertising a prefix for all routes. This should work in most applications since it would seem unlikely that there is more than one Internet gateway in an application.

Based on the presented information, what do the authors of RFC 6550 recommend be done with default routes, in case of multiple RPL instances? Furthermore, a clarification might be needed for the language in the RFC, so that implementations of RPL adopt the appropriate solution.

Warm regards,
Anuj Sehgal