Subject: [6tisch] Adding A cellOptin field to 6P Clear Request Command

From: Sedat Gormus <[email-masked]>
Date: Fri, 20 Jan 2017 19:21:53 +0300

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

---

From: Qin Wang <[email-masked]>
Date: Fri, 20 Jan 2017 21:18:46 +0000 (UTC)

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-masked]> 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-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Sedat Gormus <[email-masked]>
Date: Sat, 21 Jan 2017 12:49:40 +0300

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-masked]> 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
>
>
> 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

---

From: Qin Wang <[email-masked]>
Date: Mon, 23 Jan 2017 16:08:26 +0000 (UTC)

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-masked]> 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

Hi Sedat,

 Dear All, 

Kind Regards,
Sedat
______________________________ _________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/l istinfo/6tisch