Minutes for 6TISCH at IETF-92
minutes-92-6tisch-1
| Meeting Minutes | IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG | |
|---|---|---|
| Date and time | 2015-03-26 14:00 | |
| Title | Minutes for 6TISCH at IETF-92 | |
| State | (None) | |
| Other versions | plain text | |
| Last updated | 2015-04-17 |
minutes-92-6tisch-1
# Minutes IETF 92 WG meeting, 23 March 2015, 6TiSCH WG # Note: timestamps in CDT. Information and agenda ---------------------- Note: there are two 6TiSCH WG meetings at IETF92 Dallas, on Monday and Thursday. ``` Meeting : IETF92 MONDAY, March 23, 2015 Time : 1520-1650 CDT Monday Afternoon Session II (90min) Location : Continental room, The Fairmont Dallas, Dallas, TX, USA Chairs : Pascal Thubert <pthubert@cisco.com> Thomas Watteyne <watteyne@eecs.berkeley.edu> Responsible AD : Ted Lemon <ted.lemon@nominum.com> URLs : http://tools.ietf.org/wg/6tisch/ https://datatracker.ietf.org/wg/6tisch/ https://www.ietf.org/mailman/listinfo/6tisch https://bitbucket.org/6tisch Intro and Status [2min] (Chairs) Note-Well, Blue Sheets, Scribes, Agenda Bashing DetNet (cancelled during bashing) * <draft-finn-DetNet-architecture-00> [20min] (Norm Finn) * <draft-gunther-DetNet-proaudio-req-00> [10min] (Jouni Korhonen) * <draft-wetterwald-DetNet-utilities-reqs-01> [10min] (Patrick Wetterwald) * <draft-wang-6tisch-track-use-cases-00> [10min] (Chonggang Wang) 6TiSCH vs. DetNet * 6TiSCH vs. PCE related to track operations [35min] (Pascal Thubert) * <draft-wang-6tisch-track-use-cases-00> [10min] (Chonggang Wang) Security [35min] Security [30min] * DT status and design goals (Michael Richardson) * <draft-struik-6tisch-security-considerations-01> (Rene Struik) Wrap up for rechartering [8min] (Chairs) ``` Scribes ------- * TODO Jabber (xmpp:6tisch@jabber.ietf.org) * TODO Resources, Recordings and Logs ------------------------------ **Draft slides and status at https://bitbucket.org/6tisch/meetings/src/master/150323_ietf92_dallas/** | what | where | |-----------------------|------------------------------------------------------------------| | Agenda | https://datatracker.ietf.org/meeting/92/agenda/6tisch/ | | Wiki | https://bitbucket.org/6tisch/meetings/wiki/150323_ietf92_dallas | | Presented Slides | https://datatracker.ietf.org/meeting/92/materials.html#6tisch | | Audio Recording | TODO | | Meetecho Recording | TODO | | Jabber Logs | http://www.ietf.org/jabber/logs/6tisch/2015-03-23.html | Minutes ------- * _[15.23]_ Meeting starts * _[15.24]_ Intro and Status (Chairs) * Note-Well, Blue Sheets, Scribes, Agenda Bashing * Agenda change: first 3 drafts will not be presented because they are too far from WG charter. * Expect a barBOF this week to discuss them. * There will be a discussion at PCE on 6TiSCH deterministic requirement, Pascal to present now. * maybe a WG-forming BOF in Prague * _[??.??]_ (expected: 15.22) <draft-finn-DetNet-architecture> (Norm Finn) * skipped * _[??.??]_ (expected: 15.42) <draft-gunther-DetNet-proaudio-req> (Craig Gunther) * skipped * _[??.??]_ (expected: 15.52) <draft-wetterwald-DetNet-utilities-reqs> (Patrick Wetterwald) * skipped * _[15.28]_ (expected: 16.02) <draft-wang-6tisch-track-use-cases> (Chonggang Wang) * new draft, on industry networks. * two applications: process control and automation; monitoring; * same architecture * describes first application: communication between two constrained devices across two LLNs interconnected through a backbone. Track can be established beforehand by centralized controller. * describes second application: following anomalous condition, a constrained devices sends an alert and needs a track to send ensuing monitoring data. Dynamically established. * 6tisch-architecture draft mentions centralized and hop-by-hop track reservation. This draft provides requirements for theses track establishment. For example, quickly detect track establishment failure. * Suggestion for next steps? * Q&A * Thomas: you mentioned redundancy, how to get that? I suggest you look at impact on YANG model, see 6tisch-interface draft. Do you recommend any change to this model? * Zhuo Chen, co-author of this draft: <...I didn't get that> * Pat Kenney: slide 40. Re: redundancy, ISA100.11a has duocast. We should consider that here, too. * Pascal: replication and elimination is core to DetNet * Pat: found that timeslot needs to be made slighter wider. 12ms instead of 10 in order to enable duocast as done in ISA100.11a. * Thomas: works with 4e, now 15.4-2015? Pat: yes. * Thomas: two acks? Pat: yes, talk offline. * _[15.47]_ 6TiSCH vs. PCE related to track operations (Deterministic Networking) (Pascal Thubert) * Need to convey time sensitive packets as well as regular ones on a same network. * explains train analogy: trains are scheduled to leave stations at predefined absolute times to avoid collisions outgoing * explains bus analogy: the schedule is computed in advance; buses run at known period, transport in the bus between A and B takes a known time, so maximum latency of wait for bus + transport is known. * for what kind of apps? industry, audio/video, vehicle, smart-grid. Work at IEEE 802.1 (AVB and now TSN) * track management is not specified by 6TiSCH. We only define the interface to program the 6top layer. * determinism: back to physical, real hardware, real time. * for single track, could use RPL to compute and reserve track. * for replication & elimination (needed for time determinism, retransmission won't do): nobody knows how to do it in distributed fashion. Industry does it with centralized manager/controller * what does this controller need to operate upon, what does it produce as output? * state needs to be installed in the network nodes, flows need to be labeled. Need to extend work done at TEAS and CCAMP. * may make use of PCE protocol to program each device. * inside the controller: PCE takes topology and requirements to produce routes. Also, Track management maintenance. Measurement unit. * 6TiSCH is deterministic MAC. Can be used for deterministic traffic. Need to leverage PCE/CCAMP/TEAS to achieve that. * 6TiSCH will define requirements for DetNet * differ discussion on should DetNet be a separate WG to rechartering discussion later. * Q&A * Samita: how often will the PCE configure the schedule * Pascal: There is usually a first global computation for which a shower model is appropriate, the PCE programs the full schedule in all nodes one by one. Then there is the async path creation and update, for which a classical TE way is more appropriate. * Samita: what about movement? Central controllers usually have long latency. * Pascal: DetNet has 3 core components. One nails down the path. This is usually not really appropriate for movement but that is only one of the techniques in DetNet. And it can be made more dynamic by pushing the computation in the fog at the edge of the network. Mobile application may require edge buffering. * Thomas: many systems use centralized and work just fine, including ISA100.11a. * xxxx: reliability? smart grid use case. SDN approach. Need to consider inter-controller communication. Suitable protocol? Openflow, PCE? * Thomas: see 6tisch-coap draft. Using Comi. There will be a Presentation at the second meeting on Thursday. * _[??.??]_ (expected: 16.12) DT status and design goals (Michael Richardson) * nothing to present, Michael will discuss this as part of the "rechartering" section * _[16.13]_ <draft-struik-6tisch-security-considerations-01> (Rene Struik) * posted end of Jan. * since IETF91, added details on MAC functionality, ... * refresher on IETF91 presentation: desired properties * current draft assumes devices have public key security on board. Most will also fit non-public key. Assumes there is communication path between node and server. * next draft: devices with less requirements. No certificates, non-public-key, ... * also add details on protocol. * also look at impact of relaxing security conditions, look at deployment life cycle. * Pascal: look at SACM WG, seems like doing similar work. * also add privacy considerations, key compromise * also explain how node gets IP addresses, about network discovery (many drafts around) * let's try to unify draft currently appearing in Anima, 6lo, 6TiSCH * consider new scenario with sprinkled-in nodes (disposable) * Sandeep: how does the node decide to join the network or not? Rene: some language in there. * René ask the audience if thinks this is useful/extensible enough? * Thomas: like the fact that PSK will be taken into account. * René: we need data points to do the right trade-off. * Thomas: with shared secret, less bandwidth required to join in. * Robert Cragie: do you thing there is a way unifying all these drafts on security? They might be appearing in different groups for a reason. * René: some aspects depend on MAC functionality (in the case of this case, 15.4e TSCH), but 90% of it is independent. MAC behavior is explicitly referred to. * Pascal: IoT directorate. Next session exactly about these various security drafts. * René: do something without too much overhead (UN !) * Subir Das: * Samita (with 6lo co-chair hat): invite to discuss with 6lo WG. This week, informal meeting on security on Thursday evening 7pm, location to be announced. * _[16.42]_ Wrap up for rechartering (Chairs) * two topics at hand: centralized scheduling DetNet, and security. Regarding DetNet, we know what we want, already implemented in ISA100.11a. Group is asker to read DetNet drafts. * Pascal asks a question to the group about DetNet: should we incubate or fork? * Subir: including all this DetNet is a lot, even for extended rechartering. Suggest a separate group. * Pat K: agrees that a separate DetNet group would help have a better system understanding. It's not just about 6TiSCH. * Pascal: would love Chonggang's draft to spell out the number of tracks, of nodes, the latency requirements, the number of flows. To use as input to DetNet. * Norman Finn: depends on whether you think wired or wireless. In audio systems, not about 6TiSCH. Would like to see a "side meeting" (aka barBOF) in Prague. * Pascal: * regarding security: time-out, will discuss on Thursday. Same room here. * _[16.51]_ Meeting ends # Minutes IETF 92 WG meeting, 26 March 2015, 6TiSCH WG # Note: timestamps in CDT. Information and agenda ---------------------- Note: there are two 6TiSCH WG meetings at IETF92 Dallas, on Monday and Thursday. ``` Meeting : IETF92 THURSDAY, March 26, 2015 Time : 0900-1130 CDT Thursday Morning Session I (2.5h) Location : Continental room, The Fairmont Dallas, Dallas, TX, USA Chairs : Pascal Thubert <pthubert@cisco.com> Thomas Watteyne <watteyne@eecs.berkeley.edu> Responsible AD : Ted Lemon <ted.lemon@nominum.com> URLs : http://tools.ietf.org/wg/6tisch/ https://datatracker.ietf.org/wg/6tisch/ https://www.ietf.org/mailman/listinfo/6tisch https://bitbucket.org/6tisch Intro and Status [2min] (Chairs) Note-Well, Blue Sheets, Scribes, Agenda Bashing Last Call Status * <draft-ietf-6tisch-tsch-06> [10min] (Thomas Watteyne) * <draft-ietf-6tisch-minimal-06> [10min] (Nicola Accettura) * <draft-ietf-6tisch-architecture-06> [10min] (Pascal Thubert) * <draft-ietf-6tisch-terminology> [10min] (Maria-Rita Palattella) Other Drafts * <draft-ietf-6tisch-6top-interface-03> [10min] (Xavi Vilajosana) * <draft-wang-6tisch-6top-sublayer-01> [10min] (Xavi Vilajosana) * <draft-ietf-6tisch-coap-03> [10min] (Xavi Vilajosana) Plugtest [10min] (Miguel Angel Reina Ortega) Distributed Scheduling * <draft-dujovne-6tisch-on-the-fly-05> [30min] (Diego Dujovne) Rechartering [38min] (Chairs) * Summary of Monday's meeting * Scheduling goals and deliverables * Security goals and deliverables ``` Scribes ------- * TODO Jabber (xmpp:6tisch@jabber.ietf.org) * TODO Resources, Recordings and Logs ------------------------------ **Draft slides and status at https://bitbucket.org/6tisch/meetings/src/master/150323_ietf92_dallas/** | what | where | |-----------------------|------------------------------------------------------------------| | Agenda | https://datatracker.ietf.org/meeting/92/agenda/6tisch/ | | Wiki | https://bitbucket.org/6tisch/meetings/wiki/150323_ietf92_dallas | | Presented Slides | https://datatracker.ietf.org/meeting/92/materials.html#6tisch | | Audio Recording | TODO | | Meetecho Recording | TODO | | Jabber Logs | http://www.ietf.org/jabber/logs/6tisch/2015-03-26.html | Agenda ------ * _[09.03]_ (exp. 09.00) Meeting starts * _[09.03]_ (exp. 09.00) Intro and Status (Chairs) * The agenda is approved * _[09.05]_ (exp. 09.02) <draft-ietf-6tisch-tsch> (Thomas Watteyne) * describes latest progress * currently is RFC Ed Queue * _[09.07]_ (exp. 09.12) <draft-ietf-6tisch-minimal> (Xavi Vilajosana) (pres. Nicola) * changes since IETF91 * RPI and RH3 headers: studied solutions to packet space used. Flow label, header compression, Zigbee IP approach, ignore * RPL requires encapsulation * security: one key to authenticate EBs * a few clarifications (synchronization) and text clean-up. * René Struik: one key for EB, other key for all the rest. How do these keys get into the device? * Niccola: out of scope for this draft. * René: would recommend to remove this paragraph, this is security policy hard-coded, believe it's inappropriate. * Thomas: this is minimal configuration, with no entity that does key distribution. Likewise, schedule is hard-coded. We want this for first plugtest. PSK. * René: what would be useful is remove this key K1. Can still agree on mechanism for plugtest. * Ted Lemon: ... compromise security in the long term? * René: this appeared recently in the draft. not discussed in the security group. * Pascal: please take a few minutes to explain the pb. * René: you're putting WirelessHart into 6Tisch. * Pascal: the two keys could be identical * Thomas: this is the simplest you can get * René: can mess nonce... <editor comment, if the reader is interested, a whole thread has followed, see http://www.ietf.org/mail-archive/web/6tisch/current/msg03186.html > * over Jabber from ???: mostly agree with René's arguments * over Jabber from Xavi: * René: you can remove the 2nd paragraph and still need to agree on something for the ETSI plugtest in Prague. * René: it's possible to have EBs properly authenticated using ... * René: worried this will become an RFC, will be regarded as bootstrapping mechanism * Yoshi Ohba: * Thomas: key is pre-provisionned, no key exchange protocol. * Robert Cragie: not sure what exactly is René's concern? ... I don't have an issue with this text. * Subir Das: if key distribution is out of scope, then remove "well-known or pre-configured". * Pascal: we need more work, discussion will be conducted on the mailing list. * René: * Subir: * Pascal: please send proposals to the mailing list with new text and explain why the change is needed * _[09.30]_ (exp. 09.22) <draft-ietf-6tisch-architecture> (Pascal Thubert) * went through WGLC * Pascal goes through 4e TSCH benefits and rationale for architecture document for 6TiSCH WG at IETF. Collect and organize the pieces into a full stack. * found some improvement that need to be done in their original groups. * some truly new stuff: how to manage the TSCH mechanic (6top sub layer), dynamic routing and scheduling (deterministic flows on deterministic MAC), security (join). * CoMI work at Core (how to program our 6TiSCH network), routing dispatch compression. * aggregate all the design decisions. When new charter, second volume of arch will be produced. * addressed last call comments, some rework still to be done (eg Michael R's review), then push to ISEG * _[09.42]_ (exp. 09.32) <draft-ietf-6tisch-terminology> (Maria-Rita Palattella remotely) * reviews changes following Last call feed-back * improved and new definitions * deleted some definitions no longer needed or not relevant * not received much comment, few discussion, believe the draft is ready * Pascal: normative ref to terminology draft in arch, so we need this. Ship this one and * Ted Lemon: security terms will be in security draft. Other drafts will need the security terms? * Pascal: Brian Haberman new AD. Thanks to Ted for all the work done. * Brian: * _[09.50]_ (exp. 09.42) <draft-ietf-6tisch-6top-interface> (Qin Wang) presented by Xavi remotely * changes since IETF91: * took MR's comments and translate into YANG model elements * addressed mail from Jonathan Simon (Linear Tech) on legal issues * discussion on how to expose the MAC attributes (eg PANId) so that external entities can configure the node. What attribute need to be exposed? * Thomas: simply need to do work or help needed? Xavi: some advice wanted. * Pat Kinney: another interface that needs to be addressed: priority control. Who gets first access on shared slot? Many others. Willing to participate. * Pat: co-chair of ISA100, will make sure both groups are consistent. * Pascal: PCE and TEAS, far away from device, will interact with the device through these interfaces. We need to do it right. Data model difficult to change later on. * Xavi (resumes): will fill in 4.3 as 6top security work progresses. * _[10.03]_ (exp. 09.52) <draft-wang-6tisch-6top-sublayer-01> (Qin Wang) presented by Xavi remotely * how the 6top sublayers talk to one another. * Not in the charter at this time. * _[10.05]_ (exp. 10.02) <draft-ietf-6tisch-coap> (Raghuram Sudhaakar) presented by Xavi remotely * recent changes are: addition of ref to comi, bibliography, ... * remote node interfaces with 6top layer of constrained node avec CoAP. * CBOR compression of payload. * list examples of resources, commands * goes through a few samples of messages exchanges * Samita Chakrabarti: 6top request and response. Could it be applicable to other device that are not 6TiSCH? Xavi: this is designed for 6top. However, we support extensions which allow to query other resources. * Thomas: this is just CoMI addressing the 6top sublayer. You could use CoMI to talk to your other layer, rather than extending 6top. * Samita: ...names... * Pascal: this document is done, but references other documents, so we're holding it for a while. * Thomas: Peter VdS, do you care for offering comments on CoMI status? * Peter: based on RESTCONF.... * Thoams: RESTconf chairs asked for help for reviews. * xxx: pubsub term in slides. Not consistent with Coap terms. ... ... .... * Thomas: we are not changing anything to CoAP. * yyy: little constrained Class0 nodes? * Thomas: you're right, in this work, we assume you have CoAP implemented. Otherwise, can still use -minimal configuration, which is static schedule. * Michael Richardson: what about intermediate situation, distributed scheduling: nodes need more memory than with PCE. Not having a PCE might be more complex than you'd think. * _[10.26]_ (exp. 10.12) Plugtest Miguel Angel Reina Ortega * week-end right before IETF93. Scope is -minimal. * participation links will be made available on the website which is not fully ready yet. and announced on the ML * milestones for the expert group are: stable specs beg. June; golden device June; final test specs July 10th; post plugtest technical report end of Aug. * test specs will be distributed to the 6TiSCH community for review * Group of expert announced: Thomas, Xavi, Maria-Rita, Tengfei Chang (golden image leader), Miguel (plug test team leader) * _[10.34]_ (exp. 10.22) <draft-dujovne-6tisch-on-the-fly> (Diego Dujovne) * Status and evolution * long maturing time. Last updates mostly addressed itneraction with (evolving) 6top. * OTF provides a framework for distributed and hybrid scheduling approaches * estimates bandwidth requirements from various statistics. Allocation algorithm is user-defined. * Diego describes block diagram. * Two versions since the last IETF91 * Functionality description has been simplified * this draft specifies hysteresis to improve stability of allocation. Two thresholds, one for overprovisioning, one for underprovisioning * previous "list of events" was replaced by common structure, to made it easier to add more as need arises. * next? add this work into the WG charter; discussion on option on cells, contention allowed?; compliance to terminology draft. * Thomas: * Pascal: (to the group) A bundle is a collection of cells. Handling bundles in OTF is just fine. * Diego: how about creating bundles? Pascal: bundles are created for you if the node has a neighbor. * Pascal: this work fills the case of stochastic traffic over deterministic MAC. * _[10.56]_ (exp. 10.52) Rechartering (Chairs) * Pascal: chartered work mostly completed: architecture, interface. Do we want to close or carry on? * Proposed items for next rev of charter - 15.4e will be rolled into 15.4-2015, fix charter text. - security: attend side meeting tonight 7pm. Do we want to take on security work in this group? Join process security, in this case - centralized scheduling: current charter actually already says "will work with relevant WG's", would include PCA, TEAS, CCAMP. From 6TiSCH or create DetNet and push requirements from 6TiSCH to DetNet to take on that work. - add distributed scheduling * Pascal: opinions on our WG's capability to handle security work? * Michael R: sec design team created 14 months ago. Expected to explore zero-touch secure joining process. Since security work not chartered, work ended-up delineate the requirements for the arch. Regarding from now on: join process could be done at ACE/Anima, this group could just push requirements. * Thomas: secure join. Also need a secure session between nodes and management entity. MR: agreed, the secure join process has to resolve in forming a secure session with PCE * Thomas: could Anima provide solution to both reqs? * MR: our req , Anima must pass back to us a "thing" which is a connection to the PCE or facilitate its establishment. * Michael Behrenger: Anima should take care of the bootstrap scenario. * René: Anima decided to remove IoT from their charter. Would like 6TiSCH group to continue doing expedient work. Here. * René: how much of this is generic Layer3, how much ties to 15.4e, don't know, but good work being done here. * Thomas: agreed to keep mobing, but want to make sure what we come up with is generic enough. * Leslie ??? (sec advisor for Anima): draft at Anima that describes general workflow for secure bootstrapping. Will send list to 6Tisch list. * Subir Das: * Ted Lemon: meta comment on process. Current charter has milestones: earliest uncompleted milestone Aug14 ,rescheduled Dec94. Still need to complete all that. * Pascal: -interface and -coap drafts are complete, just we don't want to ship them because of references. * Ted: -minimal? Thomas: finished, will be submitted to IESG shortly. * Samita: come to 6lo. Let's discuss how we divide and conquer the world. * Pascal: also, join DetNet if you're interested in scheduling. * Pascal; comments on scheduling? * xxx: scheduling work exists outside this WG. This group to provide a framework. * Pascal: DetNet to do scheduling. Can be useful for other that 6TiSCH as well. * xxx: <<<missed>>>. Pascal: send to the list. * Pat Kinney: requests change in current charter. 15.4e will be rolled into IEEE802.15.4-2015. Currently %df5? draft, to voting members and participation members. Sponsor ballot Apr, draft will be publicly available. Final document expected Dec. describe changes in 15.4 that impact 6TiSCH. Priority Channel Access now aligned with 6TiSCH. ... Current charter refers to 15.4e. This is an amendment, a delta to -2011. Does define the whole MAC. 15.4 would refer to whatever is current at IEEE802, which today would be 15.4-2011 amended by e,f,g,..... * Thomas: anybody objecting to writing 15.4 in our charter? * René, Robert C: clarifying question that this means work that is adopted standard. Pat: yes. Explained above. Robert: then I agree. * Subir: ... normative reference... * Thomas: this [the 15.4e discussion] will be discussed again at next interim meeting, that will take place in a few weeks. * _[11.37]_ (exp. 11.30) Meeting ends