Hi Sedat,
I agree your use cases should be considered and I can see your point. Let's see
if there are other comments from others.
ThanksQin
On Saturday, January 21, 2017 4:49 AM, Sedat Gormus <[email protected]>
wrote:
Hi Qin,
There are quite a few situations where is would be beneficial to just send a
directional CLEAR request with cellOption. For example, if I want to delete
lets say all transmit slots from A to B, DELETE will require the packet to
include all the cell list allocated between the pair so it might be cumbersome.
Also, If I am in the middle of a cell allocation transaction and decided to
CLEAR my TX cells to my current next hop and move on, I do not exactly know how
many cells have been allocated and what they are.
Does that make sense ?
Regards,
Sedat
On 21 Jan 2017 12:19 am, "Qin Wang" <[email protected]> wrote:
Hi Sedat,
I think CLEAR is usually used when inconsistency in schedules of a pair of
nodes is detected. In your case, DELETE, instead of CLEAR, can be used. In
addition, DELETE already has CellOption field. Make sense?
ThanksQin
On Friday, January 20, 2017 11:22 AM, Sedat Gormus <[email protected]>
wrote:
Dear All,
We think it might be a good idea to have a cell option field in the 6P clear
command. In some cases, we might want to delete only the transmit/receive slots
to our neighbor and keep the receive/transmit slots to that neighbor. One
example can be such that when a child node in a RPL network changes its parent,
it will need to delete its transmit cells to its parent. But, it might want to
keep its receive cells since there might be an ongoing communication happening
to another part of the network in the opposite direction which might be
negatively affected due to this change ( example can be a previously allocated
track).
Any comments and suggestions are welcome.
Kind Regards,
Sedat
______________________________ _________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/l istinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
