Subject: [Roll] multi gateway in a RPL nwk

From: Mathieu Pouillot <[email-masked]>
Date: Thu, 15 Jul 2010 14:09:21 +0200

Hello All,

We are working on an architecture on which it is necessary to have two 
gateways to link our RPL-(W)SN and a LAN.

The goal is to have a redundancy of gateway if one of them crashes, And 
to select the way the most efficient according to the selected constraints.

In the scenario where we have only one root, we are not able to go out 
through the no-root gateway: all exterior addresses of the RPL nwk is 
routed through the Dag Root.

I see just the solution with a multidag ( each gateway is a Dag Root) 
involves more memories... Are there other possibilities?

best regards,

Mathieu

-- 
Mathieu Pouillot
R&D Engineer
[email-masked]

Tel : +33(0)4 98 01 60 05 (Poste 43)
Fax : +33(0)4 94 14 10 80
1766 Chemin de la Planquette
83130 LA GARDE - France
www.watteco.com<http://www.watteco.com/>

---

From: Tim Winter <[email-masked]>
Date: Thu, 15 Jul 2010 09:34:56 -0400

Hi Mathieu,

> involves more memories... Are there other possibilities?

There are two ways one could operate RPL in this scenario- depending on your goals 
and your ability to ensure a reliable communication between the two devices that are 
acting as DAG Roots.

In the first scenario, each device acts as an independent DAG Root, each with its own 
DODAGID but serving the same RPLInstanceID.  In this case, each node in the LLN will 
seek to join _one_ DODAG, thus associate with _one_ DODAGID for that RPLInstanceID. 
The effect is that the LLN (RPL-WSN) is partitioned, with some nodes associated with 
one DAG Root only and the remainder with the other DAG Root only.  In terms of 
memory, the DAG Roots may be relieved somewhat since the size of the partition that 
they are managing may be a subset of the entire LLN.  Similarly the nodes may be 
relieved (depending on storing/non-storing, etc).  If one DAG root fails then the 
nodes that had joined that failed DODAG will begin to lose parents (starting with the 
failed root) from that DODAGID, and then may join the second root (a different 
DODAGID) in order to regain connectivity for that RPLInstanceID.  (some of the 
'interior' nodes may not actually remove a parent, but may end up following their 
existing parent to the new DODAG).  Of course, in the failed root case, the remaining 
root now must now be able to allocate enough memory to support the entire LLN.

In the second scenario, the two root devices coordinate (over the LAN connection in 
your example) to operate as if they are one 'virtual' DODAG root.  In this case both 
nodes advertise the same DODAGID for the same RPLInstanceID, and they coordinate with 
each other to stay synchronized with any DODAG State, such as the VersionNumber. 
Each of these root nodes MUST then issue DIOs at the same time, increment the 
VersionNumber at the same time, ... in order to stay in synch over the LLN.  The 
mechanism/protocol for such synchronization is not defined in the RPL base 
specification.  Nodes could forward traffic to either root devices, and change their 
preference at any time in response to temporary link conditions, load balancing, etc. 
  If one DAG root fails then the nodes that were using that DAG root may begin to 
switch over to begin forwarding traffic exclusively to the other DAG root without any 
change in DODAGID.  (some nodes may have no choice but to drop off the DODAG and 
reattach at a different location in the sub-DODAG in order to raise their Rank, 
depending on the exact topology, etc.)

Regards,

-Tim

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Mathieu Pouillot <[email-masked]>
Date: Fri, 16 Jul 2010 08:41:11 +0200

Hi Tim,

The second scenario is very interesting. But how to manage the packet 
sending from the LAN to a node. If the routing table is shared between 
the two gw then two packets will be sent on the LLN, if the routing 
table is not shared, we are an issue with DAO when the topology will 
change. This could be sent on the other gw and so the first gw will  not 
update its routing table...

regards,

Mathieu
Le 15/07/2010 15:34, Tim Winter a écrit :
> There are two ways one could operate RPL in this scenario- depending 
> on your goals and your ability to ensure a reliable communication 
> between the two devices that are acting as DAG Roots.
>
> In the first scenario, each device acts as an independent DAG Root, 
> each with its own DODAGID but serving the same RPLInstanceID.  In this 
> case, each node in the LLN will seek to join _one_ DODAG, thus 
> associate with _one_ DODAGID for that RPLInstanceID. The effect is 
> that the LLN (RPL-WSN) is partitioned, with some nodes associated with 
> one DAG Root only and the remainder with the other DAG Root only.  In 
> terms of memory, the DAG Roots may be relieved somewhat since the size 
> of the partition that they are managing may be a subset of the entire 
> LLN.  Similarly the nodes may be relieved (depending on 
> storing/non-storing, etc).  If one DAG root fails then the nodes that 
> had joined that failed DODAG will begin to lose parents (starting with 
> the failed root) from that DODAGID, and then may join the second root 
> (a different DODAGID) in order to regain connectivity for that 
> RPLInstanceID.  (some of the 'interior' nodes may not actually remove 
> a parent, but may end up following their existing parent to the new 
> DODAG).  Of course, in the failed root case, the remaining root now 
> must now be able to allocate enough memory to support the entire LLN.
>
> In the second scenario, the two root devices coordinate (over the LAN 
> connection in your example) to operate as if they are one 'virtual' 
> DODAG root.  In this case both nodes advertise the same DODAGID for 
> the same RPLInstanceID, and they coordinate with each other to stay 
> synchronized with any DODAG State, such as the VersionNumber. Each of 
> these root nodes MUST then issue DIOs at the same time, increment the 
> VersionNumber at the same time, ... in order to stay in synch over the 
> LLN.  The mechanism/protocol for such synchronization is not defined 
> in the RPL base specification.  Nodes could forward traffic to either 
> root devices, and change their preference at any time in response to 
> temporary link conditions, load balancing, etc.  If one DAG root fails 
> then the nodes that were using that DAG root may begin to switch over 
> to begin forwarding traffic exclusively to the other DAG root without 
> any change in DODAGID.  (some nodes may have no choice but to drop off 
> the DODAG and reattach at a different location in the sub-DODAG in 
> order to raise their Rank, depending on the exact topology, etc.)
>
> Regards,
>
> -Tim
>
>>
>> best regards,
>>
>> Mathieu
>>
>> -- 
>> Mathieu Pouillot
>> R&D Engineer
>> [email-masked]
>>

-- 
Mathieu Pouillot
R&D Engineer
[email-masked]