Re: [Roll] Issue with multiple instances in RPL

[[e-mail]]

Hi Anuj,

Just curious to know, is it difficult to tweak IP layer code to realise
what you mentioned ? I know a typical IP implementation is what you are
referring to. These days with so much happening in the forwarding path in
the form of policy based routing, one can have an internal mechanism to
achieve what you are saying, no ?  Hope my understanding of your concern
is right.

Anand

> 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
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.