Wiki
Clone wikimeetings / 140523_webex
Minutes Webex 23 May 2014, 6TiSCH WG
Note: timestamps in PDT.
Connection details
- Webex Link
- Live etherpad for minutes
- Topic: 6TiSCH Weekly
- Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
- Meeting Number: 206 802 913
- Meeting Password: sixtus
- CCM: +14085256800x206802913
Resources
- Webex recording [69min]
- Wiki: wiki page for this meeting
- slides: slides shared during the call
Attendance (alphabetically)
- Diego Dujovne
- Giuseppe Piro
- Ines Robles
- James Pylakutty
- Kazushi Muraoka
- Kris Pister
- Maria Rita Palattella
- Michael Richardson
- Nicola Accettura
- Pascal Thubert
- Pat Kinney
- Patrick Wetterwald
- Pouria Zand
- Rouhollah Nabati
- Sedat Gormus
- Thomas Watteyne
- Tom Phinney
- Xavi Vilajosana
Action items
- chairs to contact IETF to ask if it is possible to do the plugfest on Sunday.
- [Xavi] and [Thomas] to look at issue 7 of minimal draft
- Pascal to send an email to the ML with the proposal of adding part of draft-piro to the draft-tsch.
- Thomas to review/clean use of terminology in draft-tsch
- Patrick to send remarks by e-mail to ML.
- Pascal to propose an ad-hoc meeting next Friday dedicated to terminology.
- Pat to detail regulatory limits about slotted aloha on ML.
Agenda
- Administrivia [10min]
- Approval agenda
- Approval minutes last call
- plugfest: date
- architecture draft issues:
- reviewers needed for draft-piro-6tisch-security-issues
- Terminology [15min]
- updates minimal draft [15min]
- overview bitbucket changes
- requirements
- EB control bits proposal [15min]
Minutes
- [08:04] Meeting starts
- [08:04] Administrivia
- Approval agenda
No issues raised. Agenda approved.
- Approval minutes last call
No issues raised. Minutes approved.
- plugfest: date
- plugfest
- conflict with registration
- possible problem with rooms available and insurances
Action item: chairs to contact IETF to ask if it is possible to do the plugfest on Sunday.
- [Xavi] Need to present tools and techno and we can learn from everyone
- [Thomas] need a clear set of goals, something more constructive, show outcomes, working demo.
- [Xavi] for 6TiSCH last time objectives apply again
- plugfest
- architecture draft issues:
- [Pascal] use tickets and resolution mechanism
Action item: [Xavi] and [Thomas] to look at issue 7 of minimal draft
- Issue 9 is a clarification.
- http://trac.tools.ietf.org/wg/6tisch/trac/ticket/7
In section 7.2, I might read that broadcast DIO and DAO are not contained in ICMPv6 messages In section 7.2, I might read that broadcast DIO and DAO are not contained in ICMPv6 messages, but rather that the payload is put into a "Data Packet" without an IPv6 header and ICMPv6 header. Is that intended? [PT] There is an ICMP header; let me reword that. What about: " To broadcast ICMPv6 control messages used by RPL such as DIO or DAO, 6top uses the payload of a Data frames. The message is inserted into the queue associated with the cells which LinkType? is set to ADVERTISING. Then, taking advantage of the broadcast cell feature established with FrameAndLinkIE (as described above), the RPL control message can be received by neighbors, which enables the maintenance of RPL DODAGs. " yes, works for me.
- http://trac.tools.ietf.org/wg/6tisch/trac/ticket/8
section 7.5 seems jumbled... maybe just not done yet. [PT] Yes, we need to raise an issue on this
- http://trac.tools.ietf.org/wg/6tisch/trac/ticket/9
Clarify that a TSCH Schedule is a set of 2D matrices Please clarify that a TSCH Schedule is a set of 2D matrices. Each matrices is [slotOffset,channelOffset] sized slotframe, and determines how a particular node assigns the chunks. [PT] Yes, there can be multiple matrices formatted globally in chunks that are later appropriated by devices
- [Pascal] use tickets and resolution mechanism
- reviewers needed for draft-piro-6tisch-security-issues
- [Michael] draft-piro explains what 15.4 proposes for security, good stuff there. Goes on to add command frames for P2P key management. On that part, we need to decide what we do but grain of salt. Missing how join a new network.
- [Pascal] can part of this draft be included in the tsch draft as a solution review?
- [Michael] The draft is a solution document. Having the draft it is interesting as it contains information that is relevant and very descriptive.
Action item: Pascal to send an email to the ML with the proposal of adding part of draft-piro to the draft-tsch.
- Approval agenda
- [08:30] Terminology
- [Patrick] on terminology: would be great to keep or enhance the definition
- [Maria Rita] good suggestion, try to have the same meaning with maybe a richer explanation
- [Patrick] ok. examples are timeslot schedule link linktype.
Action item: Thomas to review/clean use of terminology in draft-tsch
- [Pascal] link must be defined the IETF way so we can explain
- [Patrick] terminology should be in one document, right now there are multiple definitions e.g. draft-tsch Annex A
- [Thomas] could you send a list of what you found?
- [Patrick] yes will send remarks through email
Action item: Patrick to send remarks by e-mail to ML.
- [Patrick] cell vs. timeslots is unclear. e.g. a track is a suite of cell not timeslots
- [Patrick] in terminology it says that the broadcast cell has a mac address. Cell is referencing a slotframe handle
Action item: Pascal to propose an ad-hoc meeting next Friday dedicated to terminology.
- [08:44] minimal draft
- [Thomas] going though the questions in the scope draft
- [Thomas] Can we agree that, when ONLY minimal is running:
- all nodes in the network have the same schedule
- the schedule never changes
- [Pat] shouldn't the schedule change when new nodes are admitted
- [Xavi] running minimal does not prevent other mechanisms on top
- [Kris] not here we're just doing slotted aloha
- [Pat] maybe regulatory issues with slotted aloha, let us discuss on the reflector
Action item: Pat to detail regulatory limits about slotted aloha on ML.
- [Kris] DAGroot to be able to set the links in the EB. The only think that changes the slotframe length.
- [??] what happen if there are potentially 2 DAGroots?
- [Kris] if this is the case then 2 networks will be form
- [Kris] The simplest thing is to put TXRX slots in the beginning of the slotframe. You have a variable length of the slotframe.
- [Kris] slotframe provides a trade-off between bandwidth and energy consumption. That is what determines how the network behaves.
- [Thomas] do we prevent the EB to use frame and link IE and keep that minimal pre-configured slotframe?
- [Kris] We need to be compliant to IEEE802.15.4e.
- [Thomas] So must be there which implies that hardcoded minimal is not useful.
- [Kris] Maybe we could poll the WG about whether they have the minimal schedule hardcoded in their implementation.
- [Michael] In the EB, is there a flag that says to turn on/off minimal, or is the schedule described in the EB.
- [Thomas] The latter.
- [Michael] In general, it's better to think about what the receiver does when receiving something it doesn't understand, rather than focusing on what the transmitter is allowed to do.
- EB control bits proposal
No time.
- [09.14] Meeting ends
Updated