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?
>
> Thanks
> Qin
>
>
> 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/listinfo/6tisch
>
>
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to