Wiki

Clone wiki

meetings / 130730a_ietf87_berlin_pre-bof

Minutes IETF 87 pre-BoF meeting, 30 July 2013, 6TSCH group

Note: timestamps in CEST.

Venue

  • Tuesday July 30, 09.30-11.15
  • Tegel room, InterContinental Berlin, Berlin, Germany

Goal

The goal of this meeting is to:

  • rehearse for the BoF
  • present the drafts we will not have time to present at the BoF

Jabber

Taking notes (using Etherpad)

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

Present (alphabetically)

  1. Alejandro Lampropoulos
  2. Alfredo Grieco
  3. Daniel Popa
  4. Diego Dujovne
  5. Dominique Barthel
  6. Etienne Dublé
  7. Guillaume Gaillard
  8. Laurent Toutain
  9. Marc Blanchet
  10. Maria Rita Palattella
  11. Olivier Alphand
  12. Pascal Thubert
  13. Pouria Zand
  14. Rafael Martinez-Lopez
  15. Raghuram Sudhaakar
  16. Subir Das
  17. Thomas Watteyne
  18. Xavi Vilajosana
  19. Yoshihiro Ohba

Minutes

  • [09:34] Meeting starts
    • Thomas announces the goal and agenda
  • [09:38] IT/OT network convergence slide [Pascal] [took 03min30]
    • control loops
    • automation process control.
    • large scale monitoring
    • convergence IT/OT -- deterministic networking
    • capability to schedule the network == determinism
  • [09:39] What is IEEE802.15.4e TSCH? [Maria Rita] [took 18min]
    • Thomas introduces Maria Rita
    • 802.15.4e - created in 2012 -- ammendment
    • low power multihop mesh network.
    • better feature for low power. Time Slotted CH.
    • synchronization and ch.hopping
    • PHY layer is 15.4 used for LLNs
    • 6LoWPAN, ROLL and CORE WG work on top on that PHY/MAC
    • [09:39] Thomas explains TSCH details
      • TSCH network is sychronized
      • Synchronization. Clocks drift, to cope with that there is mechanism in the std.
      • CH.hopping,
      • nodes only wake up when they need to communicate. CH: provides reliability.
      • Schedule: tradeoff between throughput, latency, radundancy.
    • [09:48] Maria Rita on deterministic networking
      • no contention
      • suitable for traffic engineering. traffic flow can be managed according QoS needs.
      • Network is synchronized.
      • No delays.
      • No jitter
      • Network like a train system.
      • Proven technology: Wireless HART, ISA100.11a. Products exist but not based on 15.4e
      • what we need something that work on 15.4e and also works with IPv6
      • New Applications:
        • Control Loops, Process Control, Umbrella networks thanks to TE, As Low Power Energy harvesting comes into play.
        • Widespread (dense) monitoring -- open loop.
      • Summary: TSCH a mac layer ammendment of the 15.4 std. low power, ts, ch,
        • flow isolation,etc.
        • proven technology
  • [09:57] What is missing? [Xavi]
    • Thomas introduces Xavi
    • use existing blocks and glue them together, into an IETF architecture.
    • maybe a few little pieces missing
      • out of scope in 15.4e
      • network maintence which is not addressed by 15.4e
      • multihop topology
      • how ot build the schedule
      • dimension the queues, set priorities
      • ensure latency, ensure reliability
    • Blocks com from 6LoWPAN, ROLL, CoRE, not thought for deterministic MAC. Other
    • missing blocks
    • Schedule computation
    • A global picture
    • Schedule computation
    • Many solutions such as RSVP, NSIS, et...
    • Missing guidline even for dis. or centralized
    • Missing blobks
      • identify solutions, provide guidelines
      • Other blocks: enforce QoS, monitoring, rescheduling
    • Traffic engineeting
    • Explains typical network buildup. Problem of matching RPL routes to TSCH schedule. How to do this?
    • Key distribution, commissioning/joining, authentication
    • Tunneling
    • Need to define backbon operation, ,ND, reallocation of nodes.
    • Security: open problem: secure joining of new node. Is this a repeat of previous slides, or getting into more details??? Clarify [TW: Agreed]
    • Backbone.
  • [10:09] Why is this a problem? [Alfredo]
    • Thomas introduces Alfredo
    • competing standards not interoperable.
    • std competing cannot be managed in the same way. From the other side, QoS, care about
    • pure deterministic services - dificult support reallocation. Change of topology is agains determinism
    • Centralized vs distributed approaches. Centralized approaches - "god view", it is ok for optimization, distributed approaches more scalable.
    • distributed might lead to not optimal approaches.
    • global architecture is still missing.
    • hinder adoption IETF std.
    • Open Source impl of std -- Fast IoT deployment
  • [10:13] Update on the status of the group [Thomas] [took 3min]
  • [10:16] draft-architecture [Pascal]
    • Informational.
    • Requirements:
      • Wireless Process Control
      • Smarcities
      • Building automation
      • etc.
    • Scope:
      • Architecture
      • support all use cases:
        • distributed routing
        • centralized routing
        • advantages for both.
      • Classical routing:
        • traditional forwarding at L3
      • Track operation:
        • GMPLS model: L2 operations- tslot in - tslot out
        • create end to end path
        • 6top uses a switching table
        • tunneling model
      • Oportunistic track slot reuse.
      • Forwarding fragments:
      • Question: 15.4g enables longer packets. Does 6top will work on other MAC different from 15.4e tsch,
        • fragmentation.
  • [10:24] Clarifying Questions [Thomas]
    • Will not be taken now, but 10min allocated in the afternoon
  • [10:25] Proposed charter [Thomas] [took 1min]
    • published first April 2013
      • Background
      • description
  • [10:26] Description of the WG [Dominique] [took 6min]
    • Who are the people on that work:
      • Academia, Big companies, network operators.
      • Americas,Asia, Europe
    • Expertise:
      • implementators. IETF, companies, milions of nodes from companies being represented in the group
    • Deliver:
      • Open source
        • OpenWSN. Nivis.
      • Development of comercial solutions by companies
      • Different O.S: OpenOS, FreeRTOS, etc..
    • Charter:
      • TSCH mode of 15.4e
      • Other frequency bands than 2.4, as we focus on TSCH not PHY
      • Open Standard based network
      • Missing pieces to achieve industrial quality.
      • 3 models:
        • centralized version
        • best effort.
        • distributed with RPL
      • Produce arch. recomendations.
      • Informally coordinate: IPSO, ISA, IEEE, etc..
  • [10:32] Work Items [Raghuram] [took 10min]
    • Defining the 6top layer.
      • 6top specification
      • centralized management
      • distributed managemetn (rsvp)
      • Minimal 6TSCH configuration (bootsrapping)
      • Architecutre
      • TSCH overview
      • Security (PANA)
    • w1: 6top: sub-layer between 6LoWPAN and TSCH
    • w2: interaction 6top and an centralized computation entity (PCE) - PCEP and CoAP as options
    • w3: define a mechanism for nodes to reserve mac layer resources in a distributed manner.
    • w4: define 6TSCH minimal configuration. How to configure the network with static schedules.
    • w5: architecture - signaling and data flows, BR operation, Label Switching
    • w6: 6TSCH overview. Present missing pieces and motivation for 6top
    • w7: Security: define security req. Define mech. for nodes to secure resource resevation
  • [10:42] Non-Milestone items [Pascal]
    • Implementers guide
    • Coexistence guide: in a environment shared with other protocols.
    • applicability: how do we use the technology in other environments.
  • [10:43] External work [Pascal]
    • 6MAN: WiND, flow label for RPL
    • ROLL/6Lo - BBR, Fragment Forwarding, Node relocation, OF impacts
  • [10:46] Thomas: this is the end of the rehearsal
    • we are 12min too late
    • let's discuss ideas on how to remove later
  • [10:47] Security draft [Yoshihiro]
    • Background: Security on WirelessHART.
    • Purpose: indentify requirements:
      • provide scalable key management framework for 6TSCH
      • current document is a starting point
      • revise document based on group input.
    • Discussion
      • [Thomas] Integration of Security with CCM. How the nounce of CCM? What keys are used?
      • [Yoshihiro] CCM* will be used. How we integrate key management, is missing in 15.4e, A key management protocol is needed. First agree on the set of requirements, and on the problem.
      • Use of unsecure frames, session keys. etc. to discuss in the ML
      • Security profiles.
      • jamming, recommendation about protocols on 6top to cope with network attacks (DoS) etc.
  • [11:00] Remarks and recommendations about rehearsal
    • [Subir]
      • Pascal: Expand IT/OT acronym
      • What is missing_ architecture: initial slides seem to show that the missing block is architecutre but this is more than that
      • Non-work items can be added later. too many work items - maybe skip non-work items. Be very quick and reduce slide.
    • [Marc]
      • architecture is not good job by itself.
      • the details of each Work Item are never discussed in that BoF. Make sure that people can go to the mic and comment.
      • Too much time spent in Non-Milestone items.
    • [Subir]
      • make clear that this is a multi-hop network
      • make sure all acronyms are expanded on all slides, e.g. LL
    • Out of scope? Multicast? ND and deterministic? For sure we can expect some questions:
    • Terminology? main terms? 1 slides? -- no, avoid acronyms when we speak.
    • External Work to other WG:
      • go fast or skip
    • It is not clear exactly what is NOT in scope:
      • ND?
      • 6top on RPL?
  • [11:20] Meeting ends.

Updated