[6tsch] IETF87 6TSCH BoF minutes

[Thomas Watteyne <[e-mail]>]

All,

You will find the minutes of the 6TSCH BoF during IETF 87 at:
https://bitbucket.org/6tsch/meetings/wiki/130730b_ietf-87_berlin_bof

I also copied them at the end of this e-mail.

Let's give ourselves one week to work on/discuss these minutes. Once we
have reached consensus, I will upload them into the proceedings.

If you find any errors/inaccuracies, or know missing names, please reply
directly to this e-mail.

Thomas

---

Minutes IETF 87 BoF, 30 July 2013, 6TSCH group

Note: timestamps in CEST.
Venue

   - Tuesday July 30, 15.20-16.50
   - Bellevue room, InterContinental Berlin, Berlin, Germany

Taking notes *(using Etherpad)*

   1. Xavi Vilajosana
   2. Dominique Barthel
   3. Pouria Zand

Jabber

   - Room: xmpp:[e-mail]
   - Logs: http://jabber.ietf.org/logs/6tsch/
   - Proxy: Guillaume Gaillard

Recordings

   - audio recording<http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3>
    [mp3,43MB]
   - webex recording<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=70245732&rKey=20ae6ae1b0abddfd>
(no
   sound) [streaming]
   - Jabber logs <http://www.ietf.org/jabber/logs/6tsch/2013-07-30.html>

Material

   - BoF Poster<http://www.ietf.org/proceedings/87/slides/slides-87-6tsch-0.pdf>
    [240kB]
   - Consolidated
Slides<http://www.ietf.org/proceedings/87/slides/slides-87-6tsch-1.pdf>
    [1.5MB]
   - All slides<https://bitbucket.org/6tsch/meetings/src/a5501873ad51cb8caa0869202bb19756fb445929/130730_ietf-87_berlin?at=master>

Agenda

See https://datatracker.ietf.org/meeting/87/agenda/6tsch/

6TSCH: Deterministic IPv6 over IEEE802.15.4e Timeslotted Channel
HoppingBoF Agenda
Meeting        :   IETF 87 Tuesday, July 30, 2013Time           :
1520-1650 CEST Afternoon Session II (90min)Location       :
BellevueChairs         :   Pascal Thubert <[e-mail]>
                   Thomas Watteyne
<[e-mail]>Responsible AD :   Ted Lemon
<[e-mail]>URLs           :
https://www.ietf.org/mailman/listinfo/6tsch

https://bitbucket.org/6tsch===========================================================
problem statement [40min]
    what is IEEE802.15.4e TSCH?           [15min] (Maria Rita Palattella,
    (draft-watteyne-6tsch-tsch-lln-context)        Thomas Watteyne)
    what is missing?                      [15min] (Xavi Vilajosana)
    why is this a problem?                [3min]  (Alfredo Grieco)
    status of 6TSCH group                 [7min]  (Thomas Watteyne,
    (draft-thubert-6tsch-architecture)             Pascal Thubert)
discussion of the charter [20min]
    Introduction                          [1min]  (Thomas Watteyne)
    description of the WG                 [4min]  (Dominique Barthel)
    work items                            [10min] (Raghuram Sudhaakar)
    non-milestone work items              [2min]  (Pascal Thubert)
    external work to other WG             [3min]  (Pascal Thubert)
open discussion and questions [30min]
Proposed charter for the BoF: https://bitbucket.org/6tsch/charter-ietf-6tsch/src

Attendance

   - about 60 people present at 3:22
   - about 80 people present at 3:25

