Re: [6tisch] Node Address of Cell

[Thomas Watteyne]

Synchronized is a good thing in a 6TiSCH world :-)

On Wed, 16 Nov 2016 at 19:56 Yasuyuki Tanaka 
wrote:

> Hi Tero,
> Thank you for the clear explanation!!
>
> I check Figure 6-5 and Figure 6-6 that you referred. Indeed, there is
> no distinction on a sending frame between unicast or broadcast.
>
> Now I've got synchronized. :-)
>
> Best,
> Yatch
>
> On 2016/11/16 4:05, Tero Kivinen wrote:
> > Yasuyuki Tanaka writes:
> >> In this sense, the purpose of macNodeAddress is only to make something
> >> like a priority cell for outgoing frames to a certain MAC address
> >> other than the broadcast address. And, we cannot allocate a cell
> >> exclusively used for sending broadcast frames. I wish IEEE
> >> 802.15.4-2015 could elaborate what is expected to do with
> >> macNodeAddress... Everybody may have no confusion about these things
> >> except me...
> >
> > We had long discussion about that when 802.15.4-2015 revision was
> > being made, and we tried to clear things as much as possible, but as
> > people also had bit different things what 4e meant it was bit hard...
> >
> >> With regard to Link Options or Cell Options, I believe I have the same
> >> understanding as Tero's. I'm relieved here. :-) But, I have one thing
> >> I want to confirm about this.
> >>
> >> If a cell is "shared", this means that there is a possibility of
> >> contention or collision as you mentioned. This attribute, shared or
> >> not, is orthogonal to which type of communication, unicast and/or
> >> broadcast, to be done, isn't it?
> >
> > Yes. The 802.15.4-2015 [1] CSMA-CA algorithms (section 6.2.5.1) state
> > machines Figure 6-5 and TSCH CSMA-CA retransmission algorithm (section
> > 6.2.5.3) Figure 6-6 do not make difference whether the slot is
> > broadcast or not. It just have steps "Wait for next TX link to
> > destination" and that can be either broadcast link or link only for
> > it. The shared bit affects the next step which is "Dedicated Link?" /
> > "Shared slot?" questions.
> >
> > [1] http://standards.ieee.org/getieee802/download/802.15.4-2015.pdf
> >
> >> Therefore, in theory, we may have a dedicated (non-shared) TX cell
> >> whose macNodeAddress is the broadcast address.
> >
> > Yes. I.e. you are the only one allowed to send to that link, but there
> > are multiple listeneres in there. So, as it does not have shared bit
> > on, there will not be other transmitters, but there can be multiple
> > listeners on it.
> >
> >> In this case, a node having such a TX cell is supposed to be the
> >> unique sender in its neighborhood. We may also have a shared TX cell
> >> whose macNodeAddress is a unicast address. In this case, more than
> >> one pairs of devices could share such a cell for their
> >> communication.
> >
> > Yes.
> >
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Node Address of Cell

[Yasuyuki Tanaka]

Hi Tero,
Thank you for the clear explanation!!

I check Figure 6-5 and Figure 6-6 that you referred. Indeed, there is
no distinction on a sending frame between unicast or broadcast.

Now I've got synchronized. :-)

Best,
Yatch

On 2016/11/16 4:05, Tero Kivinen wrote:

Yasuyuki Tanaka writes:

In this sense, the purpose of macNodeAddress is only to make something
like a priority cell for outgoing frames to a certain MAC address
other than the broadcast address. And, we cannot allocate a cell
exclusively used for sending broadcast frames. I wish IEEE
802.15.4-2015 could elaborate what is expected to do with
macNodeAddress... Everybody may have no confusion about these things
except me...


We had long discussion about that when 802.15.4-2015 revision was
being made, and we tried to clear things as much as possible, but as
people also had bit different things what 4e meant it was bit hard...


With regard to Link Options or Cell Options, I believe I have the same
understanding as Tero's. I'm relieved here. :-) But, I have one thing
I want to confirm about this.

If a cell is "shared", this means that there is a possibility of
contention or collision as you mentioned. This attribute, shared or
not, is orthogonal to which type of communication, unicast and/or
broadcast, to be done, isn't it?


