Subject: [6tsch] minutes IETF 86 Wednesday meeting

From: Thomas Watteyne <[email-masked]>
Date: Thu, 14 Mar 2013 20:12:29 -0700

All,

Thanks for Dominique and Xavi for taking notes at yesterday's 6TSCH
meeting. You'll find the at https://bitbucket.org/6tsch/ietf86-orlando/src.

For convenience, I also copy-pasted them below.

Thomas

---

Minutes 6TSCH Wednesday meeting
IETF 86 Orlando
03/13/2013 11.30-13.00 Boca 2

[slides available at https://bitbucket.org/6tsch/ietf86-orlando/src/]

Notes taken by:
- Dominique Barthel
- 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
https://bitbucket.org/6tsch/.
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:
http://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-applicability-00
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: http://tools.ietf.org/html/draft-palattella-6tsch-terminology-00
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: http://tools.ietf.org/html/draft-thubert-6tsch-architecture-00
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: http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01
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: http://tools.ietf.org/html/draft-wang-6tsch-6tus-00
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: http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-03
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.