1. 6tisch Avatar 6tisch
  2. admin
  3. meetings

Wiki

Clone wiki

meetings / 131220_webex

View History

Minutes Webex 20 December 2013, 6TiSCH WG

Note: timestamps in PST.

Taking notes (using Etherpad)

  1. Xavi Vilajosana
  2. Pascal Thubert
  3. Thomas Watteyne

Present (alphabetically)

  1. Alaeddine Weslati
  2. Cedric Adjih
  3. Diego Dujovne
  4. Giuseppe Piro
  5. Nicola Accettura
  6. Pascal Thubert
  7. Pat Kinney
  8. Pouria Zand
  9. Qin Wang
  10. Raghuram Sudhaakar
  11. Sedat Gormus
  12. Thomas Watteyne
  13. Tina Tsou
  14. Xavi Vilajosana

Recording

Slides

Action Items

  • Thomas to send an email to the ML during the 2 next weeks to make clear that there is no meeting.
  • Pascal take "schedule" vs "slotframe" discussion to ML.
  • Pascal to detail use of chunks in architecture draft

Agenda

  • Administrivia [2min]
    • Approval agenda
    • Approval minutes last call
  • Definitions [15min]
    • cell
    • unscheduled cell
    • scheduled cell
    • to schedule a cell
    • broadcast cell
    • hard cell
    • soft cell
    • to reallocate a cell
    • chunk
    • chunk ownership delegation
    • chunk ownership appropriation
  • quick status update WIP drafts [5min]
    • draft-dujovne-6tisch-on-the-fly
    • draft-wang-6tisch-6top-interface
  • draft-piro-6tisch-security-issues-01.txt [10min]
  • AOB [1min]