Minutes

   - *[15:20]* BoF starts
   - *[15:20]* Introduction *[Thomas Watteyne]*
      - Official pronounciation of 6TSCH is "sixtus"
      - administrivia:
         - be aware of IPR principles
         - circulate blue sheets
         - volunteers for scribes: Xavi Vilajosana, Dominique Barthel,
         Pouria Zand (over Etherpad)
         - Jabber coordinator: Guillaume Gaillard (room address on slide)
      - Note Well
      - Presentation of the agenda:
         - we have 1h30, until 4.50
         - 40min presentation of the problem statement.
         - 10min for clarifying questions
         - description of the charter. URL on the slide.
         - open discussion and question
      - questions are inline on the slides, recap at the end
   - *[15:23]* IT/OT network convergence *[Pascal Thubert]*
      - one slide for set the stage
      - two terms:
         - OT (Operational technologies). :ittle penetration of IETF
         technology in OT world.
         - IT
      - We are preparing the convergence of IT and OT networks
      - We need to provide capabilities, in particular deterministic
      properties
         - we have control over where every packet is. Critical to enable
         e.g. control loops
         - vision of what process control network might look like if we
         move to 6TSCH networks
      - *[15:25]* Approval of the agenda *[Thomas Watteyne]*

   No objections to current agenda. Agenda approved.

   - *[15:25]* What is IEEE802.15.4e TSCH? *[Maria Rita Palattella]*
      - *Thomas* introduces *Maria Rita*
      - overview of data link protocol we want to use within 6TSCH
      - IEEE802.15.4e task group create at 2010
      - amendment of the IEEE802.15.4 that will provide very low power
      consumption and high reliability
      - 3 new MAC (Medium Access Control) mode, Timeslotted Channel Hopping
      (TSCH) is the focus of this group
      - Draft since 2010, published in 2012
      - Uses PHY layer of IEEE802.15.4, no new radio chip needed
      - Widely used in low power wireless mesh networks
      - Provides good tradeof between throughput, energy consumption,
      bandwidth, packet length, range
      - Different working groups created within IETF to provide IPv6
      protocol stack on top of IEEE802.15.4. Can we do the same with
      IEEE802.15.4e TSCH? Would allow networks with better performance.

      request from Jabber: microphone lower. OK.

      - Designed for multi-hop networks. Synchronized operation. Time
      divived in time slots. Grouped in slotframes.
      - Slots are identified by slot offset and channel offset. Cells are
      mapped to a scheduling table.
      - A slot is long enough to send a data frame and receive an ack (10ms
      typical).
      - Clocks drift. Need for synchronization between neighbors. Done by
      exchanging packets to re-synchronize by time stamping.
      - Overhead of synchronization is very low. See
      http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-02.
      - Channel hopping: every packet is sent in a different frequency due
      to channel hopping. Known to efficiently combat multi-path fading and
      narrow-band interference.
      - Translation function from channel offset to frequency.
      - The communication schedule allows for a clean trade-off between
      energy consumption, latency, bandwidth and redundancy.
      - We call "tracks" the multi-hop paths between source and destination
      nodes.
      - Deterministic networking: traffic is known a priori. Deterministic
      traffic flows, known data-rate, known routing path to follow.
      - The link-layer resources are allocated when are needed.
      - Supports traffic engineering
      - Timely transmission because:
         - no hot potato forwarding
         - no exponential backoff
         - no collisions and virtually no jitter
         - no CSMA/CA mechanism
         - collision-free schedule typically built.
      - Good illustration is a train
      - Proven technology.
         - TSMP (2006), then WirelessHART ISA100.11a
         - Commercial products and thousands of networks running using this
         technology.
         - But these are not based 802.15.4e TSCH; missing blocks.
         - Existing systems are monolitic stack. IEEE802.15.4e defines
         layer 2 (link layer), and the interface to upper layers,
making it suitable
         for IETF to build an IP stack.
      - Applications: Control loops, process control, umbrella networks,
      widespresad monitoring, etc.
      - Suitable for traffic engineering.
      - Summary: proven technology, deterministic, flow isolation, TE, low
      power consumption. IT/OT convergence.
   - *[15:41]* What is missing? *[Xavi Vilajosana]*
      - *Thomas* introduces *Xavi*
      - objective: enable OT integration to the Internet architecture. Use
      existing blocks and define missing ones where needed.
      - many building blocks exist. Not all of them in IETF scope. Not all
      of them IPv6 compliant.
      - what does IEEE802.15.4e *not* provide: network formation,
      maintenance, multi-hop topology (how routing protocol builds on top of
      15.4e), ressource management (currently vendors implement own solutions),
      dataflow control (how to manage queue number, priorities w.r.t. to flows,
      retransmission)
      - how do we endure determinism (latency, bandwidth)
      - how to interconnect to PCE (which protocol?)
      - how to distribute keying material, how is authentication done?
      - existing blocks will come from IETF (6LoWPAN, ROLL, CoRE), ISA100,
      WirelessHART
      - missing: schedule computation (centralized and distributed), how is
      the schedule distributed to nodes along the track, missing a
global picture
      (backbone integration, architecture definition)
      - missing: how is QoS enforced, how is the performance monitored, how
      are metrics conveyed to the routing protocol, management of traffic
      classes, queues, differentiated services, how to make RPL know
how to build
      routes on top of layer 2 mesh.
      - missing: keys distribution, label switching based on slots
      (G-MPLS-like), backbone operation, relocation of nodes.
      - global block diagam: how do individual nodes talk to PCE across
      backbone and BackBone Routers (BBR), what if nodes relocate from
