Subject: [Roll] Join preference calculation

From: "Charlie Chen (jianzche)" <[email-masked]>
Date: Sat, 3 Feb 2018 03:23:30 +0000

Hi Michael,

I am Charlie from Cisco. Our group is doing mesh products for grid. PAN migration is one of the most important features in our mesh solution, which we would like to keep refining.

We are interested in your proposal about join preference and want to follow it up in our future solution.

We think there are two factors that may need to be considered in the calculation for join preference.

First, DAG selection affects (sometimes decides) parent selection. We found that some nodes may select a DAG with less nodes but also a parent with too many children. It takes a certain of time for the node to reselect a better parent.
Thus, if join preference gives some indication like rank and children number, a node would make a right decision at the beginning.

Second, capacity limit is another semantics that join preference may need to carry, considering aggregated bandwidth and memory size on the root node. Especially, when root nodes with different capacity are deployed, mesh nodes have no clue to
decide whether to join a DAG with 60-nodes capacity and 50 nodes joined or a DAG with 1000-nodes capacity and also 50 nodes joined. If the limit of supported nodes or current utilization is carried, a mesh node can compare two DAGs in a reasonable way.

Above are our premature thoughts. We are look forward to the narrowing down of join preference calculation.

Thank you.

Best regards,
Charlie

---

From: peter van der Stok <[email-masked]>
Date: Mon, 05 Feb 2018 09:21:58 +0100

Hi Charlie,

is is an interesting subject that needs more reflection.
It is not clear to me when the join selection takes place; Is this 
before or after enrollment of the node in the mesh?
Dependent on that choice, different techniques are called for, in my 
view.

I like to draw your attention to the ROLL meeting in London that will 
discuss the coordination of the different parent selection and ranking 
algorithms that are currently proposed.

It would be good if we could give your subject a place in the currently 
ongoing and proposed ROLL work.

Cheerio,

Peter

Charlie Chen (jianzche) schreef op 2018-02-03 04:23:
> Hi Michael,
> 
> I am Charlie from Cisco. Our group is doing mesh products for grid.
> PAN migration is one of the most important features in our mesh
> solution, which we would like to keep refining.
> 
> First, DAG selection affects (sometimes decides) parent selection. We
> found that some nodes may select a DAG with less nodes but also a
> parent with too many children. It takes a certain of time for the node
> to reselect a better parent.
> 
> Thus, if join preference gives some indication like rank and children
> number, a node would make a right decision at the beginning.
> 
> Second, capacity limit is another semantics that join preference may
> need to carry, considering aggregated bandwidth and memory size on the
> root node. Especially, when root nodes with different capacity are
> deployed, mesh nodes have no clue to
> 
> decide whether to join a DAG with 60-nodes capacity and 50 nodes
> joined or a DAG with 1000-nodes capacity and also 50 nodes joined. If
> the limit of supported nodes or current utilization is carried, a mesh
> node can compare two DAGs in a reasonable way.
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 5 Feb 2018 13:34:01 +0000

Hello Peter and Michael

>From an architecture point of view, RPL either ignores or mixes the preference for the network, the DODAG in the network, the Join Proxy in the DODAG at join time, the parent in the DODAG once joined, and then the next hop at forwarding time, all in one concept of Rank. 

This is way to concise and creates all sorts of side effects in the field, such as nodes flapping between DODAGs.

The metrics to be used for the different stages vary widely.  As a summary of a talk with you and Michael, I see that the stages should be:

1) Select a Network. The network ID whatever that is could be hashed into one octet. An example could be the /64 folded on itself using XOR. A network in which the join process failed should be blacklisted for a while, and placed at the bottom of the queue of networks to be tried then.

2) Select a DODAG in that network. There is a need for a DODAG-level Rank value that is different from the RPL Rank; a new node should join the DODAG with the best value for that DODAG-Rank and for which a Join Proxy exists. A node that already participates to a DODAG should also jump onto the best DODAG with appropriate dampening to avoid mass jumps and oscillations. Metrics that contribute to that DODAG-Rank could include the load at the root, in terms of available bandwidth and capacity to accept new children. Battery levels could also be accounted for there. This can be compressed into a one-octet DODAG-Rank using a new PAN-Selection-OF.

