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

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Tue, 13 Dec 2016 08:35:12 +0100

Dear Jonathan,

thanks for your comments. See inline our responses:

2016-12-12 22:48 GMT+01:00 Jonathan Simon <[email-masked]>:

> Xavi, Kris - Some questions about draft 17:
>
> 4: The callouts in figure 1 don't exactly match what's in 4.5.2, namely
> that the timelsot and hopping template IDs (as opposed to the full
> sequence) are what is carried in the EB.
>
> XV: The proposed configuration as advertised in the EB uses the default
timeslot and hopping template ID. macTimeslotTemplateId = 0 and the
default (macHoppingSequenceID = 0). Following your suggestion I will change
the table to indicate this (macHoppingSequenceID = 0). Should we also keep
the default sequence as a clarification (indicating that) [5, 6, 12, 7, 15,
4, 14, 11, 8, 0,  1, 2, 13, 3,  9, 10]?

> 4.5: This paragraph could be interpreted as saying that a compliant node
> may choose particular settings, but must be able to understand all possible
> valid TSCH settings to be 6TiSCH compliant.  I don't understand that you
> "may" set to any valid TSCH setting but you "should" set them to what is
> specified later on.
>

> XV: You are right. We need to clarify this. I think we want to be clear
> here with the recommended frame format. I try to rephrase it.
>

> 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.

"The Source Address field, if present, shall contain the address of the
device sending the frame. When a
device has associated and has been allocated a short address (i.e.,
macShortAddress is not equal to 0xfffe or
0xffff), it shall use that address in preference to its extended address
(i.e., macExtendedAddress) wherever
possible. When a device has not yet associated to a PAN, it shall use its
extended address in all
communications requiring the Source Address field. If the Source Address
field is not present, the originator
of the frame shall be assumed to be the PAN coordinator or RFD-TX device,
and the Destination Address
field shall contain the address of the recipient, optional for RFD-TX
devices."

The destination address should be 0xFFFF as you indicate. (short address).
The source should be the node's extended address as per table 7-6 of
15.4-2015 (page 117) (12th row of the table).

> 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.

> 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.

>
> 4.6: How do you send in a join request using K2 (since it is a data frame
> and not an EB) when you don't have K2 yet?
>
> XV: Good point. we do not say how K2 is provisioned. This is something
that other documents in the WG should specify. In case K2 is
pre-provisioned this is solved, however, the zero or one touch approaches
should clarify this I guess. Do you have any suggestion for that? I
understand that considering only minimal, if K2 is not pre-provisioned, we
cannot join the network unless we use another mechanism.

> Jonathan
> [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| [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)

---

From: Jonathan Simon <[email-masked]>
Date: Tue, 13 Dec 2016 10:34:13 -0800

Xavi - please see my responses inline

> On Dec 12, 2016, at 11:35 PM, Xavi Vilajosana Guillen <[email-masked]> wrote:
> 
> Dear Jonathan,
> 
> 2016-12-12 22:48 GMT+01:00 Jonathan Simon <[email-masked] <mailto:[email-masked]>>:
> 4: The callouts in figure 1 don't exactly match what's in 4.5.2, namely that the timelsot and hopping template IDs (as opposed to the full sequence) are what is carried in the EB.
> 
> XV: The proposed configuration as advertised in the EB uses the default timeslot and hopping template ID. macTimeslotTemplateId = 0 and the default (macHoppingSequenceID = 0). Following your suggestion I will change the table to indicate this (macHoppingSequenceID = 0). Should we also keep the default sequence as a clarification (indicating that) [5, 6, 12, 7, 15, 4, 14, 11, 8, 0,  1, 2, 13, 3,  9, 10]?

JS - I don't think you need to call out the specific sequence. It should be sufficient to cite 802.14.5 section 6.2.10 which describes how it is generated.
>  
> 4.5: This paragraph could be interpreted as saying that a compliant node may choose particular settings, but must be able to understand all possible valid TSCH settings to be 6TiSCH compliant.  I don't understand that you "may" set to any valid TSCH setting but you "should" set them to what is specified later on.  
> 
> 
>  
> XV: You are right. We need to clarify this. I think we want to be clear here with the recommended frame format. I try to rephrase it. 

JS - thanks!
> 
>  
> 4.5.1:  
> 1) What is the EB source address size?   Presumably the dst is short FFFF, but it isn't stated. 
> 
> "The Source Address field, if present, shall contain the address of the device sending the frame. When a
> device has associated and has been allocated a short address (i.e., macShortAddress is not equal to 0xfffe or
> 0xffff), it shall use that address in preference to its extended address (i.e., macExtendedAddress) wherever
> possible. When a device has not yet associated to a PAN, it shall use its extended address in all
> communications requiring the Source Address field. If the Source Address field is not present, the originator
> of the frame shall be assumed to be the PAN coordinator or RFD-TX device, and the Destination Address
> field shall contain the address of the recipient, optional for RFD-TX devices."
> 
> The destination address should be 0xFFFF as you indicate. (short address). The source should be the node's extended address as per table 7-6 of 15.4-2015 (page 117) (12th row of the table). 

JS - I would think that if the JA beaconing has a short address, whether we use the association process discussed in 15.4 section  6.4.1 or not, then it should beacon using its short address (table 7-6 line 13), unless this makes it impossible for the JN to properly address its join request.   

In either case, I think an explicit callout to the address size in the text would be helpful. 
>  
> 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.

JS - to me this is policy.  If I as a vendor want to partition networks by PANID, then I can do so, and if I want to be able to join any PAN, I can do so.  I think a statement that setting to FFFF allows the JN to join any PAN is sufficient.
> 
> 
> 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?
> 

JS - thanks
> 
> 4.6: How do you send in a join request using K2 (since it is a data frame and not an EB) when you don't have K2 yet?
> 
> XV: Good point. we do not say how K2 is provisioned. This is something that other documents in the WG should specify. In case K2 is pre-provisioned this is solved, however, the zero or one touch approaches should clarify this I guess. Do you have any suggestion for that? I understand that considering only minimal, if K2 is not pre-provisioned, we cannot join the network unless we use another mechanism.

JS - I think you've hit on the point - frames should be secured with K2 once K2 is provisioned.  Then you can say that can be done a priori, or refer to Mališa's minimal security draft (or Michael's draft) as an example of how K2 get's provisioned. 

> 
>  
> Jonathan
> 
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> 
> -- 
> +34 646 633 681| [email-masked] <mailto:[email-masked]> | Skype: xvilajosana
> http://xvilajosana.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__xvilajosana.org&d=DgMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=3DOaKrDPnnwRLCTyzcyokUCKXuQps31_f-91AsGhUTY&s=Jla7GomFTQ4asauScSlvf8A3cngLcCeRuQRGXr0zU8U&e=>
> http://wine.rdi.uoc.edu/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__wine.rdi.uoc.edu_&d=DgMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=3DOaKrDPnnwRLCTyzcyokUCKXuQps31_f-91AsGhUTY&s=JoQxnNqyj0DjMWz2oE7AlLpOcDmcwgJV0_2lBP0WeAw&e=>
> 

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Dec 2016 14:15:47 +0200

> XV: According to 15.4 -2015

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

>     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...

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

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Fri, 16 Dec 2016 13:34:16 +0100

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