Clone wiki

meetings / 130313_ietf86_orlando

Minutes IETF 86 Orlando meeting 13 March 2013, 6TSCH group


Boca 2, 11.30-13.00


Taking notes

  1. Dominique Barthel
  2. Xavi Vilajosana


(15 people in the room)

=== Introduction ===

[Thomas] Today is technical discussion. 6TSCH is not a WG, so no IETF home page, instead repositories at Agenda: presentationsof 6 drafts, followed by discussion on 4 on-going topics.

=== draft-ietf-roll-rpl-industrial-applicability-00 ===

Draft Title: RPL Applicability in Industrial Networks URL: Presented by: Pascal Thubert

Draft written for the ROLL working group, used as starting point requirements for 6TSCH. Same slides as presented at ROLL WG meeting. We need a common draft to collect the goals. This can be in RPL industrial context. In 6TSCH, mixing paths computed on PCE and paths computed in a distributed fashion by RPL. Not in this draft. Today there is no definition yet of how to achieve deterministic tracks that go beyond the wireless to the backbone. Need another draft to explain how WirelessHART, ISA100.11a and 6TSCH networks can co-exist.

Q: are we mixing RPL storing and non-storing modes? A [Pascal]: No, 6TSCH will not be changing RPL.

=== draft-palattella-6tsch-terminology-00 ===

Draft Title: Terminology in IPv6 over Time Slotted Channel Hopping URL: Presented by: Thomas Watteyne

Draft was published yesterday. Goal is to capture terminology, clarify name conflicts between IEEE and IETF. Some terms from 15.4e were colliding with IETF terms, e.g. link and path. Next step is to capture new terms as they appear on the mailing list and in the drafts.

[Pascal]: includes by reference terminology drafts by other groups (ROLL, autoconf)

=== draft-thubert-6tsch-architecture-00 ===

Draft Title: An Architecture for IPv6 over Time Synchronized Channel Hopping URL: Presented by: Pascal Thubert

Draft was supposed to be written at ROLL but never was. Goal: How to put together RPL/PANA/6LoWPAN/ E.g. tuning to use RPL, how we do DAD. -00 published yesterday. Scope of work is in the (current) draft. The draft will progress as the group progresses. Inside is the LLN, functionality of the BBR that connects the LLN and the BB. Exchange between the wireless world and the PCE. Needs help from PANA experts.

Q [Pascal]: we need help for the PANA section. Yoshihiro Ohba offered to help with that. A [Yoshihiro Ohba]: yes.

Will have to decide which protocol to use to reserve bandwith along multi-hop paths, candidates are RSVP, NSIS. Items on the "to discuss" list are the ones on the agenda for the second part of this meeting.

=== draft-watteyne-6tsch-tsch-lln-context-01 ===

Draft Title: Using IEEE802.15.4e TSCH in an LLN context: Overview, Problem Statement and Goals URL: Presented by: Thomas Watteyne

Overview, problem statement and goals. version -01 draft. This draft states what TSCH does not do, hence what 6TSCH should provide as a complement. Appendix A contains highlights of TSCH, appendix B contains further comments that are not explicit in the TSCH standard. ToC and 2 appendix that deal with TSCH protocol highlights. Section 3 presents the problems. Thomas delivers a 5min tutorial on TSCH. 15.4e is a MAC-only amendement, that runs in 15.4 radios. Enables deterministic communications. Typically 10ms cell. Channel hopping mitigates multipath. Inside the schedule all cells are empty and can be allocated. Building the schedule is the challenge. It enables a clear trade-off between BW, Latency, redundancy vs energy-consumption. The more cell scheduled, the more energy consumption. Duty cycle is <1% if you don't have a very full schedule. Each cell does 1 out of 4 possible things: Sleep, transmit, receive, same with no ACK The IEEE802.15.4e TSCH standard describes the mechanics to execute a schedule, not how one builds a schedule. The draft describes nine problems to be solved. Thomas talks us through four of them. Network formation. How to send EBs? Network maintenance: how to select time source neighbors? Resource management: how to deal with links/cells, how to schedule cells? how to match the number of links to bandwidth. Dataflow control: a queueing policy. how to deal with the policies of packets and flows. Next: align terminology with "terminology" draft, include goals.

