Subject: [6tsch] blacklisting support on 6tus

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 22 Mar 2013 09:28:49 -0700

From the discussion today I've detected the need to blacklist channels. 
Does 6tus need to provide a command to do that? Specially if 
blacklisting is dynamic, 6tus needs to reallocate softlinks from that 
channels that have been blacklisted.

regards,
X

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 22 Mar 2013 09:54:34 -0700

Xavi and all,

When we talk about blacklist, the assumption is the blacklist is LLN wide,
or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100,
blacklist seems LLN wide.

Qin

> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 22 Mar 2013 09:59:47 -0700

IEEE802.15.4e supports blacklisting of one of more frequencies for the
whole network, as per
http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appendix-A.7
.
We could add a command in 6tus to drive that, but I would keep the
blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide.
Thomas

On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang <[email-masked]> wrote:

>  <https://www.ietf.org/mailman/listinfo/6tsch>
>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 22 Mar 2013 17:07:18 +0000

Xavi, all,
6tus allocates soft/hard cells, that are function of the channelOffset.
The number of available channelOffset is equal to the number of available PHY channels.
The blacklist affects the PHY channel (i.e., frequency) that is actually used for the transmission.
Thus, in case of balcklisting, if the number of available channels (i.e., the size of the blacklist doesn't change), then 6tus will not need to reallocate the soft cells.
The channel offset will be translated in a different PHY channel, based on the list of available frequencies.
Only if the size of the blacklist changes, then, 6tus will need to reallocate soft cells.
In any case, 6tus may needs to provide a command for knowing abut the blacklist and thus, the set of available channels.
Does this make sense to you?
Maria Rita

________________________________
From: [email-masked] [[email-masked]] on behalf of Thomas Watteyne [[email-masked]]
Sent: Friday, March 22, 2013 5:59 PM
To: [email-masked]
Subject: Re: [6tsch] blacklisting support on 6tus

IEEE802.15.4e supports blacklisting of one of more frequencies for the whole network, as per http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appendix-A.7.
We could add a command in 6tus to drive that, but I would keep the blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide.
Thomas

On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Xavi and all,

Qin

> [email-masked]<mailto:[email-masked]>

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch
<https://www.ietf.org/mailman/listinfo/6tsch>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Mar 2013 17:07:53 +0000

Hello Xavi.

There is an interface to the network management and blacklist and whitelist are typical methods.
I'm unsure how deep we want to go in that sort of things in the 6TUS draft.
Certainly we cannot cover everything and we want to be extensible.

Cheers, 

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: vendredi 22 mars 2013 17:29
To: [email-masked]
Subject: [6tsch] blacklisting support on 6tus

 From the discussion today I've detected the need to blacklist channels. 
Does 6tus need to provide a command to do that? Specially if blacklisting is dynamic, 6tus needs to reallocate softlinks from that channels that have been blacklisted.

regards,
X

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 22 Mar 2013 10:21:41 -0700

Hi all,

I agree, my only concern is that if 6tus layer provides commands to the 
management entity, blacklisting commands might be there for completeness.

regards,
Xavi

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 22 Mar 2013 10:52:30 -0700

Xavi and all,

If we agree that the blacklist is LLN wide, then the Channel Hopping IE
(defined by IEEE802.15.4e, instead of by 6tus) in EB will propagate the
validate physical channels. That means it is unnecessary for 6tus to
provide commands to set/get physical channels in blacklist.

Does it make sense?

Qin

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 22 Mar 2013 10:56:17 -0700

so who tells to the mac layer what channels need to be blacklisted?

does the mac layer decide by itself?

X

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 22 Mar 2013 11:11:28 -0700

At the beginning, the PIB of TSCH WPAN coordinator is configured,
including channel hopping attributes. Then, for a new joining node, after
it receives EB, the channel hopping IE should be given to MAC layer, i.e.
TSCH, and TSCH will be in charge to set its channel hopping related
attributes in PIB.

Make sense?

Qin

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 22 Mar 2013 11:44:22 -0700

+ More.

During a network running, TSCH WPAN coordinator can change its blacklist
according to the link quality report from nodes in the network. And,
still, the new blacklist and other information about channel hopping is
carried in channel hopping IE and propagated to the entire LLN.

Qin

>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf
>>>>> Of Xavier Vilajosana

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 22 Mar 2013 12:30:41 -0700

Hi Maria Rita,

I guess you mean that PCE needs to know the set of channels. I agree with
it. However, I think PCE has same knowledge as TSCH coordinator. The
blacklist is formed by TSCH coordinator without effort of 6tus by
definition of IEEE802.15.4e, thus, PCE should know the set of channels
without 6tus help.

I'm not sure how PCE get information from TSCH coordinator. But I think
the information should not provided by 6tus.

Does it make sense?

Qin

> Thus, in case of balcklisting, if the number of available channels (i.e.,
> the size of the blacklist doesn't change), then 6tus will not need to
> reallocate the soft cells.
> In any case, 6tus may needs to provide a command for knowing abut the
> blacklist and thus, the set of available channels.
> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appendix-A.7.
> On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang
> <[email-masked]<mailto:[email-masked]>> wrote:
> Xavi and all,
>

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 22 Mar 2013 12:31:03 -0700

Hi Maria Rita,

Does it make sense?

Qin

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 22 Mar 2013 20:19:17 +0000

Hi Qin,
yes, this is what I meant. From my point of view, 6tus shoudn't have much to do related to the blacklisting.
Once the TSCH coordinator has selected the set of channels to be used in the TSCH-LLN,  the PCE should collect such information (-- how is something still to be defined--).
Then, the PCE knows how many channels (and  channel offsets) are available for building the schedule (i.e., allocates the cells). 
Maria Rita
________________________________________
From: Qin Wang [[email-masked]]
Sent: Friday, March 22, 2013 8:31 PM
To: Maria Rita PALATTELLA
Cc: Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] blacklisting support on 6tus

Hi Maria Rita,

Does it make sense?

Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 22 Mar 2013 23:32:11 -0700

+1

I agree that 6tus should not have to care about channel blacklist. Thanks
for clarifying that.

On Fri, Mar 22, 2013 at 1:19 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

> Once the TSCH coordinator has selected the set of channels to be used in
> the TSCH-LLN,  the PCE should collect such information (-- how is something
> still to be defined--).
> Then, the PCE knows how many channels (and  channel offsets) are available
> for building the schedule (i.e., allocates the cells).
> Maria Rita
> > The channel offset will be translated in a different PHY channel, based
> on
> > the list of available frequencies.
> > From: [email-masked] [[email-masked]] on behalf of
> Thomas
> > Watteyne [[email-masked]]