Dear all,
Regarding the discussion on the 6top-sublayer and the
6top-sf0 drafts, I would like to point out two items:
- First, If there is a preference for the parent's
schedule over the child, I think the transaction should be started
always from the parent side, but requested (maybe) from the child node.
The problem I see there is that we must define a cell direction indicator
to allocate the cells. Until now, we were managing allocation in a
neighbour-to-neighbour basis, so the one requesting allocation defined
the direction, as Thomas pointed out.
Example: Given two nodes, A and B, neighbours:
If A starts an allocation request towards B, then, it is expected that A
wants
to send traffic to B, so the direction is implicit.
Now, If A is the child and B the parent, A requires cells in the A->B
direction:
A asks B to allocate cells, in the A->B direction; then B starts an
allocation
request to A asking for cells in the A->B direction.
If we do not specify the direction, then, the cell will be allocated in the
opposite
direction. (B->A).
One further item: I assume that we must always use RPL for 6tisch, and that
the RPL DODAG is already formed before SF0 starts sending requests to 6top.
- Second: I agree with Pascal on adding a sequence number to keep
track of transactions. This increases reliability on top of the already
established non-concurrent transactions+timeout philosophy.
I'm only worried about the overhead of this approach (longer
packet and transaction sequence number storage and verification)
What do you think on the former comments?
Thank you.
Regards,
Diego
--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
