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

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear Kris and Xavi:

Please see below.

I agree with you on all of this.
[] Same here; I think that Xavi's text is well-balanced. And we will not have time for controversies at the BoF so this discussion on avoiding them is critical.
We're trying to make a fully IETF/IEEE compliant standard, and there are definitely some missing blocks.  We can point to some industrial standards that have some similarities, to say "see, it can work really well, but they don't do us any good because they aren't based on IEEE 15.4e".
Our goal is to tell people how to run IPv6 on 15.4e.

[] Yes, that is the primary goal. Hopefully the architecture that we are producing applies to all sorts of TDM-based LLNs. The key here is to leverage the new level of guarantees and services that Time Slotting enables.

I just have a pet peeve about the IETF calling anything that isn't IETF "proprietary".
[] It's true that IETF has its view of open standards that is useful for discussion within the IETF, but 1) your words are not true to that definition (see section 7 of RFC 2026) and 2) it is not just the IETF that redefines the term for its own use; it's really all sorts of countries and organizations, often referring to the way the standard was elaborated and is made available, in particular with regards to fee policies, IPR rules, or open source implementations. Still I agree that this time and place are not for fighting on the definition of such terms. If the IETF term is not the right tool for our discussion then let us be more specific on why we can't just live with a status quo.
The existing protocols:
- are not fully compatible with IEEE 15.4e which came later
- are not compatible at all at any layer though similar on paper
- are not implemented as open source
- do not define all the required interfaces and protocols for operation over the Internet (e.g. interface to the WiHART AP or ISA100.11a backbone router operations over the backbone)
- have their own versions of protocols and elements that the IETF defines (PCE/P, ICMP, DHCP, PANA, DTLS ...) and for which open source implementations are available
- do not support other functionalities that are available with IETF protocols (RPL, ND, CoAP..).
- ... ?
Just like proprietary RPL implementations over TSCH, industrial standards demonstrate both the need and the feasibility of our work and show the way.

And I don't think that we should try to point to WiHART and ISA100 and say "they are missing some blocks" because they are outside of our scope anyway.
[] Agreed. At the same time, we need to explain why we're not all set with what exists already on the market. We must make sure that we do not make it look like criticizing the excellent work that is really our foundation. On the contrary we want to strongly express that reuse all the concepts that those protocols have demonstrated but will base the devices interactions on existing IETF (open ; ) standards when possible.
Makes sense?
Pascal
On 7/15/2013 5:29 PM, Xavier Vilajosana Guillen wrote:
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]<mailto:[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 list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/6tsch


_______________________________________________
6tsch mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6tsch