Q (JeongGil Ko, ETRI, Korea): Looks like we want to do something like RSVP for TSCH. How protocol-specific are we? Fine-tuning for RPL? Providing general consideration on various possibilities? A [Thomas]: we want to be generic but we want to cover all the possible scenarios. A [Pascal]: we assume we use RPL. We'll decide if we use RSVP or something else. We'll explain how we use these.

Q [Carsten]: what does multi-hop mean? within a 6LoWPAN or though various heterogeneous links. A [Pascal]: multi-hop within 6LoWPAN. But also verify behavior (determinism) across several networks, see presentation on 802.1Q on Tuesday.

Q [Carsten]: more than setting DSCP? A [Pascal]: yes. RSVP at layer 3. Not through the general Internet, only through controlled backbone.

Q [Carsten]: what about patents in this landscape? Open implementation ever? A [Pascal]: same techniques already deployed in ISA100.11a and WirelessHART. Purpose is to do same but using open standards. Regarding patents, we know those advertized by WirelessHART. C [Carsten]: would be great if people did their IPR declaration. Third-party or Dust themsleves. A [Thomas]: open-source implementation exists.

Q [Mehdi Mani (ITRON, France)]: opinion on 6LoWPAN and RPL? What is missing for TSCH networks? A [Pascal]: 6LOWPAN HC is being used in TSCH networks. Regarding RPL, question is if we need to define new OF, what bandwith info do we need to provide OF with.

Q [Medhi]: I am afraid of adding too much layers that can introduce inter-operability problems. A [Pascal]: better understanding of various functions, clear layer is key for viability. A [Thomas]: The work can be done at l2 but by separating it into a new layer (mac management layer) gives a more cleaner structure.

Q [Mehdi]: experience is extra layer is also burden to apply to new technology. A [JeongGil]: clear definition of interfaces is key in this work.

Q [Matthias Kovatsch]: are we limited to IEEE802.15.4e TSCH? Could this work be extended to e.g. ContikiMAC? A [Pascal,Thomas]: The primary focus of the group is IEEE802.15.4e TSCH. This is an existing standard, and coming up with the glue to make it fit under 6LoWPAN is relatively simple. Opening up to other MAC approaches makes the work less well-defined. Feel free to keep an eye on what is being proposed and make sure that it could be applicable to other MACs.

=== draft-wang-6tsch-6tus-00 ===

Draft Title: 6tus Adaptation Layer Specification URL: Presented by: Xavi Vilajosana

This draft describes interfaces to upper layers, discusses how to interact with RPL or GMPLS. Long draft, this presentation meant to help reading and understanding the draft. Draft should answer the problems described by Thomas. Hard link is imposed by PCE, cannot be moved by 6tus. Soft link is a bandwith requirement by upper layer, managed by 6tus. This work doesn't say how this is managed, only defines the interfaces. Using 6tus with PCE: could use RSVP, IS-IS In distributed approach: upper layer requests bandwidth at each node, 6tus instance in the node negociates with neighbor. CoAP is an option as a distribution protocol, or RSVP or IS-IS.

C [Pascal]: open right now, but we want to have it defined as part of this work.

In a distributed approach, nodes don't have a global view. May have hidden terminal problem. The 6tus monitoring process observes whether link is not up to the required performance, and re-negociates with neighbor to move it in the TSHC schedule. Some 6tus "objective function" has to be defined. Simple (default) behavior: could be to start with one link with each neighbor.

C [Thomas]: don't be scared by our mentioning RSVP. We're talking only inside the LLN. It's the concept of RSVP.

Xavi walks us through the current list of commands to the 6tus layer. 6tus uses packets to exchange control information between nodes. Makes use of 3 new Information Elements in 15.4e EBs.

C [Thomas]: Communication between PCE and node? CoAP? other existing protocol? Ask PCE group. C [Pascal]: We could look at PCEP.

=== draft-thubert-6lowpan-backbone-router-03 ===

Draft Title: 6LoWPAN Backbone Router URL: Presented by: Pascal Thubert

We don't want to renumber when node moves from DODAG to the next. Single subnet. Pascal explains multiple roles of 6LBR. Walks through node registration into the 6LoWPAN network. Needs to differentiate two cases: real duplicate address (keep the oldest one, reject the new one); node movement in the graph (accept the new one, remove the old one). Differentiate cases based on device OUID (unique ID). In summary: single IPv6 subnet (single prefix), capability for a node to move between routers while keeping same IPv6 address, BBR server as proxy ND.

Thomas closes the meeting.

Discussions items planned for this meeting will be discussed during the phone meetings and on the mailing list.