Michael's assumptions regarding why are mostly correct. There are many versions of the SSNI network, but the standard model is where the continuously powered devices (CPDs) which are firmware-upgradable form the core canopy and the majority of the device population, and various battery-powered devices hang off of the canopy using whatever CPD signals they can get. The CPDs are typically not significantly constrained (they aren't constrained at all per rfc7228) but the BPDs typically are, and they aren't all the same rfc7228 class. The evolution is to allow standard Wi-SUN (route-over) devices join the mesh, and potentially use some of the same RPL data structures, messages, and algorithms where possible to reduce the private burden of having non-standard routing structures and the various tooling and expertise challenges that go with that.
Benjamin Damm O: 669-770-4000 E: [email protected] www.ssni.com ________________________________________ From: 6lo <[email protected]> on behalf of Michael Richardson <[email protected]> Sent: Thursday, April 13, 2017 7:51 AM To: Pascal Thubert (pthubert) Cc: [email protected] Subject: Re: [6lo] Adaption of ROLL for mesh-under Pascal Thubert (pthubert) <[email protected]> wrote: mcr> I would suggest that networks that want to move from mesh-under to mcr> route-over and are already running IPv6, would be best to use RPL in mcr> the way 6tisch uses it. Gather the topology with RPL, then mcr> establish 6tisch-like tracks at L2. > [Pascal] In a green field, yes; maybe leveraging DAO projection, > too. But then if the goal is to use an existing forwarding plane, > certainly that's not the same story. yeah, I'm not entirely sure I know what the existing situation is. My impression is that the idea is to have a network that is a hybrid of both mechanisms, because the network is being incrementally evolved. As such I can see perhaps making L3 adjacencies (parent/child) over multi-hop L2 mechanisms, but in some cases, also recognizing that there are L3 aware nodes in between. If the nodes capabilities are high (and software upgrades or incremental replacement is possible), but the network bandwidth is such that running two networks (on different PANIDs or something) is impossible, then this might work. I asked Benjamin for more details privately, and I think that we'll get some more details soon. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
