Clone wiki

meetings / 130730b_ietf87_berlin_bof

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

Note: timestamps in CEST.


  • 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






6TSCH: Deterministic IPv6 over IEEE802.15.4e Timeslotted Channel Hopping
BoF Agenda

Meeting        :   IETF 87 Tuesday, July 30, 2013
Time           :   1520-1650 CEST Afternoon Session II (90min)
Location       :   Bellevue
Chairs         :   Pascal Thubert <>
                   Thomas Watteyne <>
Responsible AD :   Ted Lemon <>
URLs           :

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:


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


  • [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): Little 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 trade-off 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 divided 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
    • Channel hopping: every packet is sent on 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), resource 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]
  • [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. [Thomas Narten] I prefer show of hands, countable and unambiguous. Hums on depend on where you sit in room.
    • A. [Ted Lemon?] 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. [Lars Eggert] Clarifying question. As chartered? Topic is usual, but roles are not clear.
    • Q. [Pascal Thubert] How should we work it out?
    • A. [Thomas Narten] 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. [Ted Lemon?] 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