Subject: [Roll] Issue with multiple instances in RPL

From: "Sehgal, Anuj" <[email-masked]>
Date: Wed, 3 Sep 2014 20:44:35 +0000

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

---

From: [email-masked]
Date: Thu, 4 Sep 2014 09:23:16 +0530

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
> [email-masked]
> 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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Sep 2014 09:44:36 +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:[email-masked]] On Behalf Of
> [email-masked]
> 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.
> >
> > 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.
> >
> > 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.
> >
> > 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
> >
> > This message has been scanned for viruses and dangerous content by
> > MailScanner, and is believed to be clean.
> >
> 
> 
> --

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Sep 2014 11:06:35 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > 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.

Did you typo "0" somewhere here?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Sep 2014 15:48:04 +0000

I meant that the elided instance could be 0 (zero) by default but a context could indicate otherwise...
Pardon my French : )

Pascal

> From: Roll [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: jeudi 4 septembre 2014 17:07