Subject: [6tsch] minutes WebEx 22 March 2013

From: Thomas Watteyne <[email-masked]>
Date: Sat, 23 Mar 2013 00:53:06 -0700

All,

Please find the minutes of today's meeting below. Attached are the slides
presented.

*Note: I understand that some of us have missed the call today because of
the switch to summer time in the PST area. Apologies for not sending a
clear reminder yesterday, will do next week. As an early reminder: it will
be the same next week (3/29), i.e. call will be at 4pm CET. The week after
that (4/5), we will be back to normal (5pm CET), since the CET region will
have switched to summer time.*

Thomas

---

*** Timestamps in PDT ***

Present:
- Bogdan Pavkovic
- Maria Rita Palattella
- Pascal Thubert
- Qin Wang
- Raghuram Sudhaakar
- Thomas Watteyne
- Tina Tsou
- Tom Phinney
- Xavi Vilajosana

Webex recording (audio+slides,streaming):
-
https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=66940742&rKey=711b58d40cd574d9[54min]

Attached slides:
- 6tsch_use_cases_call03222013.pptx: slides shared during the call and
edited live by Pascal

Agenda:
- Summary overview Orlando meeting [10min]
    . overview two meetings
    . 4 drafts presented
    . TODOs:
        . 6tus draft, add ability for a PCE to set hard cells on one side
only (text already changed)
        . typos
        . match terminology draft
