Minutes for 6TISCH at IETF-94

Meeting Minutes IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG
Title Minutes for 6TISCH at IETF-94
State Active
Other versions plain text
Last updated 2015-11-14

Meeting Minutes

   # Minutes, IETF 94 6TiSCH WG Meeting #

Note: this document is formatted using Markdown

Agenda and Meeting information

Meeting        :   IETF94 Thursday, November 5, 2015 (JST)
Time           :   15:20-17:20 JST Thursday Afternoon session II (2h)
Location       :   Room 303, Pacifico Yokohama, Yokohama, Japan
Chairs         :   Pascal Thubert
                   Thomas Watteyne
Responsible AD :   Brian Haberman
URLs           :   http://tools.ietf.org/wg/6tisch/

Intro and Status                                 [5min]  (Chairs)

   Note-Well, Blue Sheets, Scribes, Agenda Bashing

New Charter                                      [25min] (Chairs)
   * Status Document
   * New Charter
   * Milestones
   * Action Plan

Dynamic Scheduling
   *         [20min] (Xavi Vilajosana)
   *           [20min] (Maria Rita Palattella)

Tracks in 6TiSCH
   *            [20min] (Pascal Thubert)

Any Other Business
   * Announcement second ETSI 6TiSCH Plugtests   [10min] (Miguel Angel Reina


* agenda: https://www.ietf.org/proceedings/94/agenda/agenda-94-6tisch
* presented slides:
https://www.ietf.org/proceedings/94/slides/slides-94-6tisch-0.pdf * Meetecho
recording (audio+video):
* Jabber log: http://www.ietf.org/jabber/logs/6tisch/2015-11-05.html


[This summary is transmitted to the INT area ADs]

The 2-hour 6TiSCH meeting focused mainly on 3 elements:
- rechartering. This has been discussed during 2 interim meetings, and the text
presented at the WG meeting summarized the conclusions from those discussions.
The proposed new charter builds upon the old charter, and introduces dynamic
scheduling of cells. Several constructive remarks were made about the
presentation of the different work items; the chairs took as action items to
integrate those in proposed charter text, and to transmit it to the IESG. - the
main technical part of the meeting was dedicated to the
draft-wang-6tisch-6top-sublayer-03 and draft-dujovne-6tisch-6top-sf0-00 drafts
(both of which are complementary). No major issues were raised about these
draft, but the WG asked a number of clarifying technical questions and make
some smal suggestions the authors agreed to integrate. - a presentation of
draft-thubert-6tisch-4detnet-01, which links the work done at 6TiSCH with the
work done at DetNet. The chairs asked for more feedback on the document on the

A number of other points were raised:
- draft-ietf-6tisch-minimal-12 was transmitted to the IESG a couple of weeks
before the IETF94 meeting. Three constructive reviews were sent back to the WG.
To advance the work on the draft, and in the interest of time, the reviews are
discussed on the ML. We had a discussion on the status of the draft (currently
Proposed Standard), which we will conclude on the ML. - We announced the second
6TiSCH plugtests event to be held on 2-4 February 2016 in Paris, France,
organized by ETSI and hosted by Inria. - We had an announcement about a Study
Group created at the IEEE around defining an LLC which could include work from
the 6TiSCH and 6lo WGs, as well as a KMP and L2R routing protocol. We agreed to
continue the IETF/IEEE liaison around that aspect. The same announcement was
made in the 6lo and ROLL WGs, with a longer presentation at the INT Area

The full minutes, the detailed action items and the presented slides are
published in the IETF material manager. The meeting was recorded through
Meetecho, and the recording (audio+video) is available. ```

Action items

* **Chairs** to rework the charter text:
    * use bullet list, not numbered list
    * put a statement which explains that the architecture follows the progress
    of the standardization, and will not be delivered first * reorder items? *
    rework text around what can be done at the IEEE
* **Chairs** to finalize discussion about status of 6tisch-minimal on ML
* **Authors** of draft-wang-6tisch-6top-sublayer to take into account the
following remarks:
    * The child should be able to ask for a number of cell _without_ specifying
    a cells in the CellList, so that the parent can choose from a chunk it has
    set aside for that node. * would it make sense to have a transaction
    identifier in 6P?
* **Chairs** to coordinate with IEEE/IETF liaison group to request an IETF
Information Element Payload Group ID to the IEEE.


* Scribes
    * Dominique Barthel
    * Alexander Pelov
* Jabber
    * Robert Cragie


* [15.22] Meeting starts
    * ~45+25 participants (local/remote)
* [15.22] Intro and Status (**Thomas Watteyne**)
    * Thomas presents Note Well slide
    * Shows agenda and queries for comments: none. Agenda is approved.
* [15.24] New Charter (**Pascal Thubert**)
    * New charter text discussed at last IETF and at a several latest interim
    calls * First generation of charter limited to static schedule * Now
    proposing capability to negotiate schedule between nodes * Milestones:
    6TiSCH architecture not delivered in time, postponed until other work done
    to publish only one volume or architecture. Work in progress. New content
    will come with dynamic scheduling work. CoAP data model and information
    model publication postponed until CoMI is delivered. * New charter has 3
    new work items:
        * dynamic scheduling on top of 6top
        * secure bootstrapping: a lot of work done on the mailing list already
        although not in first charter. * track definition and DetNet
        requirements. Be able to tell DetNet what 6TiSCH provides.
    * New charter text shown, in final discussion
    * Requests to work on track definition and mechanism. Planned for 3rd gen
    charter. * Current non milestones work items: Test Description for next
    ETSI 6TiSCH plugtest. * [**Brian Haberman**] is order in list on screen
    order of doing work? Architecture first? * [**Pascal Thubert**] on-going
    work on architecture. Only published after other work done. * [**Brian
    Haberman**] numbered list looks like ordered list. It is important to note
    that the architecture is a work in progress that will be updated as the
    time goes by. Some people wait for a document to be published, before they
    start reading it. Making it explicit may help some people understand and
    read it before. * [**Pascal Thubert**] we will remove the numbers, place
    bullets and rewrite that architecture will be continuously worked on and
    not delivered. > Action item: **Chairs** to rework the charter text. *
    [**Brian Haberman**] Test Description looks like compliance testing. *
    [**Thomas Watteyne**] This text just reflects what we have been doing in
    first 6TiSCH plugtest. * [**Pascal Thubert**] requirements to be able to
    play the interop game. Otherwise, implementations could have nothing in
    common. * [**Brian Haberman**] intention to publish into RFC? * [**Thomas
    Watteyne**] no * [**Chonggang Wang**] The IoT router in bullet 3 is not
    defined * [**Pascal Thubert**] Need to check the exact definition *
    [**Pascal Thubert**] for this charter, rely on fact that IP packets have IP
    addresses. In the future, may be able to tag. You're welcome to do work in
    advance on something non-chartered. Right now, we're committed to deliver
    the deliverables in the charter. Architecture give the overall view, but
    not everything on current charter. * [**Subir Das**] bullet #2: what is
    going to be done here and what at IEEE? * [**Pascal Thubert**] right now,
    6top not in IEEE. We'll see in the future. * [**Subir Das**] would be good
    to clarify what exactly could be done in the IEEE in the charter. >
    Action item: **Chairs** to rework text around what can be done at the IEEE.
    * [**Thomas Watteyne**] we had a liaison meeting with IEEE to discuss that,
    will continue the collaboration. * [**Samita Chakrabarti**] The 6TiSCH
    architecture will be running on 6LoWPAN. 6lo WG would like to have the
    reviews done as well. * [**Pascal Thubert**] Agreed and positive on this.
    It is on a case-by-case basis. Let's continue working on this together. *
    [**Pascal Thubert**] personal opinion that a lot of this will work on a lot
    of PHYs.
* discussion 6tisch-minimal reviews (**Thomas Watteyne**)
    * [**Thomas Watteyne**] (6tisch-minimal): not a proposed standard draft.
    Brian and Suresh questioned this choice during their review of the doc. *
    [**Brian Haberman**] It seems that they are exploring different ways to do
    a minimal 6tisch deployment. * [**Thomas Watteyne**] We are not planning to
    replace it but to enhance it. * [**Tero Kivinen**] should get rid of ...
    Says for interop testing. Can't be a standard. * [**Brian Haberman**]
    Should be a BCP, gets the same level of review. * [**Thomas Watteyne**]
    Agreed. * [**Tero Kivinen**] Can the minimal setup change? Maybe it is
    better that when you create the network you set some parameters (profile)?
    * [**Brian Haberman**] if Informational document, would simplify review
    process. * [**Tero Kivinen**] There is not a single protocol element there.
    Only describing a set of IEEE parameter values. * [**Michael Richardson**]
    is draft-minimal not about getting enough bandwidth for RPL to run? Sounds
    much more than informational. * [**Robert Cragie**] If this is really a
    profile that works fine but it does not belong to IETF. * [**Tero
    Kivinen**] More of a profile than a protocol. The reviewers indicated too
    much text was copied from 15.4 standard. Understood that 15.4 hard to read
    and copying makes it easier. * [**Robert Cragie**] Test documents should
    not become RFCs. * [**Thomas Watteyne**] It was never the intention of the
    WG to publish Test Descriptions as RFCs. * [**Michael Richardon**] After
    discussion, no objection for -minimal to become BCP or informational.
* [15.59]  (**Xavi Vilajosana**)
    * Xavi presents the slides. Will focus on comments by Charles Perkins on
    mailing list. Main focus 6TiSCH Sublayer and 6top * Draft introduces
    scheduling function but no details, out of scope for this doc. * 6top sits
    on top of 15.4e, declares the need for Scheduling Function. * One question
    was about the coexistence of minimal and 6top. Recommend use higher
    priority for minimal. * Example of protocol exchange: container ID
    designates slotframe, bundle, chunk, whatever 6top wants to operate on *
    Suggest to define sub-IE to contain commands an response codes. *
    Discussion of 1 vs 2 bytes for slotoffset and channeloffset. * Operations:
    ADD/DELETE/LIST on cell lists. * 6P can do version checking, SFID checking,
    concurrent transactions, timeouts, etc. * [**Pascal Thubert**] on slide 31.
    Cells are owned by RPL parents. What if a child needs a slot, how does it
    go to the parent to ask for a cell? * [**Xavi Vilajosana**] Child can
    request a cell, but the pool belongs to the parent. This slide needs to
    describe the case where the child does the request. * [**Thomas Watteyne**]
    changes the way the messages are used. * Xavi resumes presentation. * Next
    steps: need agreement with IEEE to get GROUP_ID for IETF. * [**Thomas
    Watteyne**] idea is to have a GROUP_ID for IETF so that IETF can manage the
    sub-IDs with IANA. * [**Tero Kivinen**] There are only 16 GROUP_IDs; it
    might be interesting to use IEEE802.15.9's multiplexing where there are
    65535 IDs. * [**Pascal Thubert**] we have an Interest Group for 6TiSCH at
    IEEE. We ask that interest group to help us identify how we can transport
    our 6top IEs. * important issues raised during review my Charles Perkins:
        * non-local statistics
        * on which cells are the 6top commands transmitted? on -minimal cells
        first, then as bandwidth is made available on dedicated cells, on
        those. * role of SF at boot. Initial behavior?
    * [**Charles Perkins**] on retry policy. Brought it up because in the past,
    a draft got rejected because retry left variable. * [**Thomas Watteyne**]
    either in the core of protocol and well-known to all nodes, or in the SF
    and can be flexible. * [**Thomas Watteyne**] further discussion on the
    mailing list
* [16.23]  (**Maria Rita Palattella**)
    * new draft but work has been going on for a while. On-the-fly scheduling
    has had 6 revisions already. * 3 steps: monitor traffic per node / estimate
    need / determine  changes to apply * estimate based on node's own traffic
    and children traffic to be forwarded * Threshold beyond which action is
    triggered to change allocation * at requesting node side, pick slot offset
    randomly * source node can request destination to CLEAR all cells
    allocated. Can ask for cells re-allocation if too low a PDR. * if
    destination node could not allocate requested cells, will return an error
    message. Source node could provide a completely different list. *
    memorizing cells that were refused to not request them again, or just
    random. * [**Pascal Thubert**] manage the full transaction with a sequence
    number? otherwise, may loose track of which request gets accepted or
    denied. * [**Thomas Watteyne**] we ruled out concurrent transactions, so
    should not be a problem. * [**Pascal Thubert**] but no retry policy * Maria
    Rita resumes presentation of error handling. * Todos: container field
    inside 6top request; examples of error handling
* [16.39]  (**Pascal Thubert**)
    * new work taking place in DetNet and PCE, that could be useful to 6TiSCH.
    Our architecture should be clarified and exposed to other groups so that
    they can use it as input. Describe the 6TiSCH tracks. Most text taken from
    architecture draft. * in DetNet, packet replication on different paths.
    Whether 6TiSCH wants to do that is TBD. * 6TiSCH can easily do per-link
    replication (copy only sent if original did not go through). Replication on
    different paths would be new. * We should agree in this WG what we do
    before we can tell other groups. * Maybe create a separate document just on
    tracks, extracted from architecture. * [**Pascal Thubert**] who read the
    document? (5) * [**Pascal Thubert**] read and speak up if you disagree.
* [16.47] Announcement second ETSI 6TiSCH Plugtests (**Miguel Angel Reina
    * after first plugtest at Prague on draft-minimal
    * second plugtest for 6TiSCH will take place on 2-4 February 2016, in
    Paris, France, organized by ETSI and hosted by Inria. * the scope of the
    tests is:
        * start from the tests in Prague, and hence continue on draft-minimal,
        including multi-hop and link-layer security * add elements of the 6top
        Protocol * but still early enough in the process that we are open to
    * same group of experts as last time. Will put together test
    specifications, will do tech support during plugtest and will report to EC
    after the event. * learned from first plugtest that most issues were
    discovered before the event. So will strive to issue test documents and
    golden device early. * website launched in the next few days. * sponsored
    by EC, event is free of charge. * Third 6TiSCH plugtest envisaged at IETF96
* [16.54] Announcement 802.15.12 work in the IEEE (**Charles Perkins**)
    * 15.LLC Interest Group voted to form Study Group that had first meeting
    recently. * general goal is to make 15.4 easier to use. Right now, a lot
    left to implementors. * should be as easy to use as 802.11 and 802.3 *
    interface for Key Management Protocol (KMP) and L2 routing. * 802.15 has
    growing awareness of 6TiSCH thanks to 6TiSCH interest group at IEEE, that
    reports at every meeting about 6TiSCH progress * on the todo list: dispatch
    code (a la Ethertype), 15.9 and 15.10 alignment with LLC, etc. * provides
    link to presentation on LLC on IEEE side * at January meeting: submit PAR
    (Project Authorization Request) and CSD (Criteria for Standard Development)
    * [**Pascal Thubert**] how is it organized? 802.15.12 will not be merged
    into 802.15.4 release? * [**Bob Heile**] (802.15 chair): 802.15.12 and
    802.15.4 would have reasonably distinct content so they can be kept
    separated. LLC work would be delivered separately from 802.15.4 and not
    wrapped into 802.15.4 revisions. * [**Thomas Watteyne**] at 6TiSCH, we plan
    on just continuing our work at the current fast pace. Discussion and
    coordination with IEEE will happen in parallel. * [**Charlie Perkins**]
    agree that both groups want the same thing. Other "customers" also out
    there. 6TiSCH is a primary custimer that LLC wants to keep satisfied
* [17.09] Other Business
    * No other business.
* [17.10] Meeting ends