Clone wiki

meetings / 151211_webex

Minutes, 11 December 2015 interim, 6TiSCH WG

Note: timestamps in PST.

Connection details

Agenda

  • Administrivia [2min]
    • Approval agenda
    • Approval minutes last call
  • Charter Update [5min]
  • 802.15.4: status [5min]
  • 6lo drafts (BBR and 6LoRH) [10min]
  • PlugTest Scope [15min]
  • 6top drafts (next steps) [20min]
  • AOB [1min]

Taking notes (using Etherpad)

  1. Xavi Vilajosana
  2. Pascal Thubert
  3. Thomas Watteyne
  4. Benoit Claise

Present (alphabetically)

  1. Thomas Watteyne
  2. Diego Dujovne (Etherpad only)
  3. Pascal Thubert
  4. Benoit Claise
  5. Lavanya H M
  6. Maria Rita Palattella
  7. Pat Kinney
  8. Qin Wang
  9. S.V.R. Anand
  10. Sebastian Schildt
  11. Tengfei Chang
  12. Xavi Vilajosana
  13. Zhuo Chang

Action Items

  1. Thomas to poll the ML on the text that Ralph and Pascal put together for minimal abstract and intro
  2. Thomas to poll the ML on whether 6LoRH is a MUST for minimal and if so, whether we deprecate other forms of RH / IP in IP / RPI compressed encodings