Yes. The 802.15.4-2015 [1] CSMA-CA algorithms (section 6.2.5.1) state
machines Figure 6-5 and TSCH CSMA-CA retransmission algorithm (section
6.2.5.3) Figure 6-6 do not make difference whether the slot is
broadcast or not. It just have steps "Wait for next TX link to
destination" and that can be either broadcast link or link only for
it. The shared bit affects the next step which is "Dedicated Link?" /
"Shared slot?" questions.

[1] http://standards.ieee.org/getieee802/download/802.15.4-2015.pdf


Therefore, in theory, we may have a dedicated (non-shared) TX cell
whose macNodeAddress is the broadcast address.


Yes. I.e. you are the only one allowed to send to that link, but there
are multiple listeneres in there. So, as it does not have shared bit
on, there will not be other transmitters, but there can be multiple
listeners on it.


In this case, a node having such a TX cell is supposed to be the
unique sender in its neighborhood. We may also have a shared TX cell
whose macNodeAddress is a unicast address. In this case, more than
one pairs of devices could share such a cell for their
communication.


Yes.



___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Node Address of Cell

[Tero Kivinen]

Yasuyuki Tanaka writes:
> In this sense, the purpose of macNodeAddress is only to make something
> like a priority cell for outgoing frames to a certain MAC address
> other than the broadcast address. And, we cannot allocate a cell
> exclusively used for sending broadcast frames. I wish IEEE
> 802.15.4-2015 could elaborate what is expected to do with
> macNodeAddress... Everybody may have no confusion about these things
> except me...

We had long discussion about that when 802.15.4-2015 revision was
being made, and we tried to clear things as much as possible, but as
people also had bit different things what 4e meant it was bit hard... 

> With regard to Link Options or Cell Options, I believe I have the same
> understanding as Tero's. I'm relieved here. :-) But, I have one thing
> I want to confirm about this.
> 
> If a cell is "shared", this means that there is a possibility of
> contention or collision as you mentioned. This attribute, shared or
> not, is orthogonal to which type of communication, unicast and/or
> broadcast, to be done, isn't it?

Yes. The 802.15.4-2015 [1] CSMA-CA algorithms (section 6.2.5.1) state
machines Figure 6-5 and TSCH CSMA-CA retransmission algorithm (section
6.2.5.3) Figure 6-6 do not make difference whether the slot is
broadcast or not. It just have steps "Wait for next TX link to
destination" and that can be either broadcast link or link only for
it. The shared bit affects the next step which is "Dedicated Link?" /
"Shared slot?" questions.

[1] http://standards.ieee.org/getieee802/download/802.15.4-2015.pdf

> Therefore, in theory, we may have a dedicated (non-shared) TX cell
> whose macNodeAddress is the broadcast address.

Yes. I.e. you are the only one allowed to send to that link, but there
are multiple listeneres in there. So, as it does not have shared bit
on, there will not be other transmitters, but there can be multiple
listeners on it. 

> In this case, a node having such a TX cell is supposed to be the
> unique sender in its neighborhood. We may also have a shared TX cell
> whose macNodeAddress is a unicast address. In this case, more than
> one pairs of devices could share such a cell for their
> communication.

Yes.
-- 
kivi...@iki.fi

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Node Address of Cell

[Yasuyuki Tanaka]

Hi Thomas and Tero,

Thank you for your responses! Yes, Tero's answered my question!!

To summarize:

[For TX]

- Any destination address is accepted in a cell if and only if its
  macNodeAddress is the broadcast address (or the short broadcast
  address).

- A unicast frame is sent over a cell whose macNodeAddress matches its
  destination address or is the broadcast address.

[For RX]

- macNodeAddress has nothing to do with RX.

- Any frame, regardless of the combination of its source and
  destination address, can be received through a cell.

In this sense, the purpose of macNodeAddress is only to make something
like a priority cell for outgoing frames to a certain MAC address
other than the broadcast address. And, we cannot allocate a cell
exclusively used for sending broadcast frames. I wish IEEE
802.15.4-2015 could elaborate what is expected to do with
macNodeAddress... Everybody may have no confusion about these things
except me...

With regard to Link Options or Cell Options, I believe I have the same
understanding as Tero's. I'm relieved here. :-) But, I have one thing
I want to confirm about this.

If a cell is "shared", this means that there is a possibility of
contention or collision as you mentioned. This attribute, shared or
not, is orthogonal to which type of communication, unicast and/or
broadcast, to be done, isn't it?

