Thomas, I will join the call. Sure, I can shortly summarize the current discussion. I also believe there is no real need to have slides. Maria Rita ________________________________ From: Thomas Watteyne [thomas.watte...@inria.fr] Sent: Friday, December 09, 2016 3:17 PM To: Pascal Thubert (pthubert) Cc: Maria Rita PALATTELLA; pat.kin...@kinneyconsultingllc.com; 6tisch; Xavi Vilajosana Guillen Subject: Re: [6tisch] Adding CCA to the terminology draft
Maria Rita, Will you be on the call in 45min? Can you provide us with a quick update on what was agreed upon? No slides needed I believe, unless you want to put some together quickly and present from your computer. Thomas On Fri, Nov 25, 2016 at 12:10 PM, Pascal Thubert (pthubert) <pthub...@cisco.com<mailto:pthub...@cisco.com>> wrote: Hello Maria Rita From: Maria Rita PALATTELLA [mailto:maria-rita.palatte...@uni.lu<mailto:maria-rita.palatte...@uni.lu>] Sent: vendredi 25 novembre 2016 11:40 To: Thomas Watteyne <thomas.watte...@inria.fr<mailto:thomas.watte...@inria.fr>>; pat.kin...@kinneyconsultingllc.com<mailto:pat.kin...@kinneyconsultingllc.com> Cc: Pascal Thubert (pthubert) <pthub...@cisco.com<mailto:pthub...@cisco.com>>; 6tisch <6tisch@ietf.org<mailto:6tisch@ietf.org>>; Xavi Vilajosana Guillen <xvilajos...@uoc.edu<mailto:xvilajos...@uoc.edu>> Subject: RE: [6tisch] Adding CCA to the terminology draft Thomas, all, I have gone through the list of terms in the terminology draft, and I agree there are some terms that we MAY want to DELETE. In particular: a) terms specifying forwarding models, defined in the architecture draft, but never used afterward in any other draft. And moreover not in the current std. scope of 6TiSCH - 6F: IPv6 Forwarding - FF: 6LoWPAN Fragment Forwarding - TF: Track Forwarding [Pascal] agree to remove b) confusing terms - CDU matrix - concept related to chunk, but never used, and it created a lot of confusion in the group in the past. We can keep chunk, without the need of CDU [Pascal] I’d keep that one, we have not really started the work related to it, may be useful c) terms related to other RFCs, drafts, not 6TiSCH specific - ARO - DAR/DAC - EAR - NEAR [Pascal] agree to remove d) Generic Terms, not really needed for understanding 6TiSCH - Communication Paradigm - Interaction Model - Interference Domain - NME - GMPLS - MAC - QoS [Pascal] agree to remove e) terms introduced but afterward not used anymore (such those related to the queue model) - I-MUX module - MUX module - Operational network key [Pascal] agree to remove Moreover, we could also simply: i) the definition of bundle, currently quite long, by keeping only the first part: "A group of equivalent scheduled cells, i.e. cells identified by different [slotOffset, channelOffset], which are scheduled for a same purpose, with the same neighbor, with the same flags, and the same slotframe. The size of the bundle refers to the number of cells it contains. For a given slotframe length, the size of the bundle translates directly into bandwidth. A bundle represents a half-duplex link between nodes, one transmitter and one or more receivers, with bandwidth that amounts to the sum of the cells in the bundle." [Pascal] The latter sentence is incorrect; like a schedule, a bundle is a local abstraction and it is not a concern of this node whether it is a sole sender or listenenr on it. “ A bundle is a local abstraction that represents a half-duplex link for either sending or receiving, with bandwidth that amounts to the sum of the cells in the bundle." ii) the current definition of deterministic network: "A Deterministic Network supports traffic flows with communication patterns that are known a priori. Thus, routing paths and communication schedules can be computed in advance, in a fashion similar to a railway system, to avoid losses due to packet collisions, and to perform global optimizations across multiple flows. A deterministic network can allocates the required resources (buffers, processors, medium access) along the multi-hop routing path at the precise moment the resources are needed." with the following: " In the context of 6TiSCH, a network where the packet delivery rate, end-to-end latency and energy consumption of the nodes can be predicted." [Pascal] We can never guarantee a PDR : ) I’d say that the generic concept is defined in https://tools.ietf.org/html/draft-ietf-detnet-architecture and that with 6TiSCH it is implemented by reserving Tracks which guarantee an end to end latency and optimize the PDR for well-characterized flows Finally, can someone in the 6TiSCH-security team provide some explenation of the "Operational Network" definition: "A IEEE802.15.4e network whose encryption/authentication keys are determined by some algorithms/protocols. There may be network-wide group keys, or per-link keys." It is not so clear the link between the term and its definition. Thanks. Once the group agree in applying the proposed changes, I can update the draft accordingly. Thank you. Best Regards, Maria Rita ------------------------------------------------------------------------------ From: Thomas Watteyne [thomas.watte...@inria.fr<mailto:thomas.watte...@inria.fr>] Sent: Tuesday, November 22, 2016 7:45 PM To: pat.kin...@kinneyconsultingllc.com<mailto:pat.kin...@kinneyconsultingllc.com> Cc: Maria Rita PALATTELLA; Thubert Pascal; 6tisch; Xavi Vilajosana Guillen Subject: Re: [6tisch] Adding CCA to the terminology draft Thanks Maria Rita for agreeing to add the term. Can I ask you to do the edit in the repo? About last call, while I agree with the definitions in there, we MAY want to remove some, or at least do a sanity check. Maria Rita, could I ask you to go through the list and make some recommendations? Thomas On Tue, Nov 22, 2016 at 2:25 PM, pat.kin...@kinneyconsultingllc.com<mailto:pat.kin...@kinneyconsultingllc.com> <pat.kin...@kinneyconsultingllc.com<mailto:pat.kin...@kinneyconsultingllc.com>> wrote: I think that we need to remember that in some cases CCA is necessary for minimal, such as shared slots, but also when there are multiple instances of 6tisch being used by non-coordinated entities. Regardless, "In the TSCH mode, backoff is calculated in shared links, so the CSMA-CA aUnitBackoffPeriod is not used.” The CCA mode may be enabled for TSCH by the TSCH-MODE.request where the TschMode may be enabled and also the TschCca may be enabled Pat Kinney Kinney Consulting LLC IEEE 802.15 WG vice chair, SC chair ISA100 co-chair, ISA100.20 chair O: +1.847.960.3715<tel:%2B1.847.960.3715> pat.kin...@kinneyconsultingllc.com<mailto:pat.kin...@kinneyconsultingllc.com> On 22, Nov2016, at 5:57, Maria Rita PALATTELLA <maria-rita.palatte...@uni.lu<mailto:maria-rita.palatte...@uni.lu>> wrote: Xavi, sure, we can add CCA among the terms. Pascal, about the last call for the terminology draft, I believe we can go for it. Maybe we only need to check first if there are new terms coming from the 6P and SF0 drafts (but I doubt, because we checked already last time), or from the latest security related drafts (draft-vucinic-6tisch-minimal-security, and draft-richardson-6tisch-dtsecurity-secure-join). @Malisa and Michael: do you see any term missing? you would like to add? Thank you Maria Rita ________________________________ From: Pascal Thubert (pthubert) [pthub...@cisco.com<mailto:pthub...@cisco.com>] Sent: Tuesday, November 22, 2016 12:28 PM To: Xavi Vilajosana Guillen; Maria Rita PALATTELLA; tisch Subject: RE: [6tisch] Adding CCA to the terminology draft That would be good. Also: as discussed at the IETF meeting, we also need to trigger last call for the terminology draft, which will cause minimal to be held for publication otherwise. Maria-Rita, do you think we are ready for that? Take care, Pascal From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Xavi Vilajosana Guillen Sent: mardi 22 novembre 2016 11:58 To: Maria Rita PALATTELLA <maria-rita.palatte...@uni.lu<mailto:maria-rita.palatte...@uni.lu>>; tisch <6tisch@ietf.org<mailto:6tisch@ietf.org>> Subject: [6tisch] Adding CCA to the terminology draft Dear Maria Rita, I would like to suggest adding the following definition to the terminology draft so we can point to it from minimal. CCA: Clear Channel Assessment. Mechanism defined in <xref target="IEEE802154-2015"/>, section 6.2.5.2. In a TSCH network, CCA can be used to detect other radio networks in vicinity. Nodes listen before sending to detect other ongoing transmissions. Because the network is synchronized, CCA cannot be used to detect colliding transmission within the same network. let me know if this is possible. thanks! X -- Dr. Xavier Vilajosana Guillén Research Professor Wireless Networks Research Group Internet Interdisciplinary Institute (IN3) Universitat Oberta de Catalunya +34 646 633 681<tel:%2B34%20646%20633%20681>| xvilajos...@uoc.edu<mailto:xvilajos...@uoc.edu> | Skype: xvilajosana http://xvilajosana.org<http://xvilajosana.org/> http://wine.rdi.uoc.edu/ Parc Mediterrani de la Tecnologia Av. Carl Friedrich Gauss, 5. Edifici B3 08860 Castelldefels (Barcelona) _______________________________________________ 6tisch mailing list 6tisch@ietf.org<mailto:6tisch@ietf.org> https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list 6tisch@ietf.org<mailto:6tisch@ietf.org> https://www.ietf.org/mailman/listinfo/6tisch -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com<http://www.thomaswatteyne.com> _______________________________________ -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com<http://www.thomaswatteyne.com> _______________________________________
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
