Agenda and Meeting information Meeting : IETF96 Monday, July 18, 2016 (CEST)
Time : 14:00-15:30 Monday Afternoon session I (90min) Location : Room Bellevue, Intercontinental Berlin Chairs : Pascal Thubert <[email protected]> Thomas Watteyne <[email protected]> Responsible AD : Suresh Krishnan Live minutes : http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-6tisch Live feeds : https://tools.ietf.org/agenda/96/#96-mon-1400-6tisch Other 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 [5min] (Chairs) Note-Well, Blue Sheets, Scribes, Agenda Bashing New charter and status docs [20min] (Chairs) * Status Documents * Status 6lo / ROLL * Milestones * Action Plan Dynamic Scheduling * <draft-wang-6tisch-6top-protocol-01> [15min] (Xavier Vilajosana) * <draft-dujovne-6tisch-6top-sf0-01> [15min] (Diego Dujovne) Security * status of the work and action plan [10min] (Michael Richardson) Plugtests News * ETSI 6TiSCH/6lo plugtests Results [10min] (Miguel Angel Reina Ortega) (Maria Rita Palattella) Unchartered items, time permitting * <draft-satish-6tisch-6top-sf1-01> [10min] (Satish Anamalamudi) Any Other Business [2min] (Chairs) Resources * [agenda:] (https://datatracker.ietf.org/meeting/96/agenda/6tisch/) * [presented slides:] (https://datatracker.ietf.org/meeting/96/session/6tisch/) Summary TODO Action items Volunteers * Scribes * Dominique Barthel * Diego Dujovne * Jabber * Ines Robles Minutes * [14.01] (expected 14.00) Intro and Status [5min] (Chairs) * Note Well * any comment to the agenda? none. Agenda approved * [14.03] (expected 14.05) Status [20min] (Chairs) * -minimal going through IESG reveiw * 6LoRH passed LC, now at ROLL, waiting for 6lo-paging-dispatch, itself missing shepherd review * news from 6man: 2460m 4291 and 1981 bis'sed to beacom Internet standard. Discussion on header insertion. Some would like to clarify that header insertion cannot be done. Would break a lot of stuff. Chime in! * 6P protocol * security work kickstarted (michael) * Suresh: -minimal has to go through IETF last call before IESG. Another issue came up: meeting tomorrow on policy for copyright on IEEE documents. 6tisch minimal has references to copyrighted material from IEEE. * [14.09] (expected 14.25) <draft-wang-6tisch-6top-protocol-00> [15min] (Xavier Vilajosana) * version -01 submitted recently. Used to be -sublayer draft. * this text has clarification on 6top concurrent transactions * today discuss a few points that came up during ETSI plugtest. * 6p command to count cells in the schedule for a link. extend the command to get the status in both directions of the link. propose to change name from 6p count to 6p status. * 6p does not paginate. can add pagination add an offset for each page. another command: list from A->B and B->A (TX and RX) cells. A and B neighbours. * detect if a node and its neighbour is consistent after disconnection and restore state or reset. keep the status by defining a Schedule Generation * new NO_RESOURCES error: not enough cells for request. * consistency: ensure that both ends agree on their schedule, especially after disconnection, reboot, etc. Could CLEAR and restart the whole process. Change the seqnum byte to hold a shorter seqnum and a 2 bit lollipop counter ("generation" number) for each link direction. 3 states: starting, value 1, value2. Once it's going, alternate between values 1 and 2. * Thomas: what happens when schedule unknown Do both ends have to CLEAR? * Xavi: Both have to clear. * Thomas: is a one bit counter enough? Xavi: yes, because requirement to have only one transaction on-going. * Pascal: how to know that One or more routers around who has the state about the node (me). What to do? TBD * Thomas: these are issues that arose during the plugtest yesterday. We have not yet discussed them on the mailing list. Will do. Comments from implementors? Pascal: this means will probably not be done in July as planned. Xavi: if you think our proposals above create issues, tell us on the mailing list. If nothin gheard, will push a new draft out quickly. * [14.28] (expected 14.40) <draft-dujovne-6tisch-6top-sf0-01> [15min] (Diego Dujovne) * this used to be "on-the-fly scheduling". Now default scheduling function aka SF0. * algorithm to measure bandwidth usage (short of having hte application communicate its requirement to us). * the number of cells is converted to the input for the allocation policy * Establish a high SF0THRESH for overprovisioning * Thomas: don't understand drawing on slide 4. * Nicola, Pascal, Thomas: Threshold arrow should be drawn one-way, going down from current scheduled cells. * Recommendation: convert the figure 4 in 3 figures. One that represents the case that there are too many cells, another where there are more cells needed and another where the number of cells is fine. * whitelist: selection of the ch.offset randomly. The neighbor selects the cells sequentially in case there is a collision. (i,e if the cell is used proposes the next cell in the list). * blacklist: * Pascal: use of blacklist-> administrative to reserve some cells. Other more functional to avoid noisy channels, etc... Why the concept is comming here? * Diego: a black list is something that has been allocated to something else. Is a mechanism to internally reserve/protect some cells. * Pascal: there should be a mechanism to avoid collisions in the selection/ or to reuse too many times the same cell. * * Timeout: if no news from neighbor, cancel the state requested by command. * There may be concurrent requests from several neighbors (not concurrent requests for the same neighbor). * these concurrent requests may prevent from accepting the resquested allocation. * Use 1 bit from the metadata field to differentiate between concurrent transaction or busy because there are no processing resources. * "No processing ressource" means no CPU ressource or other reason, please come back later. * "ongoing concurrent transaction" means some other neighbor requested cell range that overlap with your request, or somtehing similar. * todo: adapt tp changes in 6P. Cell relocation: on which PDR? is 20% below average (across all cells to same neighbor?) a good value? Cell garbage-collection when neighbor has disappeared? * Questions? * Tengfei Chang: on slide 4, how is "more" computed? * Thomas: this is essential work, SF0 is meant to be the generic, default scheduling. We would love feedback from implementors to check that it fits the needs. Or even simulation. * Thomas: next we'll have a presentation of SF1. Authors, please position SF1 wrt SF0 so the WG can understand if we should merge, pick one, and keep both. * Pascal: depnding of node position in the network (center, edge), reaction to cell shortage might be different. * Xavi: why differentiate between "node busy"and "concurrent transaction"? Will retry in any case. Diego: differnet timeout value · [14.58] (expected 14.55) Status of the security work and action plan [10min] (Michael Richardson) * security design team, resumed work in May 2016. * -00 draft will be out this week. Table of contents presented here. * Explain motivation, assumptions and restrictions. Protocol bandwidth conservative join cordination entity to control the joining sequence(?) * Code reuse: No security protocol not already used for other purposes (if single use, less chances of being maintained, etc). * not reinvent DTLS. OS COAP evolution? o Zero conf: too expensive?. Acceptable. o Göran Selander: where does OSCOAP belong? application layer protocol on top of COSE. We are going to ask for adoption in CoRE, which is where it belongs. Diffie-Hellman (EDHOC) is less clear.It will be presented at ACE WG meeting this week. Michael: again, we'd rather not use a protocol that's not already in the device for some other purpose. * Göran: used also for firmware updates. You have it already in your device. * Carsten Bormann: COSE working group has not finished the main task. It will/may? be closed once the main draft is done. * Not throw away the good design patterns we had before. * * [15.07] (expected 15.05) ETSI 6TiSCH/6lo plugtests Results [10min] (Miguel Angel Reina Ortega/Maria Rita Palattella) * supported by OpenMote for golden HW and OpenWSN for golden SW. * two full days spread over 3 calendar days. * test description by TW, MRP, ... for 6TiSCH and CB+KL for 6lo. * 6TiSCH had 20 tests. "85%" interoperability. Tests also prompted for improvements in 6P. * 6lo NFC: "80%" interoperability. Sniffing Mechanism * 6lo BBR: 66%. Actually, many could not be run at all. Most of the tests that ran actually worked. * take-aways: advertize event earlier in advance. Have a pre-test session. * Thomas: discussing with Miguel/ETSI about next event, maybe somewhere in Europe in Feb 2017, or at IETF meeting in July 2017 (Prague). * Pascal: thanks to ETSI for organizing this. * [15.15] (expected 15.15) <draft-satish-6tisch-6top-sf1-01> [10min] (Satish Anamalamudi) * need for SF!? end-to-end scheduling for real time applications. Schedule isolated traffic flows. * background: RSVP-MPLS and RSVP-GMPLS. * Pascal: in 6TiSCH Architecture, we have notion of a track. Please use it in your design. * Pascal: More than defining the algorithm, defining a path here. * each cell is implicit label as per GMPLS. * Satish goes through examples of protocol operation. * Pascal: this is not jsut allocation algorithm, this is path-setup alogrithm. Not currently chartered for that. * Pascal: the group is interested, keep working on it, but the WG cannot adopt it (yet). * xxx: .. time ? Satish: freshness of allocation ... * Xavi: many papers of this topic. * Xavi: timeslot is enough as a label. * Xavi: slotframe ID should be part of label, in case you have more than one slotframe. * [15.30] (expected 14.25) Any Other Business [2min] (Chairs) * info session on F-Interop tonight. Live demo. * no other business
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