Therefore, in theory, we may have a dedicated (non-shared) TX cell
whose macNodeAddress is the broadcast address. In this case, a node
having such a TX cell is supposed to be the unique sender in its
neighborhood. We may also have a shared TX cell whose macNodeAddress
is a unicast address. In this case, more than one pairs of devices
could share such a cell for their communication.

How does that sound...?

Best,
Yatch

On 2016/11/15 5:06, Thomas Watteyne wrote:

Yatch,
Can you confirm Tero has answered your question?
Thomas

On Tue, Nov 15, 2016 at 12:02 PM, Tero Kivinen mailto:kivi...@iki.fi>> wrote:

Yasuyuki Tanaka writes:
> To my understanding, the scheduled cell in 6tisch-minimal can be used
> for both of unicast and broadcast. The destination address of a frame
> to be sent with the cell may have the MAC address of a particular
> neighbor or the broadcast address.
>
> But I'm not sure how we can handle that use case with the MAC Layer
> defined by IEEE 802.15.4-2015.
>
> According to IEEE 802.15.4-2015, each scheduled cell has a node
> address associated with it, which is called "macNodeAddress" and
> listed as a TSCH MAC PIB attribute in Table 8-85. By definition, this
> is "(an) address of neighbor device connected to this link or the
> broadcast address."  It sounds like we cannot use a single cell for
> unicast and broadcast at the same time; more generally, a cell cannot
> be associated with more than one distinct MAC address. This also
> implies that a node has to know the address of a correspondent
> beforehand to receive frames from it.

In 802.15.4-2015 there is 3 bits that affect this. TxLink, RxLink and
SharedLink. SharedLink means that the link is used by multiple senders
at the same time, and senders need to use different retransmission
mechanims on the link, as there might be collisions. If the link is
not SharedLink, it is dedicated link, thus node can send to it without
caring about collsions. SharedLink only has real mening on the
TxLinks.

In addition to that the TxLink might either have one mac address
assigned to it, or it might be breadcast address. This affects whether
this node can be used to send to that node. I.e. if node is trying to
send node xxx, it can either wait for TxLink having macNodeAddress of
xxx, or it can wait TxLink having macNodeAddress of broadcast.

