Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-17.txt

From: Thomas Watteyne <[email-masked]>
Date: Wed, 4 Jan 2017 12:31:56 +0100

[returning from vacation this week, catching up on e-mail]

Tero,

About

The text "set its own PAN ID to 0xffff" is old text that should not be
> here in minimal anymore. The 802.15.4-2011 section 5.1.2.1.2 did that
> to get past the receive filters, but this had some other issues, and
> this text was removed in 802.15.4-2015 and the issue was solved
> properly.
> In 802.15.4-2015 the issue was fixed so that the section 6.7.2
> Reception and rejection has special text saying that filtering is not
> done based on normal filtering rules if we are doing scanning, but
> instead the MAC layer will process frames are described in the
> relevant subclause of 6.3.1...

Good catch. I propose the following change:

OLD:
While listening for EBs, setting its own PAN ID to 0xFFFF allows a node to
join any PAN.
Otherwise it will only join a network matching its PAN ID <xref
target="IEEE802154-2015"/>.
As per this specification, the selection of the PAN ID is out of scope.
NEW:
Nodes follow the reception and rejection rules as per Section 6.7.2 of
<xref target="IEEE802154-2015"/>.

About synchronization, the mechanism is very well understood, also by the
authors of minimal.
YOU have pointed out that, since EB are not secured with K2, using them for
time sync is not recommended after K2 is learnt.
I do NOT want to restart that whole discussion and suggest to keep the text
currently in -17.

On Fri, Dec 16, 2016 at 1:34 PM, Xavi Vilajosana Guillen <
[email-masked]> wrote:

> Hi Tero,
>
> I realized I am using
> Draft IEEE P802.15.4-REVc/D01TM
> Revision of
> IEEE Std 802.15.4-2011
> date 17-03-2016.
>
> so it seems a draft of the final 15.4. I switch to the last one. Sorry for
> the confusion.
>
> I will check and follow your comments. Thanks!
> X
>
> 2016-12-16 13:15 GMT+01:00 Tero Kivinen <[email-masked]>:
>
>> Xavi Vilajosana Guillen writes:
>> >     4.5.1:
>> >     1) What is the EB source address size?   Presumably the dst is
>> short FFFF,
>> >     but it isn't stated.
>> >
>> > XV: According to 15.4 -2015
>> > page 65.
>>
>> Which version of 802.15.4-2015 you have as the page 65 does not match
>> anything what you are saying. Page 65 has figure 6-6 about TSCH
>> Retransmission backoff.
>>
>> Better make sure you have the correct version, and download it from
>>
>> http://standards.ieee.org/getieee802/download/802.15.4-2015.pdf
>>
>> >     2)  "While listening for EBs, a joining node set its own PAN ID to
>> >     0xffff..." Why is the PAN ID set to FFFF? This implies that the EB
>> either
>> >     doesn't have a dst PAN ID (contrary to the previous paragraph) or
>> that
>> >     nodes accept EB's from any advertising PAN, which makes PANID not
>> useful
>> >     in partitioning networks.
>> >
>> > XV: This comes from some discussions we had some time back. I will try
>> to find
>> > the threads. As far as I remember, the concern was that the PAN ID is
>> not
>> > known by the node performing the scan. Then in order to be able to
>> accept the
>> > EB following the filtering rules (level 3) defined in the 15.4-2011.
>> section
>> > 5.1.6.2 or later in section 6.7.2 of 15.4-2015 the PAN ID has to be set
>> to
>> > FFFF.  I agree with you that we need to check this again.
>>
>> The text "set its own PAN ID to 0xffff" is old text that should not be
>> here in minimal anymore. The 802.15.4-2011 section 5.1.2.1.2 did that
>> to get past the receive filters, but this had some other issues, and
>> this text was removed in 802.15.4-2015 and the issue was solved
>> properly.
>>
>> In 802.15.4-2015 the issue was fixed so that the section 6.7.2
>> Reception and rejection has special text saying that filtering is not
>> done based on normal filtering rules if we are doing scanning, but
>> instead the MAC layer will process frames are described in the
>> relevant subclause of 6.3.1...
>>
>> >     4.5.2:  "EBs SHOULD NOT be used for time synchronization." The JN
>> must
>> >     initially set it's clock from the EB, otherwise it will have no
>> idea when
>> >     to send in its join request - see 6.2.   I think you mean that EB's
>> should
>> >     not be used for time synchronization after a node has K2?
>> >
>> > XV: I agree. We need first to join the network. I will correct that.
>>
>> Actually whether the node has K2 or not, is not relevant, the fact
>> whether it has any other time keeping neighbors tells whether it can
>> use any other method than EBs for time synchronization:
>>
>> See section 6.5.4 Synchronization in TSCH PAN:
>>
>>     Note that a device sending Enhanced Beacons to advertise a TSCH
>>     PAN should set the Timekeeping bit in the Link Option field, as
>>     described in 7.4.4.3, for the joining devices’ receive link so
>>     that joining devices can maintain time synchronization until
>>     additional time source neighbors are configured by a higher layer.
>>
>> Note, that there is two levels of timekeeping, first is the very
>> course level i.e., getting the ASN, and then time synchronization
>> inside the slot. The nodes get the ASN when they join the network and
>> they gain that from the EB. This is not really relevant here (except
>> that it forces the EBs to be unencrypted, even when they can be
>> authenticated as joining nodes need to be able to read ASN from the
>> EB).
>>
>> Then the second level of timekeeping, i.e., to keep synchronization
>> inside the slot is what we are talking here. For that the node needs
>> to use two methods described in the 6.5.4.2 Node synchronization.
>>
>> First method is to use acknowledgement-based synchronization, which
>> requires exchanging acked message with time keeping neighbor. Second
>> method is the frame based synchronization, and that requires receiving
>> frame from the time keeping neighbor of the node. The second method
>> can also use EBs, and that would be quite cheap way of keeping in sync
>> with network, as it does not require sending frames too often.
>> --
>> [email-masked]
>>
>
>
>
> --
> Dr. Xavier Vilajosana Guillén
> Research Professor
> Wireless Networks Research Group
> Internet Interdisciplinary Institute (IN3)
> Universitat Oberta de Catalunya
>
> +34 646 633 681 <+34%20646%2063%2036%2081>| [email-masked] | Skype:
> xvilajosana
> http://xvilajosana.org
> http://wine.rdi.uoc.edu/
>
> Parc Mediterrani de la Tecnologia
> Av. Carl Friedrich Gauss, 5. Edifici B3
> 08860 Castelldefels (Barcelona)
>
>
>
> 
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> 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
_______________________________________

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 4 Jan 2017 17:03:37 +0200

Thomas Watteyne writes:
> Otherwise it will only join a network matching its PAN ID <xref target=
> "IEEE802154-2015"/>.
> Nodes follow the reception and rejection rules as per Section 6.7.2 of <xref

Thats ok.

> About synchronization, the mechanism is very well understood, also
> by the authors of minimal. YOU have pointed out that, since EB are
> not secured with K2, using them for time sync is not recommended
> after K2 is learnt. I do NOT want to restart that whole discussion
> and suggest to keep the text currently in -17.

I was not proposing the initial change, that was somebody else saying
that we should not use EBs after we have K2, and Xavi agreed. Then I
pointed out that whether we have K2 or not is irrelevant. We should
only use EB if we do not have any other timekeeping sources, and if we
have any other timekeeping source, we should not use EB...
-- 
[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 5 Jan 2017 21:34:41 +0100

Tero,
Thanks for the explanation, I believe we agree.
Thomas

Thomas Watteyne, PhD

www.thomaswatteyne.com