3) Select a Join Proxy within the preferred DODAG. There is a need for a JP-Rank value that is also different from the RPL Rank. Join-Proxy is a capability which decreases with the number of attached nodes down to a maximum. That maximum can be bound to a maximum number of devices that are attempting a join via this proxy. Other parameters may influence the JP-Rank, e.g. network selection, DODAG selection, the bandwidth to the root, the Rank of the JP in the DODAG, etc... A candidate JP must advertise the relevant information in its beacons for nodes to make an appropriate selection. This can be compressed into a one-octet JP-Rank using a new join-OF.

4) Once joined, select parent(s) within the preferred DODAG to extend it with self. This is what the Rank in RFC 6550 does. Though new OFs and metrics can be devised, this is not the object of this discussion

5) Once routing is established, select a parent or a child for packet forwarding. Forwarding time needs metrics that reflect the immediate state of the next hop whereas routing builds longer term topologies that leave multiple possible selections for the forwarding to make. This is why RPL builds DODAG but does not discuss forwarding at all. This is not the object of this discussion either.

I see that defining all the above belongs to ROLL and that 6TiSCH is concerned with expressing requirements and mapping the information back into IEEE std 802.15.4 beacons. All in all, 6TiSCH recommends not to beacon till L3 is up and running (including RPL) and then to set the 802.15.4 Join preference in beacons with the Rank. Michael's draft indicates that this is not enough and propose a 4 tuple: netID, DODAG_Rank, JP-Rank, and RPL Rank. This will probably require a new IE.

Cheers,

Pascal

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: lundi 5 février 2018 09:22
To: Routing Over Low power and Lossy networks <[email-masked]>
Cc: Michael Richardson <[email-masked]>
Subject: Re: [Roll] Join preference calculation

Hi Charlie,

is is an interesting subject that needs more reflection.
It is not clear to me when the join selection takes place; Is this before or after enrollment of the node in the mesh?
Dependent on that choice, different techniques are called for, in my view.

I like to draw your attention to the ROLL meeting in London that will discuss the coordination of the different parent selection and ranking algorithms that are currently proposed.

It would be good if we could give your subject a place in the currently ongoing and proposed ROLL work.

Cheerio,

Peter

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Feb 2018 15:33:04 -0500

peter van der Stok <[email-masked]> wrote:
    > It is not clear to me when the join selection takes place; Is this before or
    > after enrollment of the node in the mesh?

yes, that's exactly the tusscle.

My take is that the enrolling pledge should not care about parent selection.
If it turns out the Join Proxy it selected is not a good Parent, then that's
okay, it will see other DIOs and pick them.

Others suggest that the there may be different LLNs with different
credentials, and that enrolling in the wrong LLN (even though one has
appropriate credentials) means that the new node will not see the right
parent offers.  I dispute that such a situation is secure.

I would like to separate the discussions, I really don't want to conflate them.

    >> I am Charlie from Cisco. Our group is doing mesh products for grid.

"grid" == smartgrid, meaning AMI?

    >> solution, which we would like to keep refining.

I would like to understand what "PAN migration" really means.
I understand that the PANID could change, but what else will change?
Why does the PANID need to change?  Has the node moved?
How are the administration/management of the two PANs related?

Will a new 2-byte layer-2 short address need to be assigned?

    >> node can compare two DAGs in a reasonable way.

Can you explain the topology and the management situation such that these
LLNs are separate, yet a node has the ability to see/hear traffic from both?

To me, what I see is a problem that occurs only in a network with no
security.

Looking forward to talking about this at 101.

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

---

From: "Charlie Chen (jianzche)" <[email-masked]>
Date: Sun, 11 Feb 2018 05:14:29 +0000

Hi Peter,

Sorry for late reply. Join selection takes place before enrollment of the node in the mesh.

But after joining, if current PAN does not serve well, the node should be able migrate to other mesh using the same metric as join selection,

Thus, the metric is important for both before enrollment and after.

If possible, I would love to contribute on this work.

Thank you.

Best regards,
Charlie

在 2018/2/5 下午4:22，“Roll 代表 peter van der Stok”<[email-masked] 代表 [email-masked]> 写入:

    Hi Charlie,

    
    
    Cheerio,
    
    Peter

---

From: Michael Richardson <[email-masked]>
Date: Sun, 18 Feb 2018 21:00:50 -0500

