Wiki
Clone wikimeetings / 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
- Room: xmpp:6tsch@jabber.ietf.org
- Logs: http://jabber.ietf.org/logs/6tsch/ (2013-07-30.html)
- Proxy: Guillaume Gaillard
Taking notes (using Etherpad)
- Xavi Vilajosana
- Dominique Barthel
- Pouria Zand
Present (alphabetically)
- Alejandro Lampropoulos
- Alfredo Grieco
- Daniel Popa
- Diego Dujovne
- Dominique Barthel
- Etienne Dublé
- Guillaume Gaillard
- Laurent Toutain
- Marc Blanchet
- Maria Rita Palattella
- Olivier Alphand
- Pascal Thubert
- Pouria Zand
- Rafael Martinez-Lopez
- Raghuram Sudhaakar
- Subir Das
- Thomas Watteyne
- Xavi Vilajosana
- 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
- published first April 2013
- [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..
- Open source
- 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..
- Who are the people on that work:
- [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
- Defining the 6top layer.
- [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?
- [Subir]
- [11:20] Meeting ends.
Updated