Minutes Webex 10 May 2013, 6TSCH group

Note: timestamps in PDT.

Taking notes

1. Xavi Vilajosana
2. Thomas Watteyne

Present (alphabetically)

1. Thomas Watteyne
2. Pascal Thubert
3. Adrian Farrel
4. Alfredo Grieco
5. Dominique Barthel
6. Maria Rita Palattella
7. Pouria Zand
8. Raghuram Sudhaakar
9. Tina Tsou
10. Tom Phinney
11. Xavi Vilajosana

Recording

• This webex was not recorded.

Slides

• slides_130510_webex.ppt: slides shared during the call

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.