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

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Mon, 15 Jul 2013 16:03:51 -0700

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

---

From: Kris Pister <[email-masked]>
Date: Mon, 15 Jul 2013 16:55:39 -0700

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!)
>
>
>        -These blocks are mainly for the management and operation of 
> the network
>        -missing blocks limit interoperability and mass scale adoption 
> of the technology
>        -...
>     - 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.
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Mon, 15 Jul 2013 17:29:17 -0700

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 <[email-masked]> 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.
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>
>

---

From: Kris Pister <[email-masked]>
Date: Mon, 15 Jul 2013 18:02:41 -0700

I agree with you on all of this.  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.

I just have a pet peeve about the IETF calling anything that isn't IETF 
"proprietary".
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.

ksjp

On 7/15/2013 5:29 PM, Xavier Vilajosana Guillen wrote:
> 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:
>
> 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?)
>
> 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.
>
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Xavi -
>      regarding the existing industrial implementations of TSCH, I'd
>     say things a little differently.
>     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).
>     These are complete standards-based solutions, they just aren't
>     based (completely) on IETF/IEEE standards.
>
>     ksjp
>
>
>>     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
>>            -...
>>        -Vendor specific RPL proved to scale to 1000s (need info about
>>     that please!)
>>         - 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.
>>
>>     [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Qin Wang <[email-masked]>
Date: Tue, 16 Jul 2013 10:06:56 +0800

Hi Kris and Xavi,

For better understanding, can we distinguish Channel Hopping technology
from standards like ISA100, WirelessHart, and IEEE802.15.4e? According to
my understanding, ISA100 and WirelessHart employ Channel Hopping
technology, and also define other blocks or roles, like network manager,
security, to fully support industrial wireless. IEEE802.15.4e also employs
Channel Hopping  technology, but leaves some functions like link resource
reservation, schedule installation undefined, which results in a gap to use
the TSCH of IEEE802.15.4e with IPv6. Correct?

By the way, I remember TSCH is a name used in IEEE802.15.4e. WirelessHart
names it as "Channel Hopping" and ISA100 names it as "Slotted Channel
Hopping". So, if TSCH is used, it should imply the context of 802.15.4e.
Correct?

Thanks!

Qin

On Tue, Jul 16, 2013 at 9:02 AM, Kris Pister <[email-masked]> wrote:

> 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".
> 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.
>
> ksjp
>
>
> 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
>  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
>
>
>
>
>> 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!)
>>
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 16 Jul 2013 09:56:51 +0000

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 <[email-masked]<mailto:[email-masked]>> 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

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

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.

6tsch mailing list

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

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

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Tue, 16 Jul 2013 17:04:21 -0700

Hi Kris, Pascal, all,

some of the ideas drawn on this discussion are confusing me, sorry!. I like
to be very synthetic and write the main points as I have on my mind:

1-we aim to define how to run IPv6 on IEEE 802.15.4e TSCH.
2-An analogy of our work can be found on ISA100.11a and WiHART approaches
although the flavor is different as they don't use IETF building blocks. In
fact these blocks have not been though for IEEE 802.15.4e, so while people
may think the work is done, that is not case -- and this goes against our
work as we need to convince as well--
3-For our case, the blocks we need to use already exist (zigbee IP, etc...)
however the guidelines on how/what exactly glue together are *missing*.
4-The latest made vendors to implement their own variations of these blocks
that limit open-inter-operability or at least make it harder.
5-Our aim therefore is glue all together and glue it with the IP
architecture including what is on the backbone (ND, etc..)
    The main points that need to be glued together are:
         -Scheduling construction and maintenance:
                     -Centralized vs distributed: support for both
                     -Protocols to distribute the information: Based on PCE
architecture or distributed (RSVP like)
          -QoS and TE due to the cell nature of the underlying MAC layer
(including priorities, Traffic Classes, etc..)
          -RPL on TSCH, routes and best effort vs deterministic tracks:
support to mobility and fast commissioning
          -Security, key distribution, EB security
          -ND and backbone architecture
          -Packet switching and tunneling
          -management and maintenance of TSCH, seen as an orchestra
director based on underlying TSCH information (6top)

do I miss any points? :-)

thanks!
Xavi

are these points covering the topic? What else I'm missing.

