Hi Maria Rita and all,
For support RPL structure of parent & children, I agree to think upstream and
downstream resource reservation separately. But, I'm not sure if we should use
3-phase protocol for upstream resource reservation, because that means 1/3
communication cost will be added for one transaction.
Maybe we can implement the upstream resource reservation in this way.
(1) The Child sends a Request message to its parent to require adding TX cells,
including NumCells, but without candidate CellList. Then, the parent choose the
cells for this Request without any constraint, and send back Response message
to the Child including the selected CellList; Or(2) The Child sends a Request
message to its parent to require TX cells, including NumCells and candidate
CellList, but the CellList is just information instead of requirement. Then the
parent choose cells for this Request considering the CellList or ignoring the
CellList, and send back Response message to the Child.
The basic idea is the rule of processing Request message involves the position
of nodes, i.e. parent or child. A problem could be the new selected cells may
conflict with the cells already used by the child with its children. I think
the problem can be solved by using un-overlapped Chunk in the neighborhood.
What do you think?
ThanksQin
On Monday, November 9, 2015 7:33 AM, Maria Rita PALATTELLA
<[email protected]> wrote:
#yiv9198189821 #yiv9198189821 -- _filtered #yiv9198189821 {panose-1:2 4 5 3 5
4 6 3 2 4;} _filtered #yiv9198189821 {font-family:Calibri;panose-1:2 15 5 2 2 2
4 3 2 4;}#yiv9198189821 #yiv9198189821 p.yiv9198189821MsoNormal, #yiv9198189821
li.yiv9198189821MsoNormal, #yiv9198189821 div.yiv9198189821MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv9198189821 a:link,
#yiv9198189821 span.yiv9198189821MsoHyperlink
{color:blue;text-decoration:underline;}#yiv9198189821 a:visited, #yiv9198189821
span.yiv9198189821MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}#yiv9198189821
p.yiv9198189821MsoListParagraph, #yiv9198189821
li.yiv9198189821MsoListParagraph, #yiv9198189821
div.yiv9198189821MsoListParagraph
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv9198189821
span.yiv9198189821EmailStyle17 {color:#1F497D;}#yiv9198189821
.yiv9198189821MsoChpDefault {} _filtered #yiv9198189821 {margin:1.0in 1.0in
1.0in 1.0in;}#yiv9198189821 div.yiv9198189821WordSection1 {}#yiv9198189821
_filtered #yiv9198189821 {} _filtered #yiv9198189821 {margin-left:58.8pt;}
_filtered #yiv9198189821 {margin-left:1.25in;} _filtered #yiv9198189821
{margin-left:1.75in;} _filtered #yiv9198189821 {margin-left:2.25in;} _filtered
#yiv9198189821 {margin-left:2.75in;} _filtered #yiv9198189821
{margin-left:3.25in;} _filtered #yiv9198189821 {margin-left:3.75in;} _filtered
#yiv9198189821 {margin-left:4.25in;} _filtered #yiv9198189821
{margin-left:4.75in;}#yiv9198189821 ol {margin-bottom:0in;}#yiv9198189821 ul
{margin-bottom:0in;}#yiv9198189821 Diego, Thanks for raising this discussion.
About: 1) If we assume the cells should belong to a given container,
for instance a chunk (owned by a parent node), it makes sense it is always the
parent to suggest the list of candidate cells. This implies we need to
re-define better the transaction/negotiation between two neighbors: a)
Upstream traffic. We will have a 3phases negotiation: the child asks for more
cells, the parent suggests the list of cells, the child checks the list and
pick the ones suitable. b) Downstream traffic: 2 phases - the
parent asks and proposes the list of cells, the child checks the list and picks
the ones suitable. 2) I remember we discussed about sequence number for
tracking the transaction already. But while updating the draft, we did not
include/consider it. Of course, we have to take into account overhead produced
and thus, scalability of the solution. Best Regards, Maria Rita From:
6tisch [mailto:[email protected]]On Behalf Of Prof. Diego Dujovne
Sent: Friday, November 6, 2015 7:31 PM
To: [email protected]
Subject: [6tisch] Comments on the 6top-sublayer and 6top-sf0 drafts 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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