{this may be a duplicate, but I don't see it in the archive}

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > From an architecture point of view, RPL either ignores or mixes the
    > preference for the network, the DODAG in the network, the Join Proxy =
in
    > the DODAG at join time, the parent in the DODAG once joined, and then
    > the next hop at forwarding time, all in one concept of Rank.

It seems that you are making the following assumptions, which I think are
worth making explicit.   I further suggest that this gets written down into=
 a
requirements-like document before 101.

1) that the different DODAGs have different L2-network-wide-keys.
   That per-host-pair (802.15.9 mediated) keying never occurs.

2) that the different DODAGs have overlapping 2-byte short addresses.

3) that even after the initial enrollment, that the nodes can either
   reuse their PSKs (in the case of 6tisch minimal security) again,
   or that they have been provisioned with different PSKs for each PANID.

4) that the enrollment process does *not* result in a different credential
   (an LDevID for instance), that could be used to provide keying for
   all DODAGs.

5) it's unclear to me in a 6tisch context, if the different DODAGs/PANs
   have a coordinated schedule or not.

To me, it seems like enrollment should occur once.
These different DODAGs which might be on different PANIDs, should have
different RPL instanceIDs.  Perhaps it's enough to have different DODAGIDs.

    > I see that defining all the above belongs to ROLL and that 6TiSCH is
    > concerned with expressing requirements and mapping the information ba=
ck
    > into IEEE std 802.15.4 beacons. All in all, 6TiSCH recommends not to
    > beacon till L3 is up and running (including RPL) and then to set the
    > 802.15.4 Join preference in beacons with the Rank. Michael's draft
    > indicates that this is not enough and propose a 4 tuple: netID,
    > DODAG_Rank, JP-Rank, and RPL Rank. This will probably require a new
    > IE.

Do you mean an IE other than the one that the 6tisch-enhanced-beacon propos=
es
to create?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 19 Feb 2018 16:20:13 +0000

Hello Michael

This will certainly be an interesting discussion at ROLL. I do not really match my assumptions with the one you state below so we'll need to resync.
My assumption is that there is a concept of domain where a device can join and keep getting connectivity using credentials that it obtains once at join time for a long period. 
A network (which is typically a subnet identified with a /64) should be included in a domain, and a DODAG is included in a network.
6lo and 6TiSCH have the concept of a backbone router that federates multiple DODAGs in one to form a subnet; this implies that a PAN-ID is the same and that the short address namespace is common, at least if nodes derive their IPv6 address from section "6.  Stateless Address Autoconfiguration" of RFC 4944.

Take care,

Pascal

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: lundi 19 février 2018 03:01
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] Join preference calculation

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > preference for the network, the DODAG in the network, the Join Proxy = in

To me, it seems like enrollment should occur once.
These different DODAGs which might be on different PANIDs, should have different RPL instanceIDs.  Perhaps it's enough to have different DODAGIDs.

    > concerned with expressing requirements and mapping the information ba= ck

Do you mean an IE other than the one that the 6tisch-enhanced-beacon propos= es to create?

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Feb 2018 11:39:25 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > This will certainly be an interesting discussion at ROLL. I do not
    > really match my assumptions with the one you state below so we'll need
    > to resync.

That's why I ask to write them down :-)
I'm stating what I heard as assumptions, not that I agree with them all.

    > My assumption is that there is a concept of domain where a device can
    > join and keep getting connectivity using credentials that it obtains
    > once at join time for a long period.

That's also been my assumption which to me, means that it does not matter
which DODAG one enrolls through, as long as it's got bandwidth to do the enroll
process. But I hear others saying that they want to pick the network in advance.

    > A network (which is typically a subnet identified with a /64) should be
    > included in a domain, and a DODAG is included in a network.

I think we agree:
  Domain > Network(/64) > DODAG.

but maybe we need to write this down.  Perhaps there is a section of backbone
router that explains that should get a WG Consensus call in ROLL.

    > 6lo and 6TiSCH have the concept of a backbone router that federates
    > multiple DODAGs in one to form a subnet; this implies that a PAN-ID is
    > the same and that the short address namespace is common, at least if
    > nodes derive their IPv6 address from section "6.  Stateless Address
    > Autoconfiguration" of RFC 4944.

Again, let's write this down.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 19 Feb 2018 19:00:53 +0000

Agree 100%

Pascal

> Le 19 févr. 2018 à 17:39, Michael Richardson <[email-masked]> a écrit :
> 
>