On Tue, Jul 16, 2013 at 2:56 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  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".
> ****
> *[] *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. ****
>
>
> "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.
> ****
>
>
> ****
> *[] *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:****
>
> in WHart and ISA100.****
> 3) all of the blocks are defined, and there aren't any missing.  ****
>
> (completely) on IETF/IEEE standards.****
>
> the air to schedule one link with a neighbour. ****
>
> X****
>
> ** **
>
> ** **
>
> On Mon, Jul 15, 2013 at 4:55 PM, Kris Pister <[email-masked]> wrote:***
> *
>
> Xavi -
> ksjp ****
> ** **
> On 7/15/2013 4:03 PM, Xavier Vilajosana Guillen wrote:****
>
>   Dear all,
>
>        -...****
> (give me some feedback here please)****
>
>        ****
>
>
>    - Pascal Picture from architecture draft.****
>
>    - Coexistence==Support of PCE/ Distributed in same architecture****
>
>
> (give me some feedback here please)****
>
> Thanks!
> Xavi****
>
>
>
> ****
>
> _______________________________________________****
>
> 6tsch mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ** **
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>
> ** **
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 17 Jul 2013 09:42:24 +0000

Hello Xavi:

You can expect that people before you (Thomas for his draft and Maria Rita for 1.a) will have described the value of deterministic networking, the capabilities (and limits) of deterministic wireless, and the applications that will benefit from IPv6 over TSCH. So you'll be facing a crowd that already has a sense of a huge value for the real world, even for everyday life.

Your item 5 is the core of the question you are treating. I think that should be most of your time. At the end your 15 minutes, people must also be convinced that there is work to be done, understand what the scope of that work is, and that it is achievable within IETF classical operations. Your list for item 5 is perfectly in line with my thinking. I'd just add security and in particular commissioning and join process. You may want to use the architecture blocks or a subnet diagram as illustrations.

People should have gotten your item 1 in the welcome message from the chairs. As an intro, I'd insist that we aim at enabling new applications such as automation and metering over a converged IP network, for the well-known benefits that we found converging voice and video.
For item 2: It seems to me that the following sub-items are not controversial and position the missing links:
- existing standards found in smartgrid for metering use IETF building blocks but are not designed to operate on TSCH => missing deterministic aspect
- existing TSCH-based standards found in industrial are not compatible with one another => double OPEX, customer unsatisfaction
- they have their own versions of protocols and elements that the IETF defines (PCE/P, ICMP, DHCP, PANA, DTLS ...) => missing the benefits of sharing those building blocks
- but do not support other required functionalities that are available with IETF protocols (RPL, ND, CoAP..) => missing distributed routing
All in all, the lack of IETF building block hinders the network convergence that we are after.
I'd place your item 4 before your item 3, In there, you probably want to indicate that each of the existing solutions address a subset of the problem but that we want a single converged solution, in particular with a mix of centralized and distributed path computation, and a mix of track forwarding and routing.

At the end of item 4 (now 3), the audience would have a nice view of the landscape of existing -deployed- work as a side effect. This can be used to justify the bottom line of your item 3, clarifying that compared to what was already achieved and validated, what we are talking about is mostly the cement as opposed to the building blocks. This gives you an excellent intro for item 5, and you should be there around ETA = 5 minutes.

What do you think?

Notes:

In the thread we discussed that we do not want to use the term proprietary, so as to avoid an inappropriate tension and jitter.

Existing protocols, the fact that the concept validation and a large chunk of the technical engineering were done already, will be revisited in other sections, in particular 2a and 2b. So you can make a forward reference. So please save your time on those.

Cheers,

Pascal

From: Xavier Vilajosana Guillen [mailto:[email-masked]]
Sent: mercredi 17 juillet 2013 02:04
To: [email-masked]
Cc: Kris Pister; Thomas Watteyne; Pascal Thubert (pthubert)
Subject: Re: [6tsch] What is missing slides -- input needed

Hi Kris, Pascal, all,

some of the ideas drawn on this discussion are confusing me, sorry!. I like to be very synthetic and write the main points as I have on my mind:
1-we aim to define how to run IPv6 on IEEE 802.15.4e TSCH.
2-An analogy of our work can be found on ISA100.11a and WiHART approaches although the flavor is different as they don't use IETF building blocks. In fact these blocks have not been though for IEEE 802.15.4e, so while people may think the work is done, that is not case -- and this goes against our work as we need to convince as well--
3-For our case, the blocks we need to use already exist (zigbee IP, etc...) however the guidelines on how/what exactly glue together are missing.
4-The latest made vendors to implement their own variations of these blocks that limit open-inter-operability or at least make it harder.
5-Our aim therefore is glue all together and glue it with the IP architecture including what is on the backbone (ND, etc..)
    The main points that need to be glued together are:
         -Scheduling construction and maintenance:
                     -Centralized vs distributed: support for both
                     -Protocols to distribute the information: Based on PCE architecture or distributed (RSVP like)
          -QoS and TE due to the cell nature of the underlying MAC layer (including priorities, Traffic Classes, etc..)
          -RPL on TSCH, routes and best effort vs deterministic tracks: support to mobility and fast commissioning
          -Security, key distribution, EB security
          -ND and backbone architecture
          -Packet switching and tunneling
          -management and maintenance of TSCH, seen as an orchestra director based on underlying TSCH information (6top)

