Re: [6tsch] What is missing slides -- input needed

[Xavier Vilajosana Guillen <[e-mail]>]

thanks Kris, this makes sense. Last Friday on the phone call we kept
semi-propietary "word" because there are some vendor specific blocks that
although are defined do not match between different  vendors (e.g way
schedule is distributed, at least in 15.4e). I think it is already defined
in WHart and ISA100.

The points you raise here are *very important* as this is what some of the
people that will be listening at the BoF will raise. So we have to be very
sure and be very careful on how we present this.  The idea of that
presentation is to outline what is missing and why we go for 6TSCH as a
"glue" for all the blocks.

so my comments inline:

1) they are based on TSCH, but not IEEE 802.15.4e TSCH.  4e did not adopt
either WiHART or ISA100, rather we/it came up with its own way of doing
things.
agree.. I clarify that. I also clarify that we go for defining how this
blocks are built on top of IEEE 802.15.4e. (right?)

2) I don't think that even the IETF gets to say that either of these
protocols is semi-proprietary anymore.  they are both IEC standards, and
they are interoperable across many vendors (of the wireless part).
In the case of IEEE 802.15.4e networks,  what about centralized scheduling
distribution or distributed scheduling. What about how security is
installed at each node, what  about QoS maintenance (including
overprovisioning, or cell reallocation). Maybe vendors inter-operate ( in
ISA100 and WHART, not so sure in 15.4e), but are aiming to propose a common
approach for that right?-- this is because the existing approaches (in the
case of 15.4e) are vendor specific ... I guess this is what we want to show
in the BoF, everything exists but we aim to find a common direction for
everyone.

3) all of the blocks are defined, and there aren't any missing.
These are complete standards-based solutions, they just aren't based
(completely) on IETF/IEEE standards.
well because some parts are not defined by IETF yet right? e.g messages on
the air to schedule one link with a neighbour.

X




On Mon, Jul 15, 2013 at 4:55 PM, Kris Pister <[e-mail]> wrote:

>  Xavi -
>  regarding the existing industrial implementations of TSCH, I'd say things
> a little differently.
> 1) they are based on TSCH, but not IEEE 802.15.4e TSCH.  4e did not adopt
> either WiHART or ISA100, rather we/it came up with its own way of doing
> things.
> 2) I don't think that even the IETF gets to say that either of these
> protocols is semi-proprietary anymore.  they are both IEC standards, and
> they are interoperable across many vendors (of the wireless part).
> 3) all of the blocks are defined, and there aren't any missing.
> These are complete standards-based solutions, they just aren't based
> (completely) on IETF/IEEE standards.
>
> ksjp
>
>
> On 7/15/2013 4:03 PM, Xavier Vilajosana Guillen wrote:
>
>  Dear all,
>
> I am working on what is missing? presentation slides. I want to go deep on
> the description of the following points. From what we listed last webex I
> developed the content but I need further input. Please update the following
> points with your thoughts: (all ideas are welcome, I will filter later!)
>
>
> Deterministic wireless over TSCH is demonstrated and available but
> semi-proprietary (TSMP, ISA100.11a, WiHART)
>    - Vendors have semi proprietary solutions as there are some blocks
> missing:
>        -These blocks are mainly on the upper Data Link Layer and its
> integration with the network layer.
>        -These blocks are mainly for the management and operation of the
> network
>        -missing blocks limit interoperability and mass scale adoption of
> the technology
>        -...
>  (give me some feedback here please)
>
>
> Same for RPL/TSCH with scalability to *1000s
>    -Vendor specific RPL proved to scale to 1000s (need info about that
> please!)
>    -TSCH networks proved to scale to 1000s
>    -Missing junction between both. RPL on TSCH.
>    -....
>
> (give me some feedback here please)
>
> Most IETF components exist (ZigbeeIP)
>     - ZigBee IP Supports 6LoWPAN for header compression, IPv6, PANA for
> authentication, RPL for routing, and TLS and EAP-TLS for security, TCP and
> UDP transport protocols.
>      -the building blocks exist but need to be fit to TSCH nature. Slotted
> and deterministic MAC layer, mapping of RPL routes to TSCH schedules (that
> globally build tracks.) -- Coexistence of Tracks and routes.
>
> (give me some feedback here please)
>
>
> Missing IETF architecture to put it all together
>    - Pascal Picture from architecture draft.
>     - Coexistence==Support of PCE/ Distributed in same architecture
>
> (give me some feedback here please)
>
>  Thanks!
> Xavi
>
>
> _______________________________________________
> 6tsch mailing [e-mail]://www.ietf.org/mailman/listinfo/6tsch
>
>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>