- Charter use cases [40min]
    . review the following list
        . Wireless Process Control (main source for us)
           . control loops (requires a global optimization of routes for
jitter and latency – thus computed by a PCE -, flow (over) provisioning,
duocast, with static multipath hard slot allocation.
           . control loop plan B (requires self-healing -thus distributed-
routing,)
           . supervisory flows (requires determinism up to the backbone
           . management (requires a separate topology – a RPL instance -
that does not break)
           . alerts (bursty, unexpected, dynamic slot allocation,
prioritization)
           . monitoring of lots of lesser importance stuff like corrosion
(requires low cost scalability – this distributed routing )
           . cranes that are mobile within a range (requires dynamicity on
the last hop(s) whre the mobility happens and may be deterministic up to
that point)
           . large plants (requires thousands of devices– thus a backbone –
within a subnet – to avoid renumbering)
           . non-production episodes (requires fast and autonomic behavior
– again distributed routing)
           . coexistence with legacy devices (requires a common management
above)
        - Smart cities/infrastructures
            .(road,street) traffic control (requires increase of bw as more
traffic in the road)
            .smart urban parking (requires redundancy of routes an
over-provision as RF degrades with cars on top of the sensors)
            . green zones. Monitor moisture in gardens, trigger watering.
            . city lights monitoring. Requires marge scale meshes
        - building automation.
           . requires redundancy as RF degrades when there are changes on
the environment, doors, moving metallic apparel, etc..)
           . can be long distance this many hops. Can use lower frequencies
to gain range.
        - vehicular automation.
           . We can save copper for most of the man to machine interfaces,
which translates in both lower price and lower gas consumption.
        - commercial automation.
          .  asset tracking operations on the move (again mobility, and
dynamics).
          .  monitoring e.g. temperature of freezers, intrusion sensors,
    . validate the list of derived problems to be solved
    . focus on what TSCH is good at: reliability, low-power consumption,
traffic engineering
- Open technical discussions [time permitting]
    . synchronization between BBRs
        . summarize and discuss proposal
    . slotframes, cells and priorities
        . summarize and discuss proposal
    . interaction between RPL and PCE
        . summarize current state of the discussion

Minutes:
- [08.05] Meeting starts
- [08.05] Overview IETF 86 Orlando
    . 2 6TSCH information meetings
        . Tuesday: administrative and general information.
            . Adoption of draft-ietf-roll-rpl-industrial-applicability-00
as starting point for 6TSCH requirements
            . Many non-6TSCH people discovered the group.
            . Positive feedback.
        . Wednesday: technical discussion,
            . 4 6TSCH drafts presented
            . 2 non-6TSCH drafts presented
    . all information, including full minutes and slides are at
https://bitbucket.org/6tsch/ietf86-orlando/
- [08.15] Discussion on charter use cases
    . Pascal shares slides from [6tsch_use_cases_call03222013.pptx]
    . Goal: discuss the different use cases scenarios
    <<< Below is only a list of the points discussed. Refer to the attached
slides for contents. >>>
    . Duocast
        . [Tom] duocast applies only to single hop.
        . [Pascal] Edits slide.
    . Supervisory flows
        . [Pascal] Do we want the flow to be deterministic to a supervisor
which sits in the backbone? This implies matching the LLN schedule to some
backbone link-layer schedule?
        . [Tom] BB has orders of magnitude more bandwidth than LLN. Will
never be constrained. We don't need to have determinism in the BB.
        . [Thomas] We could consider this isssue out-of-scope for 6TSCH.
        . [Pascal] Edits slide.
    . Management topology
        . [Pascal] do we want to separate the management traffic from data
traffic to ensure availability?
        . [All] Agreed/
        . [Pascal] Adds open issues: OF and root selection to slide.
    . Alerts
        . [Pascal] Proposal: allow for burst of traffic to generate some
on-demand ("on-the-fly") distributed reservation?
        . [Thomas] Potentially complicates things. Why not consider a burty
traffic as a problem for the scheduling entity to taken care of.
        . [Pascal] Edits slide.
    . Support for lesser important "background" traffic.
        . [Pascal] Allow for traffic to flow along RPL routes, using soft
cell allocation, possibly alongside PCE-allocated hard cells.
        . [Thomas] Agreed since probably relatively easy to do (hard cell
have priority over soft cells, if hard cell is installed at same
timeslot/channeloffset as soft cell, soft cell needs to move). Yet, this
might bring complexity, so let's separate PCE/distributed approaches.
    . Mobility
        . [Pascal] Presents idea from Alfredo, whereby data from a mobile
crane would travel over a RPL "half-track" before reaching PCE "half-track".
        . [Thomas] Not is favor of mixing distributed and centralized
routing in a track.
        . [Thomas,Tom] What we understood from Alfredo's proposal was to
have same cells scheduled at several potential neighbors of the node
mounted on the crane.
        . [Tom] Agreed.
        . [Pascal] Agreed.
        . [Pascal] Marks issue as "no goal".
        . [Tom] Mobility case makes sense, e.g. for large container cranes
traveling along a track. Two cranes can pick up each side of a large
object. One can imagine automated communication (now human operators with
radio).
        . [Tom] Second example is pivoting crane.
        . [Pascal] Splits mobile case if "crane" and "mobile" worker.
        . [Tom] Mobile worker does not require deterministic schedules.
    . Large plants
        . [Pascal] Concept of multiple BBRs interconnected by BB to allow
nodes from different LLNs to be in same IPv6 prefix. Useful?
        . [Raghuram] In some cases, we want to know exactly where a node
is, having the same prefix might remove that information.
        . [Thomas] System can be built so that a network operator can know
to which BBR a node is attached, yet all nodes still in same prefix.
        . [Pascal] Edits slide to indicate same prefix not always needed,
isolation somtimes wanted.
        . [Thomas] Wants to stress that we also want to support a case
where one big LLN with multiple BBRs.
        . [Pascal] Agreed, text encompasses this case.
    . Non-production phases
        . [Pascal] RPL can be needed as backup or for recovery.
        . [Thomas] Very well explained in
draft-ietf-roll-rpl-industrial-applicability-00. Agreed.
    . Coexistence
        . [Pascal] Do we need a common management entity which could know
about the different schedules of different LLNs (possible covering
IEEE802.15.4e TSCH, WHART and ISA1000) to facilitate coexistence?
        . [Thomas] Such fine-grained (at cell level) coexistance management
not needed. Several network in same radio space work fine. Coarse-grained
can be easily implemented. E.g. blacklisting some frequency on which a
single-channel network runs, and which does not support a different network.
    <<< Time's up, we don't go through additional slides >>>
- [09.00] What's next?
    . for the coming week:
        . finalize the list of use cases, with slideset as a base, on the ML
        . start working on extra items (per Marc Blanchet's suggestion):
            . what needs to be done in IETF
            . milestones and deliverables.
    . at next meeting: finalize discussion on use cases, and move on to two
points above.
- [09.05] Meeting ends