Subject: [6tsch] minutes WebEx 10 May 2013

From: Thomas Watteyne <[email-masked]>
Date: Tue, 14 May 2013 19:36:34 -0700

All,

You will find the minutes of the last webex below, and the presented slides
at https://bitbucket.org/6tsch/meetings/.

Thanks to Xavi for taking notes!

Please fix anything I might have missed directly in the e-mail and reply.

Thomas

---

# Minutes Webex 10 May 2013, 6TSCH group #

Note: timestamps in PDT.

Taking notes
------------

1. Xavi Vilajosana
2. Thomas Watteyne

Present _(alphabetically)_
--------------------------

* Thomas Watteyne
* Pascal Thubert
* Adrian Farrel
* Alfredo Grieco
* Dominique Barthel
* Maria Rita Palattella
* Pouria Zand
* Raghuram Sudhaakar
* Tina Tsou
* Tom Phinney
* Xavi Vilajosana

Recording
---------

* This webex was not recorded.

Slides
------

* Available at https://bitbucket.org/6tsch/meetings/src.

Agenda
------

* Update on the BoF in Berlin [10min]
* PCE integration [25min]
* CoAP for PCE integration [15min]
* AOB [5min]

Minutes
-------

* [08.05] Meeting starts
* [08.05] Update on the BoF in Berlin [Pascal]
    * We asked ADs for support, to both Ted Lemon (INT) Adrian Farrel
(RTG). We have two ADs, not sure who will be in charge of the group in the
end. We have help from both.
    * We also have received lots of help from Marc Blanchet (IAB). Long
talks during IETF in Orlando.
    * We have to fill a document to officially request a BoF. We are
completing this. Will be sharing it next time.
    * We are making great progress. Big topic for next call: agenda for BoF
discussion.
    * Requesting 2.5h:
        * 0.5h on TSCH
        * 1h on work items
        * 1h for charter discussion. Agreement from the room that we can,
    * BoF will be called "6TSCH"
    * Not clear when the BoF will be.
    * [Thomas] People are asking exactly which day the BoF would be.
    * [Adrian] Exact date is not predictable. One thing you can do is make
a request for a particular day or time in the week. Can only be a request,
sometimes it works.
    * [Pascal] This is what we did for pre-bof: same day/room as ROLL.
    * [Adrian] Historically 2.5h sessions are on Monday and Tuesday
morning. The goal is not to schedule 2 BoFs at the same time.
    * [Pascal] Next week we will discuss these questions.
    * No questions from the room, moving on.
* [08.15] Requirements for PCE protocol [Thomas]
    * _Thomas presents slides_
    * Requirement 1: carry metric information from the nodes to the PCE
        * [Dominique] Impact of delay due to delay between two slots.
Raised at IETF85.
            * If PCE allocates all cells by itself, than it will know the
latency. Hard cells only.
            * If soft cells, then node locally has right to schedule cells.
We need a new metric that we don't have now. link delay metric has min max
average.
            * Time elapsed within a node can be varrying.
        * [Pascal]
            * we need to add time
            * multiple slotframes
            * --> discussion on ML
        * [Thomas] hard cell vs soft cell, hard cell higher priority than
soft cell, the PCE knows what hard cells are shceduled. If we have hard and
soft cells, then the PCE cannot know exactly where the soft cells are. If
there is a scheduling collision, 6tus moves the soft cell.
    * Requirement 2: commands from the PCE to the Motes.
        * contact the mote and change its TSCH schedule
        * cam match 6tus commands.
        * installation of labels: PCE needs to install the label (mapping
of in/out slots)
        * track installation, the PCE talks to every node in the track.
    * Requirement 3: Carrying scheduling requirements from the node to the
PCE
        * PCEP: PCEReq, PCEResp
        * RFC6551: can set the constraint bit in the header, how this is
related to PCEP? Is there is a way to request schedule change?
        * [Dominiqe] RPL DAOs flow to the root, constraint is used to
detect some exceeded configuration or restriction.
        * [Thomas] We need to be able carry requests, the application on
the mote will format a requirement ("please make sure I can have this").
Can this requirement be embedded in a constraint type metric as defined by
RFC6551?
        * [Dominique]
           * constraints in RFC6551 is used only to prune exploration
through RFC6551
           * very different with a centralized PCE.
    * Requirement 4: carry alarms from any node to the PCE
        * Also related to OAM. Connectivity verification, verify the BW is
still there, using all hard cells this info is in the PCE.
        * Continuity checking, make sure that the other side is still
there. A mote sent KA to a neighbor, can use the absense of the KA to
determine that a node has died.
        * [Maria Rita] Define how the PCE takes the proper action, there is
an alarm from a node, this implies some change on the schedule. Need to
define how the PCE makes actions to the schedule.
        * [Thomas] How we deal with the schedule is changed and only
effects a couple of nodes: send the command to both of these nodes, the
alarm of a node can trigger multiple changes.
        * [Maria Rita] avoid that the schedule is resent to all the nodes,
only to those that trigger the alarm.
    * Requirement 5: mutual authentication
    * Requirement 6: confidentiality
        * Not to be able to look at the data in the track except for the
src and dst.
    * Discussion
        * [Pascal] we need to write the requirement draft. Once we have the
story straight about the requirements, we can work on solutions drafts.
Might happen in 6tus or in PCE. We are not ready to work on this part. We
haven't identified the exact problems.
        * Let's do the requirements draft.
        * Not to be too greedy on this aspect in the charter.
* [09.53] CoAP for PCE integration [Xavi]
    * _Xavi presents slides_
    * We can use CoAP as a way of transporting data to and from the PCE.
    * The CoAP payload can consist of header borrowed from the different
protocols we talked about, such as PCEP of RFC6551.
    * The location of the CPE can be arbitrary. The root of the network
might act as a relay, also possibly take care of identifying the location
of the PCE.
    * CoAP can be useful since does HTTP-to-CoAP mapping
    * [Pascal] It looks like using CoAP like this makes sense.
    * [Thomas]
        * Context is that OpenWSN people are waiting for a solution to
communicate betwee the PCE and the motes.
        * We are early to start working on final solutions.
        * Does the group see any big problems with this approach.
        * Group agrees makes sense.
    * [Xavi] Will start working on a draft explaining this.
* [10.05] Meeting ends.