Minutes

  • [07.05] Meeting starts
    • Thomas makes the intro, usual BCP announcements about IPR etc...
  • [07.07] Administrivia

    • Approval agenda
    • Approval minutes last call
    • bashing: asking confirm about minutes of last meeting and agenda. Both are approved.
    • Benoit Claise will speak about the 6top interface
    • Benoit shares screen and will update the etherpad
    • Benoit screens all the YANG models and publishes them all on his site where he publishes compilation errors at http://www.claise.be/IETFYANGPageCompilation.html
    • important because of dependency model (http://www.claise.be/modules.png). Our Yang model cannot be extracted. It is missing <CODE BEGINS> and <CODE ENDS>.
    • The extraction errors are

      • xym.py 6tisch
      • ERROR: 'draft-ietf-6tisch-6top-interface-04.txt', Line 423 - Yang module 'ietf-6top' with no <CODE BEGINS> and not starting with 'example-'
    • And the compilation errors are:

      • ietf-6top.yang:18: error: keyword "organization" not in canonical order, (See RFC 6020, Section 12)
      • ietf-6top.yang:72: error: keyword "mandatory" not in canonical order,expected "type", (See RFC 6020, Section 12)
      • ietf-6top.yang:73: error: keyword "type" not in canonical order, (See RFC 6020, Section 12)
      • ietf-6top.yang:83: error: keyword "unique" not in canonical order, (See RFC 6020, Section 12)
      • ietf-6top.yang:120: warning: RFC 6087: 4.10,4.12: statement "bit" should have a "description" substatement
      • ietf-6top.yang:123: warning: RFC 6087: 4.10,4.12: statement "bit" should have a "description" substatement
      • ietf-6top.yang:126: warning: RFC 6087: 4.10,4.12: statement "bit" should have a "description" substatement
      • ietf-6top.yang:129: warning: RFC 6087: 4.10,4.12: statement "bit" should have a "description" substatement
      • ietf-6top.yang:140: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:141: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:150: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:151: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:177: error: keyword "mandatory" not in canonical order,expected "type", (See RFC 6020, Section 12)
      • ietf-6top.yang:178: error: keyword "type" not in canonical order, (See RFC 6020, Section 12)
      • ietf-6top.yang:208: error: keyword "unique" not in canonical order, (See RFC 6020, Section 12)
      • ietf-6top.yang:237: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:238: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:239: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:240: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:263: error: keyword "must" not in canonical order, (See RFC 6020, Section 12)
      • ietf-6top.yang:287: error: keyword "unique" not in canonical order, (See RFC 6020, Section 12)
      • ietf-6top.yang:329: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:330: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:331: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:332: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:333: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:334: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:335: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:336: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:337: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:338: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:339: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:340: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:341: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:342: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:356: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:357: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:390: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:391: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:412: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:413: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:414: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:680: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:681: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:692: error: keyword "unique" not in canonical order, (See RFC 6020, Section 12)
      • ietf-6top.yang:797: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:798: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:848: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:849: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:1022: warning: RFC 6087: 4.3: statement "config" is given with its default value "true"
      • ietf-6top.yang:1032: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:1033: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:1052: error: keyword "config" not in canonical order, (See RFC 6020, Section 12)
      • ietf-6top.yang:1059: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:1060: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:1061: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:1062: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:1063: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:1064: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:1065: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
      • ietf-6top.yang:1066: warning: RFC 6087: 4.10,4.12: statement "enum" should have a "description" substatement
    • Xavi: Pushed in bitbucket a partial solutions. Will address the problem. Working on it.

    • Benoit: there is a YangValidator (http://www.yangvalidator.com/) that will extract the YANG data models out of drafts and compile them
    • Thomas: Is that the same tool for your website
    • Benoit: mainly yes. But you can send me the txt file before posting to check with the latest compiler
    • Thomas: what do you mean compiling
    • Benoit: we have a pyang syntax checker
    • Xavi: aware, we will solve this
    • Benoit shows curves and the green curve of compiling models rising at http://claise.be/IETFYANGPageCompilation.png
  • [07.10] Charter Update

    • Brian asked us to add the YANG model back into the proposed charter
    • TW: so administrative mostly, OK if we don't address this right away
    • PT: Brian asked is to indicate that there are dependencies
  • [07.??] 802.15.4: status
    • presented by Pat Kinney
    • new happening in 802.15
    • new regulatory PHY, to address India high power, too
    • high rate 2MBps PHY backward compatible with 256Kbps in 2.4GHz band
    • KPM ongoing
    • L2R in letter ballot
    • ULI study group
    • 802.15.4t approved PAR. Adapt 15.4 to a new frequency band
    • changes needed in 15.4g, hopefully added in 4t
    • 802.15.4u approved PAR. New PHY backwards compatible to 250kbps, will be MFK, 2Mbps data-rate. 8 times faster. more users in the same channel. for the same duration of a message, over 1kB of frame size. Very important and would help 802.15.4 and 6TiSCH.
    • PT: in 15.4g, usual need for IPv6 is 1500, 1280 minimal MAX MTU. We must guarantee 1280 on any IPv6 link.
    • Pat: hopes that open up than 4g, i.e. 2000 bytes. But that would be 9ms of duration. Not sure whether would be possible with 6TiSCH.
    • PT: 6LoWPAN says that we need to send 1280, not more. With 1280, we're happy.
    • TW: is 802.15.4u same as 802.15.4 without DSSS?
    • Pat: u means that we will add on to it. In the past we had a lot of amendments. We will be having n and q as well.
    • Pat: in this case, will be MSK
    • Pat: draft PAR for 802.12.12. Approval in March time frame in Macau, China. Upper layer interface. We want to integrate L2 functionalities into a standard upper layer interface. Right now, fragmentation can be done KMP or 6LoWPAN, etc. Lost of overlap and confusion. We need one standard to do what we want to do in a consistent manner. We want to take 6top and integrate into 802.15.12 so we can do new IEs as it is part ot 802.15 group. Purpose: integrate and harmonize. Example: fragmentation. Network configuration, power control, modulation encoding. More capabilities than LLC.
    • Pat: Questions?
    • Pat: sent out e-mail indicating that 802.15.4-2015 approved. Will be published in Q1 2016. 6 months after that, will be in get802 program. You can now buy the draft now. When published, you can buy on the IEEE SA site now. Late 2016, in the 802 program.
    • Pat: sent recommendation for using sub-ID IE. We'll see what 6TiSCH wants to do.
    • Pat: the 802.15.4-2015 solves the PANID confusion. We issued a dedicated doc.
    • Pat: went back to 4-octet frame counter.
    • Thomas: asking confirm that the ASN for security is still 5 octets
    • Pat: Yes. And there is a byte for security. And teh nonce for TSCH is the 5 octets ASN
    • Pat: questions?
    • Thomas: need to reflect on the slide and come back on the mailing list
    • Pat: questions?
  • Pascal coordinates with lavanyahm to get full name for minutes
  • [07.??] 6lo drafts (BBR and 6LoRH)
    • 6lo-routing-dispatch
      • adopted in 6lo
      • draft will be split in 2 drafts: one for RPL, one for Paging
      • plugtest in Berlin?
      • TW: This will be done in Paris. Since we tried to do IP in IP, we broke working interoperation. Goal is to restore interop based on this draft
      • PT: great, the feedback from the plutest will be very important for the draft. If the IP in IP is a nightmare we can come back to 6MAN.
    • 6lo-backbone-router
      • pending adoption
      • Berlin
      • XV: we discussed this, and we think this is more a 6lo thing, related to the BB. For the plugtest, will test
      • PT: 6LoWPAN registration from 6lowpan node to 6LR. We will be registering the target address, not the source address.
      • PT: The RA is changed to indicate that teh 6LR supports this. The the mote that acts as a RPL root must register on behalf of the motes that are in its 6TiSCH network. BB router is not a mote, but found 2-3 people who want to implement. The change is in the NA. Capability to send registration (NS+ARO) option. Code
      • TW: The piece in the motes is easy to implement and I'm not concerned there. I'm more concerned by the interaction between the motes over the backbone, dissectors etc
      • PT Yes, we now carry the ARO option in ND messages over the backbone. That needs to be dissected, but that is a small addition. Probably people doing the openWRT will do it. DIego has a stucdent I think who is working on it.
  • [07.??] PlugTest Scope
    • MR: we had a call for scope
    • in Paris, in Inria, 2-4 Feb, we still have to decide whether full 3 days
    • technical: we want to keep the test that we did last time, keep for example multi-hop scenario. We need to add as well the 6top draft. Discussion on whether we add SF0 as well. Given the timeline, will be too short, so we just want to focus on the basic 6P interaction. We also probably include the 6loRH. Draft spec by 18 Dec. Final version 22 Jan.
    • thanks to OpenMote, each participant will get Golden Device. We plan to have an updated version of the dissector.
    • invitation has been sent by ETSI. we expect people to register.
    • TW: very cool, after the plugtest we will have the minimal implementation + 6lo routing dispatch which has set the address in RH3 to 2 bytes. After that, depending on the minimal configuration, we will have distributed scheduling which will determine which cells will be removed and re-allocated.
    • PT: should minimal then point to 6loRH
    • PT: right before the meeting, published summary to the ML. To answer Ralph, we need to insist that we support 6LoWPAN. Xavi, please review the summary. Then we will work with Brian to see if this answers his concerns.
    • Thomas: do we make the 6LoRH a MUST in minimal
    • Pascal: looks like the right thing to do but then do we deprecate calssical IP in IP / RH / RPI ?
    • Pascal: We need to poll the ML on this
  • [07.??] 6top drafts (next steps)
    • Xavi: drafts stable in the recent month. Presenting a summary of issues. Addressed in the ML and current version.
    • Xavi: Need to process item 2 about sequence numbers. I think we'll use a token
    • Pascal: that is fine, as long as we can transactionally ensure that both sides agree on the cell attribution
    • Thomas: There was also a 3-way question
    • Pascal: Yes, the parent always allocates the cells in both directions. If the child is in need, then it can request an allocation and provide a black list of times that it can not accept. Then the parent comes with a cell list that avoids those times. Then the child selects a cell, that's 3 messages total.
    • Thomas: how long we wait fro retry is out of the scope of 6top. That's part of the scheduling function (SF).
    • Xavi: use existing IEs vs. agree with IEEE. This is ongoing and need to sync with Pat
    • Pascal: please cc the IEEE interest group when we discuss this
  • [08:07] AOB next call is after the YE break

  • [08.10] Meeting ends

Updated