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) <
pthubert@cisco.com> wrote:

>
>
> Hello Maria Rita
>
>
>
> *From:* Maria Rita PALATTELLA [mailto:maria-rita.palattella@uni.lu]
> *Sent:* vendredi 25 novembre 2016 11:40
> *To:* Thomas Watteyne <thomas.watteyne@inria.fr>; pat.kinney@
> kinneyconsultingllc.com
> *Cc:* Pascal Thubert (pthubert) <pthubert@cisco.com>; 6tisch <
> 6tisch@ietf.org>; Xavi Vilajosana Guillen <xvilajosana@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
> <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.watteyne@inria.fr]
> *Sent:* Tuesday, November 22, 2016 7:45 PM
> *To:* pat.kinney@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.kinney@kinneyconsultingllc.com <
> pat.kinney@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
>
> pat.kinney@kinneyconsultingllc.com
>
>
>
> On 22, Nov2016, at 5:57, Maria Rita PALATTELLA <
> maria-rita.palattella@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) [pthubert@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-bounces@ietf.org <6tisch-bounces@ietf.org>] *On
> Behalf Of *Xavi Vilajosana Guillen
> *Sent:* mardi 22 novembre 2016 11:58
> *To:* Maria Rita PALATTELLA <maria-rita.palattella@uni.lu>; tisch <
> 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| xvilajosana@uoc.edu | Skype: xvilajosana
>
> 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
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> 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
>
> _______________________________________
>

-- 
_______________________________________

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
_______________________________________