one 6TSCH
      network to another?

      Thomas indicates that there has been some discussion on the Jabber
      room about the term MAC. Means "Medium Access Control". We're
talking about
      the link layer.

      - *[15:53]* Why is this a problem? *[Alfredo Grieco]*
      - dissatisfaction because of competing standards
      - IETF has many available building blocks, difficult to put together
      without architecture document
      - open source implementation of the standards
   - *[15:55]* Status of the group *[Thomas Watteyne]*
      - Mailing list started end of January 2013
      - 159 members
      - weekly meeting, Fridays 8am PDT
      - 21 calls until now. Average attendance of 11.2.
      - 2 1.5h meetings at IETF 86 Orlando.
      - Home page at https://bitbucket.org/6tsch/. Contains agenda,
      minutes, recording, draft, source idea, charter.
      - 6 drafts produced so far:
         - https://datatracker.ietf.org/doc/draft-ohba-6tsch-security/
         -
         https://datatracker.ietf.org/doc/draft-palattella-6tsch-terminology/
         -
         https://datatracker.ietf.org/doc/draft-thubert-6tsch-architecture/
         - https://datatracker.ietf.org/doc/draft-vilajosana-6tsch-basic/
         - https://datatracker.ietf.org/doc/draft-wang-6tsch-6top/
         -
         https://datatracker.ietf.org/doc/draft-watteyne-6tsch-tsch-lln-context/
      - 13 authors
   - *[15:56]* Architecture draft *[Pascal Thubert]*
      - Informational draft
      - Entry point into the activity of the group
      - Requirements:
         - Wireless Process control
         - Smart cities
      - Scope:
         - network in a factory flow
         - 6TSCH LLN, you want to interconnect them as they grow.
         Controllers (PLCs, DCS's) that sit in the control loop.
         - Study what is going on the backbone
         - Stack : Almost all components already exist.
         - A few of those components are a bit chatty (PCEP, RSVP)
         - putting some glue
         - The 6top component is the one that does not exist.
      - Centralized vs distributed routing
         - There are cases that we want both cases. Each case has it own
         benefits
         - Architecture: Forwarding in the routing can happen at different
         levels.
         - Traditional IP forwarding
         - Capability to map an incomming time slot to an outgoing
         timeslot. GMPLS-like.
         - 6top switches packets based on label. No need to look at packet
         header.
         - Enables tunneling other protocols (e.g WirelessHART, ISA100.11a)
         - Fragment forwarding. Currently need to recompose each packet at
         each hop. This is inefficient. A draft proposes that first fragment
         installs state in intermediate nodes so that the next fragment can be
         forwarded. This draft may find its home at 6Lo.
         - Integrating components, not considering multicast.
      - *[16:03]* Clarifying questions.
      - *Q.* [*Ted Lemon*] Operational is out of scope, what about
      debugging? Simply not standardized?
      - A. [*Pascal Thubert*] There is work done at ISA100.20 called Common
      Network Management (CNM). Coordinate with them. We might recharter and
      include some work from/with them. CNM is not well advance.
      - *Q.* [*Mehdi Mani*] Why you selected TSCH mode of IEEE802.15.4e?
      - A. [*Thomas Watteyne*] We have experience on that, implementing and
      running networks like this. We are not a research team, engineering.
      - A. [*Pascal Thubert*] Tens of thousands of networks deployed. We
      don't have another alternative that has been proven to work at
that level.
      Emulating for the PCE piece what exists and proven in WirelessHART and
      ISA100.11a.
      - A. [*Thomas Watteyne*] Modes are very different. Scope would be too
      large if we wanted to embrace all.
      - *Q.* [*Mehdi Mani*] Why not another mode?
      - A. [*Pascal Thubert*] As much as we can, not be too specific. For
      example in the future most of our work would apply for e.g. TSCH
over WiFi.
      - Q. [*Mehdi Mani*] Will you skip routing at network layer?
      - A. [*Pascal Thubert*] We are not reinventing anything in routing,
      using existing technology as RPL. We are enabling GMPLS on that
technology.
      - *Q.* [*Shahid Raza, SICS*] You target process automation industry.
      Are you only going to target IEEE802.15.4e, or also ISA100.11a and
      WirelessHART? We can use 6LoWPAN on ISA100.11, WirelessHART is
well adapted.
      - A. [*Thomas Watteyne*] WirelessHART covers a full protocol stack.
      IEEE802.15.4e clearly separates layer 2 from upper layers.
      - A. [*Pascal Thubert*] ISA uses 5-6 RFC from IETF. Constant exchange
      between IETF and ISA. IETF has many components ISA does not have, i.e.
      backbone, DHCP, ND. We are talking aboot converges IT/OT, ISA has none of
      them.
      - *Q.* [*Shahid Raza, SICS*] Minor difference between MAC layers of
      IEEE802.15.4e, ISA100.11a, WirelessHART. What do we target?
      - A. [*Pascal Thubert*] Standards are defined, we cannot change them.
      We hope that ISA100 considers this work for next generation.
Standards are
      locked.
      - *Q.* [*William (?1)*] Confused about scope. Architecture involves
      connecting a deterministic MAC to an infrastructure (i.e. Ethernet). Does
      explicit scheduling in those networs apply to 6TSCH?
      - A. [*Pascal Thubert*] Deterministic ethernet plays at a different
      scale than TSCH, we are talking of 3 or 4 orders of magnitude. Factory
      automation (100Hz control loop) would require deterministic Ethernet.
      Process control can get away with determinitic radio and regular
Ethernet.
      - *Q.* [*William (?1)*] Is there an assumption that there is a low
      packet rate?
      - A. [*Pascal Thubert*] Usually very low.
      - *Q.* [*William (?1)*] Makes sense.
      - A. [*Pascal Thubert*] Next question is whether we can enable on
      WiFi.
      - *Q.* [*Adrian Farrel*] Can the 6TSCH networks be dual-homed into
      the backbone?
      - A. [*Pascal Thubert*] Single subnet. We want to be able to move
      from one LLN to the next without renumbering.
      - *Q.* [*Adrian Farrel*] Could there be a second backbone connecting
      other clouds, so that one cloud is transit?
      - A. [*Pascal Thubert*] We don't consider transit at all.
      - *Q.* [*Adrian Farrel*] Could the PCE be placed inside one of the
      clouds?
      - A. [*Thomas Watteyne*] The architecture locates the PCE on the
      backbone.
      - *Q.* [*Erik Nordmark*] Global optimizations. What does it mean to
      do global optimizations? It is already defined? It is engineering or
      research?
      - *Q.* [*Erik Nordmark*] Backbone router draft in 6MAN. Does that
      mean that backbone not in scope for 6TSCH and we can focus on
what's inside
      single LLN?
      - A. [*Pascal Thubert*] Idea for this group is to coordinate.
      - A. [*Pascal Thubert*] The global optimization is resolved by
      different components but mainly propietary. We don't standardize the
      computation in the PCE.
      - *Q.* [*Jabber (relayed by Guillaume Gaillard)*] Regarding
      centralized and distributed routing, will 6TSCH have to do both? Isn't it
      difficult.
      - A. [*Thomas Watteyne*] Relates to charter discussion, let's ask
      this then.
   - *[16:17]* Introduction to charter *[Thomas Watteyne]*
      - Proposed charter at URL available in the agenda.
      - Announced since April 2013. Work on it in April. Minor adjustement
      in last coupld of weeks.
      - We will follow the outline of the charter to present.
   - *[16:19]* Description of the WG *[Dominique Barthel]*
      - Who are the people on that work:
         - Academia, Big companies, network operators.
         - Americas,Asia, Europe.
         - Around two dozen people very active.
         - PCE, etc. active people in IETF.
         - large WSN deployment experience.
      - Will deliver:
         - Open-Source implementation (OpenWSN UC Berkeley, Nivis)
         - Big commercial companies etc.
         - Availble OS.
      - Charter:
         - TSCH mode of 15.4e - not only 2.4GHz PHY
         - open standard
         - Standardize missing components.
         - Work on backbone routers and PCE and other IPv6 entities.
         - Centralized routing computation
         - best effort resource allocaiton scheme
         - distributed resource reservation
         - IPv6 flows, classes of services.
         - Produce architectural recommendations
         - Coordinate with other std bodies.
      - *[16:25]* Work Items *[Raghuram Sudhaakar]*
      - *Thomas* introduces *Raghuram*
      - key focus is 6top:
         - specification of the sublayer
         - define the hooks that are required by upper layers to setup
         schedules
      - define how to bootstrap a TSCH network
      - 6TSCH centralized routes and tracks management
         - comunication between PCE and 6top
      - 6TSCH distributed routes and track managemnt.
         - how to stablish a path along RPL routes in a distributed manner
      - Minimal 6TSCH configuration
         - For adoption and interoperability testing
         - Hardcoded schedules. Not requiring PCE nor Distributed.
      - 6TSCH architecture:
         - TSCH overview, presents the problem statetment. Presents
         overview of the TSCH MAC layer, presents the missing pieces.
      - 6TSCH security architecture requirements. Authentication of nodes,
      etc.
         - consider PANA protocol.
      - work items 1 and 3 are standard track, the rest are informational.
   - *[16:30]* External work *[Pascal Thubert]*
      - *Thomas* introduces *Pascal*
      - External work. Coordination with other groups (Internet, Routing
      areas)
      - Other documents will be provided (applicability statements)
      - *Q.* [*Dan Romascanu*] What is the list of groups we will work with?
      - A. [*Pascal Thubert*] We have a list in the charter of the groups
      we are going to work with.
   - *[16:32]* Open Discussion
      - *Q.* [*Emmanuel Baccelli, INRIA*] Enthusiastic about this group.
      Concern: a lot of work. Prioritize the work. List of documents,
needs to be
      ordered according to priorities. Order things in time. Scope the charter
      more precisely.
      - A. [*Pascal Thubert*] Point taken.
      - *Q.* [*Lars Eggert*] Footprint for a device, are we able to run all
      this on a resource-constrained device? RSVP, PANA are heavy-weight. May
      need to work on a lightweight version of these, nobody is
working on it at
      this time in their respective WG.
      - A. [*Thomas Watteyne*] We have an open source implementation
      running (RPL, CoAP, IEEE802.15.4e, no PANA, no RSVP). Footprint is about
      4kB or ROM, 35kB of flash.
      - *Q.* [*Lars Eggert*] Be prepared to work without PHP.
      - *Q.* [*Benedikt Stockebrand, Stepladder IT*] Smallest
      microcontrollers known to run USB have 2kB of Flash, 128B of RAM
(including
      CPU registers). Microcontrollers are very limited in resources. If we get
      along this way, microcontrollers able to run this stack will simply be to
      expensive to be usable.
      - A. [*Thomas Watteyne*] It's a constant concern. Centralized
      reservation is intended for very small footprint. This fits in
decade year
      old MSP430-based motes.
      - *Q.* [*Benedikt Stockebrand, Stepladder IT*] A number of people are
      not aware of footprint.
      - *Q.* [*Carsten Bormann*] We have a document from the LWIG WG
      classifying microcontrollers. Class 1 (~10kB RAM, 100kB ROM)
smallest sized
      full citizen of the Internet. ZigBee IP typically on Class 2 device.
      - A. [*Thomas Watteyne*] We target the class 1 devices.
      - *Q.* [*Rafa Marin-Lopez, University of Murcia*] Clarification. We
      have a PANA implemenation on Contiki OS on small Jennic device
for class 1
      micro-controllers.
   - *[16:41]* Questions
      - Is this a topic that the IETF should address?
         - hums for "yes" and for "no" did not produce a clear decision.
         - show of hands: lots of "yes", a few "no", a handful "dunno".
      - Are the goals of this WG clear, well-scoped, solvable, and useful?
         - 50/50 between yes and no
      - *Q.* [*Ralph Droms*] Strange use of raising hands. Why not record
      hums?
      - *A.* [* (?2) *] I prefer show of hands, countable and unambiguous.
      Hums on depend on where you sit in room.
      - *A.* [* (?3) *] Hums are good for getting sense of the room. If you
      don't get a good sense, you need to clarify.
      - Who is willing to edit documents, comment documents, implement?
         - About 20-30 people raise hands.
      - Should a 6TSCH WG be formed?
      - *Q.* [* (?4) *] Clarifying question. As chartered? Topic is usual,
      but roles are not clear.
      - *Q.* [*Pascal Thubert*] How should we work it out?
      - *A.* [* (?5) *] You've gotten the useful data out of the room
      already. There was clear support for "is the topic useful". Are the goals
      clear? There was clear hesitation. That's the information you
need to know.
      - *A.* [* (?6) *] Use the posaitive energy that was shown here for
      improving the charter.
      - *[Pascal]* Next step will be to work on the ML to on improving the
      charter, and ask those who voted it was not clear to participate in
      clarifying the charter.
      - *Q.* [*Alex Petrescu*] Back to question "is this a topic that the
      IETF should address?". Should also ask yourselves if there is another SDO
      should address. Maybe this is something somebody else should work on.
      - A. [*Pascal Thubert*] IETF is producing lots of components. It is
      dificult to put them together. One of the goals is to package these
      components.
      - *Q.* [*Shahid Raza*] WirelessHART is discussing IEEE802.15.4e.
      - A. [*Pascal Thubert*] Question is whether we can build the
      convergence IT/OT.
   - *[16:50]* End of meeting