Subject: Re: [6tisch] [6tisch-security] WGLC comments on 6tisch-security

From: Rene Struik <[email-masked]>
Date: Tue, 17 Mar 2015 09:59:23 -0400

Dear colleagues:

FYI - there is no such thing as a production network vs. join network: 
there is only one PAN. Please also see Section 1.1, Item #5, pp. 3-4 of 
draft-struik-6tisch-security-architectural-considerations-01, part of 
which is excerpted here:

    This does not mean, however, that these nodes operate in a separate
    PAN, though, since incoming frame processing relies on filtering on
    a single destination PAN Identifier (see 802.15.4-2011, 5.1.6.2),
    which implies that the neighbor node can only be part of a single
    PAN (802.15.4-2011 does not know the concept of "multiple PAN
    instances"). This also implies that there is no mechanism within
    802.15.4 to designate frames for "join" purposes or other special
    uses (as Wireless HART seems to do with enhanced beacon frames).

Best regards, Rene

On 3/17/2015 6:58 AM, Tero Kivinen wrote:
> Jonathan Simon writes:
>> Linear has 1000’s of TSCH networks running, and I was an author of
>> the standard so I can speak to this - the background is that since
>> 802.15.4e was a MAC amendment, there was a lot of pressure to remove
>> what was thought of as “upper layer” behavior.  So we have minimal
>> primitives to send synchronization, timeslot, hopping sequence,
>> link, and slotframe information over the air using Enhanced Beacons,
>> timing feedback through enhanced acknowledgements, and primitives
>> and to assign MAC properties by a Management layer (the MLME), but
>> we don’t have a general 4e mechanism for assigning slotframes and
>> links over the air.  The intent was the EBs are used for initial
>> synchronization and temporary joining link assignment, but that the
>> “full" link/slotframe configuration is left to a higher layer to
>> deal with, i.e. there needs to be an application layer that defines
>> the protocol - we use data frames and basically reuse the IE format
>> from the EB in our application layer.  6TiSCH is proposing to use
>> CoAP.
> But there might also be nodes which only use shared slots, and which
> are mostly sleeping, thus might not keep track of time exactly, thus
> they might benefit from using EBs also in production network. Or are
> such devices always assumed to be joining and leaving the network for
> every time they send frames.
>
> Also EB frames are something that can be used for time
> syncronmization, i.e. if your timing parent happens to be sending
> beacons, you can listen to them and stay in sync with the timing.
>
> So I would think EBs do have use in production network too, not only
> for joining devices.
>
> On the other hand as the protocol in higher layer managing the full
> link/slotframe configuration is not yet defined, we do not know what
> it will be using...
>
> But your explanation helped a lot, and reading the
> draft-ietf-6tisch-tsch also helped a lot, but in general before we
> have the upper layer protocol defined we cannot say whether EBs are
> used in production network or not...

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363