[Roll] Issue with multiple instances in RPL

"Sehgal, Anuj" <s.anuj@jacobs-university.de> Wed, 03 September 2014 20:44 UTC

Return-Path: <s.anuj@jacobs-university.de>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C16B71A0AEB for <roll@ietfa.amsl.com>; Wed, 3 Sep 2014 13:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.218
X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hK5Jd10GdHQr for <roll@ietfa.amsl.com>; Wed, 3 Sep 2014 13:44:42 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BC01A036C for <roll@ietf.org>; Wed, 3 Sep 2014 13:44:39 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de []) by atlas3.jacobs-university.de (Postfix) with ESMTP id 19DBF1C7A; Wed, 3 Sep 2014 22:44:38 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([]) by localhost (demetrius5.jacobs-university.de []) (amavisd-new, port 10030) with ESMTP id s7F7SWM8PVUz; Wed, 3 Sep 2014 22:44:23 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 22:44:37 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de []) by hermes.jacobs-university.de (Postfix) with ESMTP id 129C320036; Wed, 3 Sep 2014 22:44:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([]) by localhost (demetrius4.jacobs-university.de []) (amavisd-new, port 10024) with ESMTP id at1feZt8H-TU; Wed, 3 Sep 2014 22:44:36 +0200 (CEST)
Received: from exchange.jacobs-university.de (shubcas02.jacobs.jacobs-university.de []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (not verified)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 24AF820035; Wed, 3 Sep 2014 22:44:36 +0200 (CEST)
Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS02.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 22:44:35 +0200
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
x-originating-ip: []
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
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Sep 2014 20:44:45 -0000


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