Subject: [6tisch] Questions on draft-chang-6tisch-6top-msf

From: Esteban Municio <[email-masked]>
Date: Mon, 13 Nov 2017 20:19:37 +0100

Hi,

After reading the draft I have some small comments.

When requesting the first 6P ADD, the CellsOptions are
TX=1,RX=1,SHARED=1 which means that the cell is bidirectional.
Is there any way to prevent that future EBs and DIOs are sent in this
shared cell? Or the implementation ensures that they will only be sent
in ts=0,ch=0?
When allocating/deallocating cells due to parent switching, is this
initial bidirectional cell allocated with the same CellsOptions in the
new parent as well?
Then if I understand well the node should always have at least one cell
with TX=1,RX=1,SHARED=1 with its preferred parent and has to "re-
allocate" it parallely
in a different 6P message than the used for the dedicated cells with
TX=1,RX=0,SHARED=0. Am I right?

When the nodes start sending DAOs? If it is at Step 6, it could be
interesting mention it there.
Are the DAOs allowed to be sent in the minimal cell?

And maybe a bit off-topic,
Is it possible for a node to have TX cells to neighbours that are not
currently its preferent parent?

Kind regards,
Esteban

-- 

Esteban Municio

IDLab - Dept. Mathematics and Computer Science 

University of Antwerp - imec

Middelheimlaan 1 , 2020 Antwerp, Belgium 

Office M.G.322

---

From: Tengfei Chang <[email-masked]>
Date: Mon, 13 Nov 2017 21:29:39 +0100

Hi Esteban,

I replied inline :-)

On Mon, Nov 13, 2017 at 8:19 PM, Esteban Municio <
[email-masked]> wrote:

> When requesting the first 6P ADD, the CellsOptions are TX=1,RX=1,SHARED=1
> which means that the cell is bidirectional.
> shared cell? Or the implementation ensures that they will only be sent in
> ts=0,ch=0?
>

*In this case the implementation will ensure that but through the neighbor
associated to the cell. For the reserved cell, it associated to its
parent/child address. Only a packet send to/received from parent/child are
allow to send on the cell.*

> initial bidirectional cell allocated with the same CellsOptions in the new
> parent as well?
>

*The 6P transaction for allocation to new parent will happen on the minimal
cell. After new cells are reserved to new parent, the 6P transaction for
deallocation to the old parent will happen on the previous installed cell
to the old parent. After this process, there will be no cell to it's old
parent.*

> with TX=1,RX=1,SHARED=1 with its preferred parent
>

*Correct!*

> and has to "re-allocate" it parallely

*The cell managed by MSF are all TX=1 RX=1 and SHARED=1 type of cell but
associated to a dedicated neighbor. (It's a dedicated cell since it only
send/received packet from a dedicated address)*

> Are the DAOs allowed to be sent in the minimal cell?

*No, the DAO is send through the scheduled dedicated cell.  Hence even a
node get a RANK through the DIOs it received, it can't send any packet
except 6P until it has a dedicated cell installed.*
*The DAOs and all other packets should be sent after a node reach to the **End
State.*

> currently its preferent parent?

*For MSF, the node only schedule the TX|RX|SHARED cell to preferent parent.
The TX cell or schedule non-preferent parent are out of scope of MSF.*
*It could be another SF though.*

> Esteban

*Let me know if you have any future issue or suggestion on MSF. Thank you
for asking! They are good questions. I hope I answered clearly!*

*Tengfei*

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

-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria

---

From: Municio Esteban <[email-masked]>
Date: Tue, 14 Nov 2017 08:50:18 +0000

Thank for the answer, now it's clear.
One last thing:
"The cell managed by MSF are all TX=1 RX=1 and SHARED=1 type of cell
but associated to a dedicated neighbor"
This means then nodes run backoffs in all dedicated cells? (i.e. to
avoid collisions between parent and child)
Kind regards,Esteban
On Mon, 2017-11-13 at 21:29 +0100, Tengfei Chang wrote:
> Hi Esteban,
> I replied inline :-)
> 
> On Mon, Nov 13, 2017 at 8:19 PM, Esteban Municio <esteban.municio@uan
> twerpen.be> wrote:
> > Hi,
> > 
> > Is there any way to prevent that future EBs and DIOs are sent in
> > this shared cell? Or the implementation ensures that they will only
> > be sent in ts=0,ch=0?
> 
> In this case the implementation will ensure that but through the
> neighbor associated to the cell. For the reserved cell, it associated
> to its parent/child address. Only a packet send to/received from
> parent/child are allow to send on the cell. 
> > initial bidirectional cell allocated with the same CellsOptions in
> > the new parent as well?
> 
> The 6P transaction for allocation to new parent will happen on the
> minimal cell. After new cells are reserved to new parent, the 6P
> transaction for deallocation to the old parent will happen on the
> previous installed cell to the old parent. After this process, there
> will be no cell to it's old parent. 
> > Then if I understand well the node should always have at least one
> > cell with TX=1,RX=1,SHARED=1 with its preferred parent 
> 
> Correct! 
> > in a different 6P message than the used for the dedicated cells
> > with TX=1,RX=0,SHARED=0. Am I right?
> 
> The cell managed by MSF are all TX=1 RX=1 and SHARED=1 type of cell
> but associated to a dedicated neighbor. (It's a dedicated cell since
> it only send/received packet from a dedicated address) 
> No, the DAO is send through the scheduled dedicated cell.  Hence even
> a node get a RANK through the DIOs it received, it can't send any
> packet except 6P until it has a dedicated cell installed.The DAOs and
> all other packets should be sent after a node reach to the End State.
> > Is it possible for a node to have TX cells to neighbours that are
> > not currently its preferent parent?
> 
> For MSF, the node only schedule the TX|RX|SHARED cell to preferent
> parent. The TX cell or schedule non-preferent parent are out of scope
> of MSF.It could be another SF though. 
> > Kind regards,
> > Esteban 
> 
> Let me know if you have any future issue or suggestion on MSF. Thank
> you for asking! They are good questions. I hope I answered clearly!
> Tengfei
> > -- 
> > Esteban Municio
-- 

Esteban Municio

Office M.G.322