Minutes

  • [08.05] Meeting starts
    • Pascal starts recording
    • [Thomas] This is the last call of the year. NO call in the next 2 weeks (12/27 and 01/03).
  • Administrivia [2min]
    • Approval agenda

      No issues raised. Agenda approved.

    • Approval minutes last call

      No issues raised. minutes approved.

    • Last call of the year. No more calls during next two weeks.

      Action item: Thomas to send an email to the ML during the 2 next weeks to make clear that there is no meeting.

    • Maria Rita travelling, progressing terminology draft on her behalf.
    • list of terms to talk about are presented.
    • Guissepe will update us about the status of the security draft that was submitted earlier before IETF88 meeting in Vancouver
  • Definitions [15min]
    • cell

      A single element in the TSCH schedule, identified by a slotOffset, a channelOffset, a slotframeHandle. A cell can be scheduled or unscheduled.

      • updated to make it shorter and clearer.
      • [Pascal] The "schedule" is an abstraction owned by 6top. Should we replace "schedule" by "slotframe"? We refer to the matrix of cells.

        Action item: Pascal take "schedule" vs "slotframe" discussion to ML.

    • unscheduled cell

      A cell which is not used by the IEEE802.15.4e TSCH implementation.

      • [Pascal] Term "cell" is used for an entry in the matrix and at some point is used to identify the unit of transmission.
      • [Pascal] Unit of transmission, we should agree either we use this abuse of notation or not.
    • scheduled cell

      A cell which is assigned a neighbor MAC address (possible the broadcast address), and one or more of the following flags: TX, RX, shared, timeskeeping. A scheduled cell can be used by the IEEE802.15.4e TSCH implementation to communicate. A scheduled cell can be a hard cell or a soft cell.

      • removed"hard" flag as this is part of 6top and not part of the cell. What is hard or soft is the unit of transmission, not the cell itself.
      • Unit of transmission seems a good candidate to describe the use of a cell and separate from cell (container). The term "unit of transmission" can be changed in a future.
    • to schedule a cell

      The action of turning an unscheduled cell into a scheduled cell.

    • broadcast cell

      a scheduled cell with neighbor MAC address the broadcast address.

    • hard cell

      A scheduled cell which the 6top sublayer cannot reallocate.

    • soft cell

      A scheduled cell which the 6top sublayer can reallocate.

    • to reallocate a cell

      the action by the 6top sublayer of changing the slotOffset and/or channelOffset of a soft cell.

      • [Thomas] is relocate (as now it is unit of transmission)?
    • chunk:

      a well-known list of non-contiguous (i.e., well-distributed in time and frequency) cells within a slotframe; a chunk represents a portion of a slotframe that can be managed separately by an individual node. Chunks can be pre-programmed, or can be computed by the PCE when the network bootstraps.

      • [Thomas] Non-contiguous seem not correct. They can be contiguous. So recommends removing from definition.
      • [Thomas] State also that the way chunks are allocated is out of the scope.
      • [Thomas] Missing the concept of identifier of the chunk.
      • [Pascal] Remove the last sentence and reword so that the meaning of the sentence indicates that the chunk is global and known by everyone.
      • [Diego] Do we allow overlap of different chunks?
      • [Pascal] Yes.
      • [Qin] How do nodes that own different chunks communicate?
      • [Pascal] A node can have multiple chunks. And can use them according to a policy. Important to know if chunks are overlapping or not.

        Action item: Pascal to detail use of chunks in architecture draft

    • chunk ownership delegation

      The process by which an individual node obtains a chunk to manage based on point-to-point interaction with a PCE.

      • [Thomas] Not use the PCE as an example, generalize to external entity.
    • chunk ownership appropriation:

      The process by which an individual node obtains a chunk to manage based on peer-to-peer interaction with its neighbors

      • [Thomas] we need to skip detailing in the description specific methods (e.g PCE)
      • [Pascal] delegation multiple hops away a cell is allocated, appropriation is one hop, no owner but by means of negotiation
      • [Qin] it seems very similar to 6top negotiation.
      • [Pascal] unit of tx between A and B and 6top in A negotiates with 6top in B (schedule time frame).
      • [Pascal] A chunk delegation or appropriation is a boot-time thing (or a ramp-up thing). The idea is to allocate some chunks (set of cells) to be used to allocate particular units of transmission.
      • [Thomas] the mechanism itself (only mechanism) seems very close to 6top negotiation mechanism.
      • [Qin] 6top-to-6top should support ownership appropriation?
      • [Thomas] the 6top interface should have the methods to manipulate chunks as it has now methods to manipulate soft cells.
      • [Qin] we need to define some specific mechanism to support that and this is almost identical to soft cell negotiation.
      • [Pascal] the difference is that the chunk negotiation is broadcast, one node to all neighbors to indicate the presence of a chunk
  • [08:51] Quick status update WIP drafts [5min]
    • draft-dujovne-6tisch-on-the-fly
      • Diego speaks about 10 issues logged in issue tracker
      • other issues not update in the slide.
      • https://bitbucket.org/6tisch/draft-dujovne-6tisch-on-the-fly/issues?status=new&status=open has the issues tracked in bitbucket since this is a personal submission.
      • Thomas suggest to group issues a bit more to limit the overhead
      • [Diego] Should be CC ML on all issue updates?
      • [Thomas] Maybe. Thoughts?
      • [Pascal] better to not have issue notification to the ML for non-working group documents.
    • draft-wang-6tisch-6top-interface
      • [Qin] we need to define the MIB tables defining the content of the 6top layer. This is an intermediate step to achieve a useful yang model. The real format is not important for that tables as they will not appear in the draft.
  • draft-piro-6tisch-security-issues-01.txt [10min]
    • new version submitted.
    • the new document takes the feedback received from the ML into account.
    • use 6top layer to build the secure context. 6top and MAC interact using the commands defined in 6top draft.
    • [Thomas] Call for reviewers for this security drafts.

      Action item: Thomas to call for reviewers of draft-piro-6tisch-security-issues-01.txt on ML.

  • draft-richardson-6tisch-security-architecture-00
    • Michael Richardson submitted a new draft on security, the draft will evolve as discussions evolve.
    • goal is not a solution draft but a high level architecture. *9:07 AOB [1min]
    • next meeting will be the 10th of January.
    • happy holidays!
  • [09.10] Meeting ends

Updated