thanks!
Xavi

On Tue, Jul 16, 2013 at 2:56 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Kris and Xavi:

Please see below.

so my comments inline:

ksjp

6tsch mailing list

---

From: Kris Pister <[email-masked]>
Date: Wed, 17 Jul 2013 08:23:41 -0700

I agree with everything that Pascal wrote.

ksjp

On 7/17/2013 2:42 AM, Pascal Thubert (pthubert) wrote:
>
> Hello Xavi:
>
> You can expect that people before you (Thomas for his draft and Maria 
> Rita for 1.a) will have described the value of deterministic 
> networking, the capabilities (and limits) of deterministic wireless, 
> and the applications that will benefit from IPv6 over TSCH. So you'll 
> be facing a crowd that already has a sense of a huge value for the 
> real world, even for everyday life.
>
> Your item 5 is the core of the question you are treating. I think that 
> should be most of your time. At the end your 15 minutes, people must 
> also be convinced that there is work to be done, understand what the 
> scope of that work is, and that it is achievable within IETF classical 
> operations. Your list for item 5 is perfectly in line with my 
> thinking. I'd just add security and in particular commissioning and 
> join process. You may want to use the architecture blocks or a subnet 
> diagram as illustrations.
>
> People should have gotten your item 1 in the welcome message from the 
> chairs. As an intro, I'd insist that we aim at enabling new 
> applications such as automation and metering over a converged IP 
> network, for the well-known benefits that we found converging voice 
> and video.
>
> For item 2: It seems to me that the following sub-items are not 
> controversial and position the missing links:
>
> - existing standards found in smartgrid for metering use IETF building 
> blocks but are not designed to operate on TSCH => missing 
> deterministic aspect
>
> - existing TSCH-based standards found in industrial are not compatible 
> with one another => double OPEX, customer unsatisfaction
>
> - they have their own versions of protocols and elements that the IETF 
> defines (PCE/P, ICMP, DHCP, PANA, DTLS ...) => missing the benefits of 
> sharing those building blocks
>
> - but do not support other required functionalities that are available 
> with IETF protocols (RPL, ND, CoAP..) => missing distributed routing
>
> I'd place your item 4 before your item 3, In there, you probably want 
> to indicate that each of the existing solutions address a subset of 
> the problem but that we want a single converged solution, in 
> particular with a mix of centralized and distributed path computation, 
> and a mix of track forwarding and routing.
>
> At the end of item 4 (now 3), the audience would have a nice view of 
> the landscape of existing -deployed- work as a side effect. This can 
> be used to justify the bottom line of your item 3, clarifying that 
> compared to what was already achieved and validated, what we are 
> talking about is mostly the cement as opposed to the building blocks. 
> This gives you an excellent intro for item 5, and you should be there 
> around ETA = 5 minutes.
>
> What do you think?
>
> Notes:
>
> In the thread we discussed that we do not want to use the term 
> proprietary, so as to avoid an inappropriate tension and jitter.
>
> Existing protocols, the fact that the concept validation and a large 
> chunk of the technical engineering were done already, will be 
> revisited in other sections, in particular 2a and 2b. So you can make 
> a forward reference. So please save your time on those.
>
> Cheers,
>
> Pascal
>
> *From:*Xavier Vilajosana Guillen [mailto:[email-masked]]
> *Sent:* mercredi 17 juillet 2013 02:04
> *To:* [email-masked]
> *Cc:* Kris Pister; Thomas Watteyne; Pascal Thubert (pthubert)
> *Subject:* Re: [6tsch] What is missing slides -- input needed
>
> Hi Kris, Pascal, all,
>
> some of the ideas drawn on this discussion are confusing me, sorry!. I 
> like to be very synthetic and write the main points as I have on my mind:
>
> 2-An analogy of our work can be found on ISA100.11a and WiHART 
> approaches although the flavor is different as they don't use IETF 
> building blocks. In fact these blocks have not been though for IEEE 
> 802.15.4e, so while people may think the work is done, that is not 
> case -- and this goes against our work as we need to convince as well--
>
> 3-For our case, the blocks we need to use already exist (zigbee IP, 
> etc...) however the guidelines on how/what exactly glue together are 
> *missing*.
>
> 4-The latest made vendors to implement their own variations of these 
> blocks that limit open-inter-operability or at least make it harder.
>
>                      -Protocols to distribute the information: Based 
> on PCE architecture or distributed (RSVP like)
>
>           -QoS and TE due to the cell nature of the underlying MAC 
> layer (including priorities, Traffic Classes, etc..)
>
>           -RPL on TSCH, routes and best effort vs deterministic 
> tracks: support to mobility and fast commissioning
>
> On Tue, Jul 16, 2013 at 2:56 AM, Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Dear Kris and Xavi:
>
> Please see below.
>
> [] 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".
> */[] /*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.
>
>
> */[] /*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:
>
> - 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
>
> 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.
>
>
> 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
>
>     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.
>     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.
>
>     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.
>         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!)
>
>
>                -These blocks are mainly on the upper Data Link Layer
>         and its integration with the network layer.
>         PANA for authentication, RPL for routing, and TLS and EAP-TLS
>         for security, TCP and UDP transport protocols.

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Wed, 17 Jul 2013 11:11:22 -0700

Thanks Pascal, your detailed description makes things more clear now. I
will work on the slides so they guide us through this outline.

cheers!
Xavi

On Wed, Jul 17, 2013 at 8:23 AM, Kris Pister <[email-masked]> wrote:

>  Hello Xavi:****
> You can expect that people before you (Thomas for his draft and Maria Rita
> for 1.a) will have described the value of deterministic networking, the
> capabilities (and limits) of deterministic wireless, and the applications
> that will benefit from IPv6 over TSCH. So you’ll be facing a crowd that
> already has a sense of a huge value for the real world, even for everyday
> life.****
>
> ** **
>
> should be most of your time. At the end your 15 minutes, people must also
> be convinced that there is work to be done, understand what the scope of
> that work is, and that it is achievable within IETF classical operations.
> Your list for item 5 is perfectly in line with my thinking. I’d just add
> security and in particular commissioning and join process. You may want to
> use the architecture blocks or a subnet diagram as illustrations.****
>
> ** **
>
> chairs. As an intro, I’d insist that we aim at enabling new applications
> such as automation and metering over a converged IP network, for the
> well-known benefits that we found converging voice and video.****
>
> controversial and position the missing links:****
>
> blocks but are not designed to operate on TSCH => missing deterministic
> aspect****
>
> with one another => double OPEX, customer unsatisfaction****
>
> defines (PCE/P, ICMP, DHCP, PANA, DTLS …) => missing the benefits of
> sharing those building blocks****
>
> with IETF protocols (RPL, ND, CoAP..) => missing distributed routing ****
>
> All in all, the lack of IETF building block hinders the network
> convergence that we are after.****
>
> I’d place your item 4 before your item 3, In there, you probably want to
> indicate that each of the existing solutions address a subset of the
> problem but that we want a single converged solution, in particular with a
> mix of centralized and distributed path computation, and a mix of track
> forwarding and routing. ****
>
> ** **
>
> At the end of item 4 (now 3), the audience would have a nice view of the
> landscape of existing -deployed- work as a side effect. This can be used to
> justify the bottom line of your item 3, clarifying that compared to what
> was already achieved and validated, what we are talking about is mostly the
> cement as opposed to the building blocks. This gives you an excellent intro
> for item 5, and you should be there around ETA = 5 minutes. ****
>
> ** **
>
> What do you think?****
>
> ** **
>
> Notes:****
>
> ** **
>
> proprietary, so as to avoid an inappropriate tension and jitter.****
>
> ** **
>
> Existing protocols, the fact that the concept validation and a large chunk
> of the technical engineering were done already, will be revisited in other
> sections, in particular 2a and 2b. So you can make a forward reference. So
> please save your time on those.****
>
> ** **
>
> ****
>
> ** **
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* Xavier Vilajosana Guillen [mailto:[email-masked]<[email-masked]>]
>
> *Subject:* Re: [6tsch] What is missing slides -- input needed****
>
> ** **
>
> Hi Kris, Pascal, all,
>
> like to be very synthetic and write the main points as I have on my mind:*
> ***
>
> 1-we aim to define how to run IPv6 on IEEE 802.15.4e TSCH.****
>
> work as we need to convince as well--****
>
> etc...) however the guidelines on how/what exactly glue together are *
> missing*.****
>
> blocks that limit open-inter-operability or at least make it harder. ****
>
> architecture including what is on the backbone (ND, etc..)****
>
>     The main points that need to be glued together are:****
>
>          -Scheduling construction and maintenance:****
>
>                      -Centralized vs distributed: support for both****
>
>                      -Protocols to distribute the information: Based on
> PCE architecture or distributed (RSVP like)****
>
> (including priorities, Traffic Classes, etc..)****
>
> support to mobility and fast commissioning****
>
>           -Security, key distribution, EB security****
>
>           -ND and backbone architecture****
>
>           -Packet switching and tunneling****
>
> director based on underlying TSCH information (6top)****
>
>
>
> do I miss any points? :-)****
>
> ** **
>
> thanks!****
>
> Xavi****
>
> ** **
>
> ** **
>
> are these points covering the topic? What else I'm missing. ** **
>
> ** **
>
> [email-masked]> wrote:****
>
> Dear Kris and Xavi:****
>
>  ****
>
> Please see below.****
>
>  ****
>
> Our goal is to tell people how to run IPv6 on 15.4e.  ****
>