Minutes Webex 12 September 2014, 6TiSCH WG
Note: timestamps in PDT.
- Webex: https://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D
- Etherpad: http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true
- 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
- Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=8b6415fd8dff42a99fccf118ff2faa82
- Wiki: https://bitbucket.org/6tisch/meetings/wiki/140912_webex
- Slides: https://bitbucket.org/6tisch/meetings/src/master/140912_webex/slides_140912_webex.ppt
Taking notes (can't live without them :) )
- Xavi Vilajosana
- Thomas Watteyne
Present (thanks guys!)
- Thomas Watteyne
- Pascal Thubert
- Ariton Xhafa (call in user 3)
- Dominique Barthel
- Elvis Vogli
- Kazushi Muraoka
- Martin Turon
- Michael Richardson
- Pat Kinney
- Patrick Wetterwald
- Paventhen Arumugam
- Qin Wang
- Rene Struik
- Sedat Gormus
- Xavi Vilajosana
- Pascal will post to 6lo and ROLL indicating that these minutes contain a discussion on the RPL option for 6TiSCH
- Martin should rebound on that
- Administrivia [3min]
- Approval agenda
- Approval minutes last call
- Minimal RPL support for RPL option [30min]
- Continue Flow Label vs. 6LowPAN discussion [20min]
- AOB [2min]
- last call minutes are approved. No concerns are raised.
- Agenda is approved. No concerns are raised.
[08.10] Minimal RPL support for RPL option [30min]_
Can 6TiSCH live with the HBH ?
- [Thomas]It works but would be better to have some compression
- [Xavi] can we leave the draft not specifying this?
- [Michael] we cannot that otherwise no interop
- [Pascal] agreed with Michael, implementations need to know what to implement for interoperability. we must be clear on what we use.
- [Pat Kinney] Do not like HBH. It is not a think that may live for a long time.
- [Thomas] I support that and we need to do something quick.
- [Pascal] Zigbee IP uses 15.4g with large frames so 8Bytes are nothing compared to their packets so they can survive with that.
Can we reuse the flow label ?
- [Xavi] what propose? flow label is not adopted yet, 6lo not working yet on HbH compression
- [Pascal] 6man did not reject it. we need to have 6man think about the rule that a flow label cannot be changed.
- [Thomas] Currently 6man requires the end to end flow label.
- [Michael] random on a per-flow basis
- [Pascal] we still carry 20 bit across the LLN to satisfy the core. We need to change those rules anyway.
- [Pascal] 6man chairs will people to support and want a good reason.
- [Michael] You got consensus on the 6man ML so we can discuss about that. ROLL Mail trying to move that forward. My take is that we have consensus from 6man, that when a packet enters the LLN we can reset the flow label field. It is consistent with zero-flow label existing practice. Using the flow label on a hop by hop basis in the LLN is our matter then.
- [Michael] There was silent when asked for consensus about that.
- [Martin Turon] Are we taking about the RPL option described in RFC6553?
- [Pascal] yes
Should we go to ROLL or 6lo?
- [Pascal] Roll approach: we do something in ROLL? Other approach: we propose a solution in 6lowpan that works in 6lowpan world only. The RPL version might use the Flow Label but some people do not like. The 6lowpan approach can have some benefit but might be limited to 6lowpan networks. According to 6lo, hbh header needs only to be compressed in 6lowpan networks. Will we be able to have something by November?
- [Thomas] There are things that go fast. Do you have a description of both approaches?
- [Pascal] The big difference is whether we compress in 6lowpan or in the flow label. The 6lowpan consumes dispatch resources or next header resources.
- [Thomas] Also, there is the need to clarify the exception to the rule for the flow label. Break the rule and define an argument.
- [Michael] Is there some place where we can put the rank (changing part)? instance id can go in the flow label and the rest somewhere else. can the constant part go in the 6lo context? header compression can use the context.
- [Pascal] we need a stable work group document in 2 months. We need to decide what space in the current headers we use, it is only that.
- [Ariton] WOuld like to see slides on the problem.
- [Martin] There is something compelling on using 6lowpan compression. But it exposes a problem in 6lowpan header, it is not clear what the ordering should be or it should end.
- [Pascal] Well, RFC4944 is clear on the order, and new drafts can be clear as well. e.g. Carsten's draft imposes his new dispatch right before IP_HC.
- [Pat] what can happen if both approaches become standards? would everything work the same?
- [Pascal] We could say 6lo if present else HbH if present else flow label. Trouble is with source router packets in non storing going down the DODAG to the device; they may or may not carry a RPL option, and if the do not but yet have a flow label, then we might be confused.
- [Martin] take into account that in the future more protocols will be there and we cannot consume many bits in 6LoWPAN compression for a specific protocol such as RPL. Can we accept new routing protocols with the Flow Label solution?
- [Pascal] there is one bit left in the flow label. So we can do what we do with dispatch. If first bit is zero then the FL is used by RPL. Other settings with first bit to 1 reserved for other usages, like another routing protocol in the same LLN.