Subject: Re: [6tisch] positionning 6LoWPAN ND, RPL and efficient ND within the 6TiSCH architecture

From: Don Sturek <[email-masked]>
Date: Wed, 05 Mar 2014 08:53:11 -0800

Hi Pascal,

Question for you:  Would your proposal cover the case where there would be
two (or more) border routers for a given RPL instance?

For our ZigBee IP work, we were dealing with just 30 nodes so that topic was
not so important.  We did, however, look into supporting multiple border
routers for a given RPL instance and thought there might be some Border
Router-to-Border Router communication needed (not covered in any of the RPL
specifications).   Do you think that might also be the case for 6tisch?   I
pose the question since I think deployments with larger numbers of RPL
instance devices will likely have such a requirement for multiple border
routers (and here I am specifically talking about in the context of
non-storing since obvously in storing mode the problem is much simpler)

Don

From:  "Pascal Thubert (pthubert)" <[email-masked]>
Date:  Wednesday, March 5, 2014 8:42 AM
To:  "[email-masked]" <[email-masked]>
Subject:  [6tisch] positionning 6LoWPAN ND, RPL and efficient ND within the
6TiSCH architecture

Dear all :
 
At the plugfest and then the WG meetings tomorrow, I¹ll be introducing work
to be done on ND and RPL to enable the 6TiSCH multilink subnet Architecture.
 
I produced a number of slides that illustrate the kind of flows and
interfaces that would enable to separate:
 
- The plain LLN host from a 6LR that connects to the RPL network. That would
be 6LowPAN ND but with some additions, at least the TID, from efficient ND.
- The 6LR and the 6LBR. That would be the DAR/DAC and then RPL (DAO). Seems
that it makes sense that the 6LBR is also the RPL root, since it is often
implemented by the same vendor as the 6LR.
- The 6LBR and the 6BBR. That would be efficient ND again, as an abstract
interface for the 6LBR to advertise which IPv6 addresses are connected to
its mesh. Efficient ND is a simple abstraction to advertise all the
addresses attached to the mesh, regardless what the mesh is (IOW this can be
used to connect existing mesh solutions).
- The 6BBR and other 6BBRs or any classical IPv6 nodes over the Ethernet
backbone. This can be a routing protocol, or proxy ND.
 
https://bitbucket.org/6tisch/meetings/src/89276d8bd8897b5bfc0d809e112ec67ef2
16e172/140306_ietf89_plugfest_london/6TiSCH_Backbone_Router.ppt?at=master
 
As I went through the exercise of drawing those flows, I found that the
definitions we have in the terminology should be revised. The 6LBR would
become the 6LoWPAN 6LBR plus the RPL root, whereas the 6BBR would be the
proxy that turns efficient ND into classical ND and back.
 
Note that the last slides show how the 6LBR and the 6BBR can be collapsed
into what the backbone router draft describes, and that would be a kind of
Layer-3 AP.
Then the slides show how the host and the L6BR can be collapsed, and if
there is no RPL at all, then the same flow can be used to cover WiFi
mobility.
 
See you tomorrow!
 
Pascal
_______________________________________________ 6tisch mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Mar 2014 23:38:16 +0000

Yes, Don, this is exactly the case.

And since we cannot renumber the subnet has to span the whole set of devices which then can move from a dodag to the next within the instance.

The 6BBR functionality is to detect the movement and announce it through proxy ND...

Pascal

Le 5 mars 2014 à 16:53, "Don Sturek" <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal,

Question for you:  Would your proposal cover the case where there would be two (or more) border routers for a given RPL instance?

For our ZigBee IP work, we were dealing with just 30 nodes so that topic was not so important.  We did, however, look into supporting multiple border routers for a given RPL instance and thought there might be some Border Router-to-Border Router communication needed (not covered in any of the RPL specifications).   Do you think that might also be the case for 6tisch?   I pose the question since I think deployments with larger numbers of RPL instance devices will likely have such a requirement for multiple border routers (and here I am specifically talking about in the context of non-storing since obvously in storing mode the problem is much simpler)

Don

From: "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 5, 2014 8:42 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [6tisch] positionning 6LoWPAN ND, RPL and efficient ND within the 6TiSCH architecture

Dear all :

At the plugfest and then the WG meetings tomorrow, I’ll be introducing work to be done on ND and RPL to enable the 6TiSCH multilink subnet Architecture.

I produced a number of slides that illustrate the kind of flows and interfaces that would enable to separate:

- The plain LLN host from a 6LR that connects to the RPL network. That would be 6LowPAN ND but with some additions, at least the TID, from efficient ND.
- The 6LR and the 6LBR. That would be the DAR/DAC and then RPL (DAO). Seems that it makes sense that the 6LBR is also the RPL root, since it is often implemented by the same vendor as the 6LR.
- The 6LBR and the 6BBR. That would be efficient ND again, as an abstract interface for the 6LBR to advertise which IPv6 addresses are connected to its mesh. Efficient ND is a simple abstraction to advertise all the addresses attached to the mesh, regardless what the mesh is (IOW this can be used to connect existing mesh solutions).
- The 6BBR and other 6BBRs or any classical IPv6 nodes over the Ethernet backbone. This can be a routing protocol, or proxy ND.

https://bitbucket.org/6tisch/meetings/src/89276d8bd8897b5bfc0d809e112ec67ef216e172/140306_ietf89_plugfest_london/6TiSCH_Backbone_Router.ppt?at=master

As I went through the exercise of drawing those flows, I found that the definitions we have in the terminology should be revised. The 6LBR would become the 6LoWPAN 6LBR plus the RPL root, whereas the 6BBR would be the proxy that turns efficient ND into classical ND and back.

Note that the last slides show how the 6LBR and the 6BBR can be collapsed into what the backbone router draft describes, and that would be a kind of Layer-3 AP.
Then the slides show how the host and the L6BR can be collapsed, and if there is no RPL at all, then the same flow can be used to cover WiFi mobility.

See you tomorrow!

Pascal
_______________________________________________ 6tisch mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/6tisch