Re: [Roll] Issue with multiple instances in RPL

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 04 September 2014 09:44 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6691A00F1 for <roll@ietfa.amsl.com>; Thu, 4 Sep 2014 02:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level:
X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm24De10lq7t for <roll@ietfa.amsl.com>; Thu, 4 Sep 2014 02:44:39 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051EB1A00BB for <roll@ietf.org>; Thu, 4 Sep 2014 02:44:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5103; q=dns/txt; s=iport; t=1409823879; x=1411033479; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8WStD6C33bF7eNqzJTo4u6w4CfsEluf30N5elhfxTKg=; b=TRjnkazrbnpACYkhGwTFF3F+e15H9Enm88anbxt6qnlMGfeb4pSpIVSV B6nt2LEOySMQWL/xA09Qd77pjRLsBGvSgI/JXUxp+DkxF2qz9INVjgTVZ PiB4zYMSFEF8H/ZXN0Pn7wOn2AA2IwtqPgeobmWpFOpd1zAJkcNOKUM9/ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAD0zCFStJV2d/2dsb2JhbABZgw1TW8gZCodMAYEKFneEAwEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEEwgTiCcNvlQBEwSKL4RQHTgGgymBHQWRPpdKiQaDYWwBgUeBBwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,465,1406592000"; d="scan'208";a="74857681"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 04 Sep 2014 09:44:37 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s849ibm4000694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <roll@ietf.org>; Thu, 4 Sep 2014 09:44:37 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.236]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 04:44:37 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] Issue with multiple instances in RPL
Thread-Index: AQHPx7ffe1SAELIbPUe8HXLi/MG7HJvwq+UAgAALd8A=
Date: Thu, 4 Sep 2014 09:44:36 +0000
Deferred-Delivery: Thu, 4 Sep 2014 09:44:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D84DA2@xmb-rcd-x01.cisco.com>
References: <8727EEDC-3231-42EE-89FE-36CBCEB6C455@jacobs-university.de> <88d10f004652cc18ce329da7d94800b1.squirrel@www.ece.iisc.ernet.in>
In-Reply-To: <88d10f004652cc18ce329da7d94800b1.squirrel@www.ece.iisc.ernet.in>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.49.80.28]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/YPOFocCC6MrxsVm2qmqCeVxMbSo
Subject: Re: [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: Thu, 04 Sep 2014 09:44:42 -0000

Hi Anuj,

There is no problem with RPL itself. 

To support multiple instances the platform needs to be capable of implementing something like Virtual Routing and Forwarding (VRF).

>From an information such as receive interface, flow label,  TOS bits or RPL option, the router derives a table ID / scope and looks up the RIB that corresponds to that table ID / scope.

If you system can only have one RIB, then you are not capable of participating to multiple instances of RPL at the same time.
You'll find that draft-thubert-6lo-rpl-nhc elides the instance ID when it is zero. 
I can extend that to a well-known admin value default 0 if you need, please suggest that on the 6lo list if so.
 
Cheers,

Pascal


> -----Original Message-----
> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of
> Anand@ece.iisc.ernet.in
> Sent: jeudi 4 septembre 2014 05:53
> To: Routing Over Low power and Lossy networks
> Subject: Re: [Roll] Issue with multiple instances in RPL
> 
> 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
> > Roll@ietf.org
> > 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.
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll