Subject: [6lo] Adaption of ROLL for mesh-under

From: Benjamin Damm <[email-masked]>
Date: Wed, 12 Apr 2017 04:33:40 +0000

Hi folks, I'm new here, so please steer me straight if this is not the right forum.

Is there any work under way that looks at how to use the ROLL-RPL data structures, algorithm, and messages, in a mesh-under network?  The routing in a mesh-under network can be very similar to ROLL-RPL but just one layer down.  Using similar but slightly smaller messages, adjusted for link-level identifiers instead of IP-level identifiers (and of course not supporting IPv6 features in the routing layer) seems like it would be possible, so I'm searching to anyone or any document that might have already led the way for this kind of mapping.

Regards,

-Ben

Benjamin Damm

O: 669-770-4000

E: [email-masked]<mailto:[email-masked]>  www.ssni.com<http://www.ssni.com>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 12 Apr 2017 06:46:24 +0200

Hi Benjamin,

Just speculating here:

In RPL itself, you could use "IP addresses" made up from MAC addresses as IIDs.
For the RPL-routed traffic, you could use 6LoRH-style encapsulation (RFC 8138), which also would fit a mesh-under approach very well.
So I think the total amount of messages that have to be designed/redesigned to make RPL applicable to mesh-under is very low; you’d mainly need a few new code points to make sure router-over RPL/traffic and mesh-under RPL/traffic are not confused.

But this also raises the question why you want to go mesh-under, if in the end everything looks so similar to route-over.

Grüße, Carsten

> On Apr 12, 2017, at 06:33, Benjamin Damm <[email-masked]> wrote:
> 
> E: [email-masked]  www.ssni.com
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Benjamin Damm <[email-masked]>
Date: Wed, 12 Apr 2017 05:16:59 +0000

In my case, it's because the network I'm starting with already operates well in a mesh-under regime. Small changes to fundamental mechanisms can have very interesting consequences IRW, so adjusting fundamentals to RFC-defined messages while keeping the same principle of operation would be a relatively low-touch way to move toward the benefits of standard vernacular, use of extensions, etc.  There is a marginal benefit of having possibly slightly smaller messages due to 64-bit IIDs instead of 128-bit IPv6 addresses, which on the whole is not important but out on the fringe of the network every bit counts.  Additionally, SSNI isn't the only company with large mesh-under deployments, so I do believe it could be a shared interest and worthy of taking up.

Benjamin Damm
O: 669-770-4000

________________________________________
From: Carsten Bormann <[email-masked]>
Sent: Tuesday, April 11, 2017 9:46 PM
To: Benjamin Damm
Cc: lo
Subject: Re: [6lo] Adaption of ROLL for mesh-under

Hi Benjamin,

Just speculating here:

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 12 Apr 2017 07:51:26 +0000

+1

I came to IEEE 802.15.10 at the inception of the work telling them exactly that.

As opposed to IEEE work that would have been pure RPL based L2R, my 'natural' approach for an IETF work would be storing mode and Address Family. Use IPv6 as signaling for all AFs and transport Short addresses as one AF in DAO messages; that design opens to IPv4 and all sorts of MAC layers.

We could also work in non-storing, enabling, potentially, a mixed mode where some hops are IP and some others are L2.

Note that the 6TiSCH backbone design is L2 in the backbone and routed at the IOT edge. 

Regards,

Pascal

> Le 12 avr. 2017 à 06:47, Carsten Bormann <[email-masked]> a écrit :
> 
> Hi Benjamin,
> 
> Just speculating here:
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Apr 2017 10:35:09 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > As opposed to IEEE work that would have been pure RPL based L2R, my
    > 'natural' approach for an IETF work would be storing mode and Address
    > Family. Use IPv6 as signaling for all AFs and transport Short addresses
    > as one AF in DAO messages; that design opens to IPv4 and all sorts of
    > MAC layers.

I was thinking the same thing.
Just do it with a different AF, such that routing tables are now L2
objects.

    > Note that the 6TiSCH backbone design is L2 in the backbone and routed

I would suggest that networks that want to move from mesh-under to route-over
and are already running IPv6, would be best to use RPL in the way 6tisch
uses it.  Gather the topology with RPL, then establish 6tisch-like tracks
at L2.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 13 Apr 2017 09:18:06 +0000

[Pascal] >  > Note that the 6TiSCH backbone design is L2 in the backbone and routed
  [Pascal] >  > at the IOT edge.

Mcr > I would suggest that networks that want to move from mesh-under to route-over and are already running IPv6, would be best to use RPL in the way 6tisch uses it.  Gather the topology with RPL, then 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.

Cheers,
[Pascal] 
Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 13 Apr 2017 09:18:03 +0000

Hello Benjamin:

The control plane can be adapted, certainly quite easily. But a key question is whether or not the data plane can be adapted to use RPL's RPI or not.

The RPI is how RPL signals its instances and manages routing failures. 

With it,
- RPL allows multiple routing instances for different needs
- the routing can fix damaged paths lazily, that is, only when the path is used or at some more global refresher time like a new iteration.
- RPL allows some elasticity in the feasibility condition, a "stretch" which may cause a local loop which in turn will be detected by either a packet or a local count to infinity, whichever comes first.

RPL can work without it, we do that in ANIMA for wired use cases (see draft-ietf-anima-autonomic-control-plane-06). 
But that means quickly repairing any damage, which is probably not good for battery operated devices.

Take care,

Pascal

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Benjamin Damm
Sent: mercredi 12 avril 2017 07:17
To: Carsten Bormann <[email-masked]>
Cc: lo <[email-masked]>
Subject: Re: [6lo] Adaption of ROLL for mesh-under

Benjamin Damm
O: 669-770-4000

Hi Benjamin,

Just speculating here:

In RPL itself, you could use "IP addresses" made up from MAC addresses as IIDs.
For the RPL-routed traffic, you could use 6LoRH-style encapsulation (RFC 8138), which also would fit a mesh-under approach very well.
So I think the total amount of messages that have to be designed/redesigned to make RPL applicable to mesh-under is very low; you'd mainly need a few new code points to make sure router-over RPL/traffic and mesh-under RPL/traffic are not confused.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Apr 2017 10:51:18 -0400

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

---

From: Benjamin Damm <[email-masked]>
Date: Thu, 13 Apr 2017 16:38:53 +0000

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

________________________________________
From: 6lo <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Sent: Thursday, April 13, 2017 7:51 AM
To: Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [6lo] Adaption of ROLL for mesh-under

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Apr 2017 15:40:30 -0400

Benjamin Damm <[email-masked]> wrote:
    > 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.

Would you expect the the wi-sun devices to only link to the CPDs, or do they
also need to connect to the BPDs?

If the former (just CPDs), then you just need to incrementally upgrade the
CPDs in the field, and when they discover upstream CPDs that speak RPL
they join both PANIDs.   Then they just send DAOs for all their L2 connected
BPDs.
There are probably some ND issues to sort out, and maybe an (efficient!) ND
proxy is in order.  Basically the RPL becomes the "backbone" for the
mesh-under networks.