From: "Sehgal, Anuj" <s.anuj@jacobs-university.de>
To: "roll@ietf.org" <roll@ietf.org>
Thread-Topic: Issue with multiple instances in RPL
Thread-Index: AQHPx7ffe1SAELIbPUe8HXLi/MG7HA==
Date: Wed, 3 Sep 2014 20:44:35 +0000
Message-ID: <8727EEDC-3231-42EE-89FE-36CBCEB6C455@jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <EA684B08E884304E8E486869936D9F1D@jacobs.jacobs-university.de>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/LTQ246VInTdBDnEmYgYuoJlQjdk
Subject: [Roll] Issue with multiple instances in RPL
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>

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 ha=
s at least rudimentary support for multiple DODAGs and multiple instances a=
lready 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 deci=
de to join a DODAG MUST provision at least one DODAG parent as a default ro=
ute for the associated instance." Even though the RFC states that the defau=
lt route should be for the associated instance, while building a routing ta=
ble 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 r=
oute 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 on=
ly have one default route, which either belongs to DODAG from instance A, o=
r DODAG from instance B. Consequentially, whichever is the currently the "a=
ctive" instance, i.e. the DODAG for which the last DIO message was received=
, occupies the default route within the IP routing table. Another side effe=
ct of this is that each time a DIO message is received from the other insta=
nce, the default route changes. Of course, this leads to non-decisive routi=
ng of packets; the main problem being that instance A might try to route pa=
ckets 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 defa=
ult route upon receiving a DIO message, the node should just add a simple r=
outing table entry for the prefixes announced in the message. This should s=
olve the problem with multiple default routes, and even the constantly chan=
ging 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 v=
alid route. This could be solved by the intended border router also adverti=
sing a prefix for all routes. This should work in most applications since i=
t would seem unlikely that there is more than one Internet gateway in an ap=
plication.

Based on the presented information, what do the authors of RFC 6550 recomme=
nd be done with default routes, in case of multiple RPL instances? Furtherm=
ore, a clarification might be needed for the language in the RFC, so that i=
mplementations of RPL adopt the appropriate solution.

Warm regards,
Anuj Sehgal