macNodeAddress does not really have any meaning for the RxLinks
(unless they also have TxLinks). There is nothing in the 802.15.4-2015
which says how macNodeAddress is for RxLinks (i.e., the section 6.7.2
does not have any filter rules based on that.

> I thought there might be a special MAC address for internal use which
> matches any address, like 0.0.0.0 or ::/0, and we could set the
> address to "macNodeAddress." However, I cannot find such an address...
>
> In practice, is the broadcast address used for "any" as well as for
> "broadcast"? Do you have any thoughts?

Yes, I think you can use broadcast for NodeAddress for RxLinks.
--
kivi...@iki.fi 

___
6tisch mailing list
6tisch@ietf.org 
https://www.ietf.org/mailman/listinfo/6tisch 





--
___

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne

Re: [6tisch] Node Address of Cell

[Thomas Watteyne]

Yatch,
Can you confirm Tero has answered your question?
Thomas

On Tue, Nov 15, 2016 at 12:02 PM, Tero Kivinen  wrote:

> Yasuyuki Tanaka writes:
> > To my understanding, the scheduled cell in 6tisch-minimal can be used
> > for both of unicast and broadcast. The destination address of a frame
> > to be sent with the cell may have the MAC address of a particular
> > neighbor or the broadcast address.
> >
> > But I'm not sure how we can handle that use case with the MAC Layer
> > defined by IEEE 802.15.4-2015.
> >
> > According to IEEE 802.15.4-2015, each scheduled cell has a node
> > address associated with it, which is called "macNodeAddress" and
> > listed as a TSCH MAC PIB attribute in Table 8-85. By definition, this
> > is "(an) address of neighbor device connected to this link or the
> > broadcast address."  It sounds like we cannot use a single cell for
> > unicast and broadcast at the same time; more generally, a cell cannot
> > be associated with more than one distinct MAC address. This also
> > implies that a node has to know the address of a correspondent
> > beforehand to receive frames from it.
>
> In 802.15.4-2015 there is 3 bits that affect this. TxLink, RxLink and
> SharedLink. SharedLink means that the link is used by multiple senders
> at the same time, and senders need to use different retransmission
> mechanims on the link, as there might be collisions. If the link is
> not SharedLink, it is dedicated link, thus node can send to it without
> caring about collsions. SharedLink only has real mening on the
> TxLinks.
>
> In addition to that the TxLink might either have one mac address
> assigned to it, or it might be breadcast address. This affects whether
> this node can be used to send to that node. I.e. if node is trying to
> send node xxx, it can either wait for TxLink having macNodeAddress of
> xxx, or it can wait TxLink having macNodeAddress of broadcast.
>
> macNodeAddress does not really have any meaning for the RxLinks
> (unless they also have TxLinks). There is nothing in the 802.15.4-2015
> which says how macNodeAddress is for RxLinks (i.e., the section 6.7.2
> does not have any filter rules based on that.
>
> > I thought there might be a special MAC address for internal use which
> > matches any address, like 0.0.0.0 or ::/0, and we could set the
> > address to "macNodeAddress." However, I cannot find such an address...
> >
> > In practice, is the broadcast address used for "any" as well as for
> > "broadcast"? Do you have any thoughts?
>
> Yes, I think you can use broadcast for NodeAddress for RxLinks.
> --
> kivi...@iki.fi
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>



-- 
___

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
___
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Node Address of Cell

[Tero Kivinen]

Yasuyuki Tanaka writes:
> To my understanding, the scheduled cell in 6tisch-minimal can be used
> for both of unicast and broadcast. The destination address of a frame
> to be sent with the cell may have the MAC address of a particular
> neighbor or the broadcast address.
> 
> But I'm not sure how we can handle that use case with the MAC Layer
> defined by IEEE 802.15.4-2015.
> 
> According to IEEE 802.15.4-2015, each scheduled cell has a node
> address associated with it, which is called "macNodeAddress" and
> listed as a TSCH MAC PIB attribute in Table 8-85. By definition, this
> is "(an) address of neighbor device connected to this link or the
> broadcast address."  It sounds like we cannot use a single cell for
> unicast and broadcast at the same time; more generally, a cell cannot
> be associated with more than one distinct MAC address. This also
> implies that a node has to know the address of a correspondent
> beforehand to receive frames from it.

In 802.15.4-2015 there is 3 bits that affect this. TxLink, RxLink and
SharedLink. SharedLink means that the link is used by multiple senders
at the same time, and senders need to use different retransmission
mechanims on the link, as there might be collisions. If the link is
not SharedLink, it is dedicated link, thus node can send to it without
caring about collsions. SharedLink only has real mening on the
TxLinks.

In addition to that the TxLink might either have one mac address
assigned to it, or it might be breadcast address. This affects whether
this node can be used to send to that node. I.e. if node is trying to
send node xxx, it can either wait for TxLink having macNodeAddress of
xxx, or it can wait TxLink having macNodeAddress of broadcast.

macNodeAddress does not really have any meaning for the RxLinks
(unless they also have TxLinks). There is nothing in the 802.15.4-2015
which says how macNodeAddress is for RxLinks (i.e., the section 6.7.2
does not have any filter rules based on that.

> I thought there might be a special MAC address for internal use which
> matches any address, like 0.0.0.0 or ::/0, and we could set the
> address to "macNodeAddress." However, I cannot find such an address...
>
> In practice, is the broadcast address used for "any" as well as for
> "broadcast"? Do you have any thoughts?

Yes, I think you can use broadcast for NodeAddress for RxLinks.
-- 
kivi...@iki.fi

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Node Address of Cell

[Yasuyuki Tanaka]

Hi all,

To my understanding, the scheduled cell in 6tisch-minimal can be used
for both of unicast and broadcast. The destination address of a frame
to be sent with the cell may have the MAC address of a particular
neighbor or the broadcast address.

But I'm not sure how we can handle that use case with the MAC Layer
defined by IEEE 802.15.4-2015.

According to IEEE 802.15.4-2015, each scheduled cell has a node
address associated with it, which is called "macNodeAddress" and
listed as a TSCH MAC PIB attribute in Table 8-85. By definition, this
is "(an) address of neighbor device connected to this link or the
broadcast address."  It sounds like we cannot use a single cell for
unicast and broadcast at the same time; more generally, a cell cannot
be associated with more than one distinct MAC address. This also
implies that a node has to know the address of a correspondent
beforehand to receive frames from it.

I thought there might be a special MAC address for internal use which
matches any address, like 0.0.0.0 or ::/0, and we could set the
address to "macNodeAddress." However, I cannot find such an address...

In practice, is the broadcast address used for "any" as well as for
"broadcast"? Do you have any thoughts?

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch