Clone wiki

meetings / 150323_ietf92_dallas

Minutes IETF 92 WG meeting, 23 March 2015, 6TiSCH WG

Note: timestamps in CDT.

Information and agenda

Note: there are two 6TiSCH WG meetings at IETF92 Dallas, on Monday and Thursday.

Meeting        :   IETF92 MONDAY, March 23, 2015
Time           :   1520-1650 CDT Monday Afternoon Session II (90min)
Location       :   Continental room, The Fairmont Dallas, Dallas, TX, USA
Chairs         :   Pascal Thubert <>
                   Thomas Watteyne <>
Responsible AD :   Ted Lemon <>
URLs           :

Intro and Status                                 [2min] (Chairs)

   Note-Well, Blue Sheets, Scribes, Agenda Bashing

DetNet (cancelled during bashing)

   * <draft-finn-DetNet-architecture-00>         [20min] (Norm Finn)
   * <draft-gunther-DetNet-proaudio-req-00>      [10min] (Jouni Korhonen)
   * <draft-wetterwald-DetNet-utilities-reqs-01> [10min] (Patrick Wetterwald)
   * <draft-wang-6tisch-track-use-cases-00>      [10min] (Chonggang Wang)           

6TiSCH vs. DetNet 

   * 6TiSCH vs. PCE related to track operations  [35min] (Pascal Thubert)
   * <draft-wang-6tisch-track-use-cases-00>      [10min] (Chonggang Wang)           

Security                                         [35min]        

Security                                         [30min]
   * DT status and design goals                          (Michael Richardson)
   * <draft-struik-6tisch-security-considerations-01>    (Rene Struik)

Wrap up for rechartering                          [8min] (Chairs)


Etherpad (

  • Dominique Barthel
  • Nicola Accettura

Jabber (

  • Diego Dujovne

Resources, Recordings and Logs

Draft slides and status at

what where
Presented Slides
Audio Recording [mp3,70MB]
Meetecho Recording
Jabber Logs


  • [15.23] Meeting starts
  • [15.24] Intro and Status (Chairs)
    • Note-Well, Blue Sheets, Scribes, Agenda Bashing
    • Agenda change: first 3 drafts will not be presented because they are too far from WG charter.
    • Expect a barBOF this week to discuss them.
    • There will be a discussion at PCE on 6TiSCH deterministic requirement, Pascal to present now.
    • maybe a WG-forming BOF in Prague
  • [??.??] (expected: 15.22) <draft-finn-DetNet-architecture> (Norm Finn)
    • skipped
  • [??.??] (expected: 15.42) <draft-gunther-DetNet-proaudio-req> (Craig Gunther)
    • skipped
  • [??.??] (expected: 15.52) <draft-wetterwald-DetNet-utilities-reqs> (Patrick Wetterwald)
    • skipped
  • [15.28] (expected: 16.02) <draft-wang-6tisch-track-use-cases> (Chonggang Wang)
    • new draft, on industry networks.
    • two applications: process control and automation; monitoring;
    • same architecture
    • describes first application: communication between two constrained devices across two LLNs interconnected through a backbone. Track can be established beforehand by centralized controller.
    • describes second application: following anomalous condition, a constrained devices sends an alert and needs a track to send ensuing monitoring data. Dynamically established.
    • 6tisch-architecture draft mentions centralized and hop-by-hop track reservation. This draft provides requirements for theses track establishment. For example, quickly detect track establishment failure.
    • Suggestion for next steps?
    • Q&A
    • Thomas: you mentioned redundancy, how to get that? I suggest you look at impact on YANG model, see 6tisch-interface draft. Do you recommend any change to this model?
    • Zhuo Chen, co-author of this draft: <...I didn't get that>
    • Pat Kenney: slide 40. Re: redundancy, ISA100.11a has duocast. We should consider that here, too.
    • Pascal: replication and elimination is core to DetNet
    • Pat: found that timeslot needs to be made slighter wider. 12ms instead of 10 in order to enable duocast as done in ISA100.11a.
    • Thomas: works with 4e, now 15.4-2015? Pat: yes.
    • Thomas: two acks? Pat: yes, talk offline.
  • [15.47] 6TiSCH vs. PCE related to track operations (Deterministic Networking) (Pascal Thubert)
    • Need to convey time sensitive packets as well as regular ones on a same network.
    • explains train analogy: trains are scheduled to leave stations at predefined absolute times to avoid collisions outgoing
    • explains bus analogy: the schedule is computed in advance; buses run at known period, transport in the bus between A and B takes a known time, so maximum latency of wait for bus + transport is known.
    • for what kind of apps? industry, audio/video, vehicle, smart-grid. Work at IEEE 802.1 (AVB and now TSN)
    • track management is not specified by 6TiSCH. We only define the interface to program the 6top layer.
    • determinism: back to physical, real hardware, real time.
    • for single track, could use RPL to compute and reserve track.
    • for replication & elimination (needed for time determinism, retransmission won't do): nobody knows how to do it in distributed fashion. Industry does it with centralized manager/controller
    • what does this controller need to operate upon, what does it produce as output?
    • state needs to be installed in the network nodes, flows need to be labeled. Need to extend work done at TEAS and CCAMP.
    • may make use of PCE protocol to program each device.
    • inside the controller: PCE takes topology and requirements to produce routes. Also, Track management maintenance. Measurement unit.
    • 6TiSCH is deterministic MAC. Can be used for deterministic traffic. Need to leverage PCE/CCAMP/TEAS to achieve that.
    • 6TiSCH will define requirements for DetNet
    • differ discussion on should DetNet be a separate WG to rechartering discussion later.
    • Q&A
    • Samita: how often will the PCE configure the schedule
    • Pascal: There is usually a first global computation for which a shower model is appropriate, the PCE programs the full schedule in all nodes one by one. Then there is the async path creation and update, for which a classical TE way is more appropriate.
    • Samita: what about movement? Central controllers usually have long latency.
    • Pascal: DetNet has 3 core components. One nails down the path. This is usually not really appropriate for movement but that is only one of the techniques in DetNet. And it can be made more dynamic by pushing the computation in the fog at the edge of the network. Mobile application may require edge buffering.
    • Thomas: many systems use centralized and work just fine, including ISA100.11a.
    • xxxx: reliability? smart grid use case. SDN approach. Need to consider inter-controller communication. Suitable protocol? Openflow, PCE?
    • Thomas: see 6tisch-coap draft. Using Comi. There will be a Presentation at the second meeting on Thursday.
  • [??.??] (expected: 16.12) DT status and design goals (Michael Richardson)
    • nothing to present, Michael will discuss this as part of the "rechartering" section
  • [16.13] <draft-struik-6tisch-security-considerations-01> (Rene Struik)
    • posted end of Jan.
    • since IETF91, added details on MAC functionality, ...
    • refresher on IETF91 presentation: desired properties
    • current draft assumes devices have public key security on board. Most will also fit non-public key. Assumes there is communication path between node and server.
    • next draft: devices with less requirements. No certificates, non-public-key, ...
    • also add details on protocol.
    • also look at impact of relaxing security conditions, look at deployment life cycle.
    • Pascal: look at SACM WG, seems like doing similar work.
    • also add privacy considerations, key compromise
    • also explain how node gets IP addresses, about network discovery (many drafts around)
    • let's try to unify draft currently appearing in Anima, 6lo, 6TiSCH
    • consider new scenario with sprinkled-in nodes (disposable)
    • Sandeep: how does the node decide to join the network or not? Rene: some language in there.
    • René ask the audience if thinks this is useful/extensible enough?
    • Thomas: like the fact that PSK will be taken into account.
    • René: we need data points to do the right trade-off.
    • Thomas: with shared secret, less bandwidth required to join in.
    • Robert Cragie: do you thing there is a way unifying all these drafts on security? They might be appearing in different groups for a reason.
    • René: some aspects depend on MAC functionality (in the case of this case, 15.4e TSCH), but 90% of it is independent. MAC behavior is explicitly referred to.
    • Pascal: IoT directorate. Next session exactly about these various security drafts.
    • René: do something without too much overhead (UN !)
    • Subir Das:
    • Samita (with 6lo co-chair hat): invite to discuss with 6lo WG. This week, informal meeting on security on Thursday evening 7pm, location to be announced.
  • [16.42] Wrap up for rechartering (Chairs)
    • two topics at hand: centralized scheduling DetNet, and security. Regarding DetNet, we know what we want, already implemented in ISA100.11a. Group is asker to read DetNet drafts.
    • Pascal asks a question to the group about DetNet: should we incubate or fork?
    • Subir: including all this DetNet is a lot, even for extended rechartering. Suggest a separate group.
    • Pat K: agrees that a separate DetNet group would help have a better system understanding. It's not just about 6TiSCH.
    • Pascal: would love Chonggang's draft to spell out the number of tracks, of nodes, the latency requirements, the number of flows. To use as input to DetNet.
    • Norman Finn: depends on whether you think wired or wireless. In audio systems, not about 6TiSCH. Would like to see a "side meeting" (aka barBOF) in Prague.
    • Pascal:
    • regarding security: time-out, will discuss on Thursday. Same room here.
  • [16.51] Meeting ends