Minutes for 6TISCH at IETF-93
minutes-93-6tisch-1
| Meeting Minutes | IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG | |
|---|---|---|
| Date and time | 2015-07-21 11:00 | |
| Title | Minutes for 6TISCH at IETF-93 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2015-07-30 |
minutes-93-6tisch-1
## THIS IS A DRAFT!!! ## # Minutes, 21 July 2015 main, 6TiSCH WG # Note: timestamps in PST. Connection details ------------------ * Webex: * Etherpad: http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true * Topic: 6TiSCH Bi-Weekly * Time: 13:00 CET, 4:AM Pacific Daylight Time (San Francisco, GMT-07:00) Resources --------- * Webex recording: TODO * Wiki: https://bitbucket.org/6tisch/meetings/wiki/150721_ietf93_prague.md * Slides: https://bitbucket.org/6tisch/meetings/src/master/150721_ietf93_prague/slides_150721_ietf93_prague.ppt * Prez skeleton: https://bitbucket.org/6tisch/meetings/src/master/150721_ietf93_prague/ietf93_template.ppt Chairs Summary ---------------- 6TiSCH met on Tuesday afternoon for 2 hours with a packed agenda and a pretty full room, Brian and Ralph attending. Highlight: - Ralph’s review of the architecture indicated that the document mixed architecture and specification level aspects, while not covering all the architecture items in 6TiSCH scope. The discussion led to a proposal that the WG takes back the doc till the architecture is complete, which is probably the lifetime of the WG. The doc would go still down to what Ralph describes as a specification level, but would include security, dynamic schedule and DetNet application. This will be confirmed on the ML - The first 6TiSCH Plugtest was a huge success that validated the 6TiSCH minimal draft. Some changes were proposed and supported at the WG, namely suppression of a reference to the architecture in the security section, the MUST for non-storing mode RPL and the computation of the step of Rank by RPL. Other changes were more discussed like the way issues in 802.15.4e are avoided, and the MUST for storing mode RPL. All will be confirmed on the ML. Brian confirmed that the dissector outputs that were used for the plugtest could be placed in annex in the document if the WG thinks it appropriate. The draft will be pushed for IESG review as soon as the issues above are resolved. - The Interface and CoAP drafts progressed but are blocked by the normative reference to COMI and potentially CoOL. With this in mind, the WG cannot complete that work and must hold it. In the meantime, implementers were asked to provide feedback on the document from their implementation experience. - Non chartered work was presented on dynamic scheduling, use of CoAP for MAC level signaling and DetNet. Discussion started at the mike and are now continuing on suggesting to use 802.15.9 as the transport for CoAP, mostly due to the limited naming space in IEs. - It results that the group is ready to take new work in. The work is mostly identified and relates to dynamic scheduling, security and interface with DetNet, under the general umbrella of the architecture documents. Re-chartering discussions should start soon. %====================================== START RAW MUNITES ====================================== TODO: publish pcap suggestion from Carsten: define a Content-type (?) for 6TiSCH Planned agenda [13.00] Intro and Status [5min] (Chairs) * Note-Well, Blue Sheets, Scribes, Agenda Bashing * Drafts progression vs. plan [13.05] 6TiSCH Plugtests report [15min] * Organization report (Miguel Angel Reina Ortega) * Tools: * <draft-munoz-6tisch-minimal-examples> (Dominique Barthel) * Golden Device (Tengfei Chang) * Summary test cases, anonymized success highlights (Maria Rita Palattella) * Lesson learned (Thomas Watteyne) [13.20] Hackathon report [5min] (Maria Rita Palattella) [13.25] <draft-ietf-6tisch-architecture-08> [15min] * INT-DIR review and resolutions (Pascal Thubert) [13.40] <draft-ietf-6tisch-minimal-10> [30min] * RPL artifacts and 6LoRH at 6lo (Gabriel Montenegro, 5min) * Example format and security section (Xavi Vilajosana, 20min) * Shepherd status and IESG submission (Pascal Thubert, 5min) [14.10] <draft-ietf-6tisch-6top-interface-04> [10min] * Update on changes (Qin Wang, Xavi Vilajosana alt.) * Readiness assessment (all) [14.20] CoMI News [15min] * <draft-vanderstok-core-comi-07> and <draft-vanderstok-core-patch-01> in 6TiSCH context (Peter van der Stok, 10min) * Michel's Proposal to avoid hash collisions (Michel Veillette, 5min) [14.35] Distributed scheduling [10min] * <draft-dujovne-6tisch-on-the-fly-06> (Diego Dujovne) * <draft-wang-6tisch-6top-coapie-01> (Qin Wang) [14.45] DetNet and dependencies [10min] * BoF news (Lou Berger) * <draft-wang-6tisch-track-use-cases-01> (Chonggang Wang) * <draft-thubert-6tisch-4detnet-01> (Pascal Thubert) [14.55] Re-chartering kickstart and AOB (chairs) [5min] ------- Meeting Notes ------- [13.00] Intro and Status [5min] (Chairs) * Note-Well, Blue Sheets, Scribes, Agenda Bashing - Pascal goes through agenda * Drafts progression vs. plan - "minimal" draft passed Plugtest, deemed ready for shipment - "architecture" just returned from IESG review, needs rework. - "coap ie" and "6top interface" need to move forward Comments on the agenda ? none. Agenda is approved. [13.06] 6TiSCH Plugtests report [15min] * Organization report (Miguel Angel Reina Ortega) - organised by ETSI and 6Tisch, support from OpenMote. - 4 independent implementations. 23 test sessions plus single hop and multi-hop - Plugtest agenda over 2 days. - Sunday hackaton - Test plan: 6Tisch minimal, over 15.4 radios. 6LoWPAN, RPL, ICMPv6. - golden hardware/software provided to participants ahead of time, allowed them to do pre-testing at home. - used wireshark dissector for debugging - Miguel shows list of 18 tests. - 93.7% success rate on tests that were executed. - not so good on RPL because not implemented the same by all (storing only, non-storing only). - Thomas: "minimal" should have a MUST for at least one of the modes, otherwise not interoperable! - Thomas: opnions? - Xavi: RPL is a MUST - Pascal: Is it a problem of code space? - Xavi: It is a problem of the table size in the mote. Code size of having both modes not a problem. - Michael: what was the interop issue? Thomas: were DAG roots that only did storing modes and nodes only non-storing, or vice-versa, hence could not interoperate. - Randy Minimal does not specify a plugtest procedure for RPL - Tero: 6550 has to support both? Pascal: Leaves it open. Tero: then pb with 6550? - Pascal: There are many implementations. storing and non-storing are part of the many parameters to define - Tero: You must implement both but used according to the profile. - Oleg Ham: 6550 says either mode, would "minimal" contradict 6550 if says MUST to both? - Pascal: RPL is general, but here we need to specify a minimal implementation. - Robert Cragie: if sotring mode is a MUST, then pb for modes that have little RAM, especially close to the root. - Miguel: future plugtest roadmap presented: 2-4 Feb 2016 (Paris) and July 2016 (IETF Berlin) [tentative] - Michael R: make public the dates at which the Plugtest dates will be made public (!) - Miguel: We are going to start planning starting next week to confirm the dates. * Tools: * <draft-munoz-6tisch-minimal-examples> (Dominique Barthel) - New draft. Wireshark dissector output examples - Jonathan Munoz updated the 15.4 Wireshark dissector to dissect 15.4e TSCH amendments needed for 6TiSCH. Not the full 15.4e. - ran OpenWSN implementation 6tisch-minimal, simple 3 node linear topology and simple scenario. Copy-pasted the results from Wireshark when running the code. - Simple examples - WIP - Is this useful? Should it be published? * Michael: Would like to be able to get the PCAP files, not just the text output of Wireshark. * Dominique: will do * Robert Cragie: has the dissector been pushed back to the Wireshark site? * Dominique: not yet, will do. Already publically available, though, right now, on the 6TiSCH bitbucket. * Brian Haberman: RFC or living document? Other examples as wikipage. Move it to a wiki, it's minimum overhead. * Pascal: To the annex of minimal? * ..?:Requirements, use cases, frame examples: end of protocol specification * DR Raza: Other implementations available? * Thomas: OpenWSN is open source. Per ETIS rules, we cannot publish the name of the entreprises or implementation. * Golden Device (Tengfei Chang) * Summary test cases, anonymized success highlights (Maria Rita Palattella) * Lesson learned (Thomas Watteyne) [hh:mm] Hackathon report [5min] (Maria Rita Palattella) [13:32] <draft-ietf-6tisch-architecture-08> [15min] * INT-DIR review and resolutions (Pascal Thubert) * Pascal: Provided a document with different levels of understanding. Not same depth. This document does not cover completely 6tisch. We will use volumes, e.g. dynamic scheuling, detnet in the context of 6tisch for the IESG review. * Because currently does not fill the expectation of the reader which is a global architecture, so shall we restructure it? * Show minimal implemented. Show this could be done. Pick different items from different groups and see if they fit and if there is anything else missing. * Brian Haberman: Architectures: you never know if it is going to change. This document can be used to implement 6tisch now. It was written in small pieces. * Ralph Droms: Refer to Brian, agree with him on supporting implementation. This document should be a wikipage but not for publication. * Integrating with detnet and references to components/blocks in detnet. The expectation on the components to know which go here and which go to detnet * Thomas (co-chair): One way could be to make a simple document with high level architecture only * Pascal: The architecture should represent what is being developed. Wanted to describe way to use RPL and 6LoWPAN together. * Ralph: putting together protocols is a spec document, not an arch document. Needs to be consistent through the document as to what is is. * Ralph: arch describes boxes and interfaces, not necessarily sepcifying what's inside or parameters. The later belongs to spec document. * Brian: one way of doing this is wait until all building blocks documented, document is architecture document. But right now, there are TBDs and future work. * Pascal: to summarize, reopen the document, keep it active until all pieces are done. * Ralph: arch part should be understandable by somebody that does not know RPL, but knows waht a routing protocol is. * Thomas: Shall we hum? * Pascal: Humm. People who think we should reopen the doc, keep it active in the WG and ship after WG work is complete. * Pascal: humm for keeping pushing it through the IESG? none head * Pascal: humm for dropping the doc altogether? none heard * Pascal: so we take the doc back * Qin Wang in Jabber room: some elements not on the charter. * Pascal: We cannot finish this document unless we charter the documents not chartered yet. * Brian: you guys confirm consensus on mailing list. If yes, I will send the doc back to you. * Pascal: Come to 6lo to help solve RPL issues. [13:52] <draft-ietf-6tisch-minimal-10> [30min] Actually version -11 * Example format and security section (Xavi Vilajosana, 20min) different interpretations of 15.4e fields, had to agree before Plugtest. define key for interoperability tests * Subir Das: last line in Security section refers to 6TiSCH arch doc, needs editing * Subir: what doc to refer to regarding security * Brian: So... you can t live with crossed references. Put security in this document or build another security document * Subir: We can live with the phrase saying it is out of scope * DR Raza: Agree to drop the sentence. It can be understood without the reference. * Brian: agree to drop the sentence. * Pascal: humm if opposed to dropping this snetence?none heard. Will confirm on mailing list. * Malisa: add that implementation MUST have security implemented. * Xavi resume presentation. RPL OF0. Rank computation. * Pascal: typo in the slides. Proposal is actually 3*ETX-2. * Pascal explains: a good link is ETX=1; With 2*ETX, can't have step rank of 1. Humm if disagree? none heard. * Tero: (one slide back to specific 802.15.4 headers) Table 2 is wrong, features don' t work in 15.4. You cannot have two PANIDs with the new version. * Propose that PANID should be 1. * Pascal: with -2011, we know it's broken. * Tero: no, in -2011 was OK two PANIDs worked. * Tero: 15.4e-2012 got it wrong. * Thomas: what do you recommend? * Tero: ???? * Pascal: technology works. But this doc refers broken specs. * Tero: why compressed PANID O? What's the use? * Thomas: We are talking about 1 bit in a header, what is the meaning of that bit. * Tero: Wireshark will parse frame, won't be able to parse this because this bit wrong. * Subir Das: Why don' t just accept the mechanism. This draft should recommend this. let the text go through and add the reference when the IEEE standard is finished (november) * Raza: for the "last sentence", cite 802.15.9 that does key management for .... * Pascal: please Subir propose your idea on the mailing list, and will confirm. Then ship. * RPL artifacts and 6LoRH at 6lo (Gabriel Montenegro, 5min) * Shepherd status and IESG submission (Pascal Thubert, 5min) [hh:mm] <draft-ietf-6tisch-6top-interface-04> [10min] * presented by Xavi on behalf of Qin * Update on changes (Qin Wang, Xavi Vilajosana alt.) in Yang model, modified the SecurityAttributes. Comments received from M Richardson. minor changes, grouping of attributes. * remove commands section * Check if YANG model to cover attributes (read/write) * Use the format to negotiate for distributed scheduling * Randy: Did you say one PIB or any PIB? * Readiness assessment (all) will come back to this after COMI's presentation [14:17] CoMI News (work done at Core, presented for information here) [15min] * <draft-vanderstok-core-comi-07> and * Peter: Issues being discussed on the ML. * Small services and small clients. All the items taken into account, including hashes. * Discussion points: name hashing and patch content format. * Hash clash probability very low, but incrementing with the number of names * Reduce impact of rehash handling; client will only know of a hash clash when it uses that hash. * assumption that no clash within module. * server will provide info on modules involved in the clash; suggest some servers are managed, have fixed names, others unmanaged, only have hashes. <draft-vanderstok-core-patch-01> in 6TiSCH context (Peter van der Stok, 10min) * Add a PATCH command to CoAP. * patch format 1: use CBOR or JSON format, but need additional rules to do it. * Carsten: Microoptimization. you need measurements. is it possible to get a prediction? * Thomas: yes. Some elements can be accessed with less cost depending on the access frequency. * Implementers provide feedback. * Peter: if more rules, put in Comi document or -patch? * Thomas: This must be discusseed in CoRE * Peter: CoRE tells how to send a patch, there are existing media types or creating your own. * Michel's Proposal to avoid hash collisions (Michel Veillette, 5min) COnstrained Objects Language (COOL) * could be used beyond management. * avoid hash clashes by using managed numbers. * A hash clash might results in acting upon an unwanted resource. * The client must know the notification source * Dynamic loading of a new module may create hash clash. * Comi clients need to store large tables. * Pascal: Constrained devices. what if don't have space for this. The tables use memory. * Michel: Unmanaged vs. Managed. There is no solution for the memory problem. * Proposal is 20 bits registered module IP, and 10 bits assigned YANG ID. * Modules registered in IANA, leave 3/4 of space reserved for future use. * Goes through a GET example. * Support Patch, stream based on RFC5277, resource discovery, etc.. * TW: is cool and optimization of COMI? Will you update COMI with the ideas in CooL? * Peter VDS: we did not see a.. * Thomas: we need a flexible solution. * PT: Make clear what is a must and what is not. In terms of using clash vs IDs * Peter: might be useful to have packet sizes, payload sizes etc... How to choose and asses on the choice. [14:40] Distributed scheduling [10min] * <draft-dujovne-6tisch-on-the-fly-06> (Diego Dujovne) OTF Update. * new version 06 * distributed scheduling * event triggered and parametrized allocating policy. Accessing to it through CoAP * When to trigger the allocation and the number of requests that it will do to allocate the cells. This is fundamental in terms of performance and energy consumption * 2 associated bundles: only on the outgoing bundle. Reservations are only performed in the outgoing bundle. * 6top will negotiate the cells with the corresponding neighbors. * Default algorithm defined. * if incoming cells > outgoing cells then the mechanism triggers a reservation of some cells. In the opposite case it removes cells. There is a threshold to avoid churn. * Next steps: * How to deal with l2 tracks? Not only the best effort track * uses shared soft cellls between nodes. * Thomas: any implementation of this (next plugtest in mind)? Diego: soon in OpenSWN. Hopefully for Berlin. * <draft-wang-6tisch-6top-coapie-01> (Qin Wang) * Thomas presents on Qin's behalf. * fixed CoAP IE to be paylod IE.T * Tero: only 16 payload IEs, already 4 allocated. <<<missed the last comment>>> * Tero: will send pointer * Thomas: Do we publish the interface now or shall we wait for CoMi to provide feedback? * We have a dependency here. * Pascal: We need a normative reference. * Peter VDS: use of RPC. Recommend to wait till Yokohama. [14.51] DetNet and dependencies on 6TiSCH [10min] * BoF news (Lou Berger) * Lou Berger: prep work done here, BOF well attended, polling resulted in lots thinking good stsuff, half willing to do work. * expect good collaboration between the groups. * Randy: Asks for the BOF slides. said wired nework? Pascal: Detnet, not here, won't comment. * Pascal: Nothing is casted in stone * <draft-wang-6tisch-track-use-cases-01> (Chonggang Wang) * updates: track and Detnet. Work on track is 6Tisch could be beneficial to Detnet. path redundancy. metrics for industry networks: RFC 5673 from ROLL. * Thomas: please WG read and comment on mailing list. * <draft-thubert-6tisch-4detnet-01> (Pascal Thubert) * Pascal: 6tisch view of what we need from detnet. Core question is "what is a track". [14.58] * Re-chartering kickstart and AOB (chairs) [5min] * Out of time. * Conclusions 1) <<<missed that>>> 2)interface delayed until COMI is finished. 3) rechartering. AD comment? Brian: makes sense.