Clone wiki

meetings / 131105_ietf88_vancouver

Minutes IETF 88 WG meeting, 05 November 2013, 6TiSCH group

Note: timestamps in PST.


  • Tuesday 05 November, 1420-1550 PST
  • Georgia B room, Hyatt Regency, Vancouver, BC, Canada

Taking notes (using Etherpad)

  1. Xavi Vilajosana
  2. Dominique Barthel





See IETF88 6TiSCH Agenda page


  • [14:20] Meeting Starts
  • [14:20] Intro and Status
    • Introduction (Thomas Watteyne)
      • Jabber room available.
      • Etherpad with minutes.
      • Note well read.
      • Meeting is recorded.
      • Objectives of the meeting
        • first meeting of the WG
        • go through the drafts
        • 8 drafts published under 6TiSCH
        • discussion of reshuffling of content between various drafts
        • update general directions
        • election of WG documents
      • Agenda
        • Intro
        • Architecture
        • Informations Models
        • Minimal RPL support
        • Call for draft adoption
        • Unchartered drafts
    • <draft-palattella-6tisch-terminology-00> (Pascal Thubert)

      Presented version:

      • version is 00 but this draft has 3 revisions, it is 00 due to name change
      • added additional terminology
      • Avoid colliding definitions. It does not use 15.4e terminology.
      • Extends ROLL terminology
    • 6TiSCH charter recap (Pascal Thubert)
      • Scope of the WG is presented again for clarification.
      • goal after IETF87 BoF: reduce number of work items. Ended up with half of initial charter.
      • work item 1: limit the scope to RPL operation over static schedule. Not schedule management in that charter yet.
      • work item 2: information model containing the management requirements: Information model currently in English. Data Model in YANG. Turn into different representation of the data.
      • work item 3: specification of how we can run RPL on a static TSCH network. Need for management (see RPL industrial applicability statement), it is the base by which can control the network (like control plane).
  • Architecture
    • <draft-watteyne-6tisch-tsch-00> (Thomas Watteyne)

      Presented version:

      • update on the draft: minimal changes and minor rewording and typo correction. Gives an overview of TSCH and outlines what 6TiSCH should provide.
      • in TSCH management and monitoring is out of scope.
      • draft stable for at least 2month
    • [14:31] <draft-thubert-6tisch-architecture-01> (Pascal Thubert)

      Presented version:

      • follows the discussions on the ML, status of the work being done.
      • this is 4th revision, with 6tsch renamed to 6TiSCH, published as -01
      • reorganization,
      • updated interaction models
      • fragment forwarding supported (see 6lo) because of small frames
  • Information and Data Models
    • <draft-wang-6tisch-6top-00> (Xavi Vilajosana)

      Presented version:

      • draft defines interface offered on top of TSCH to upper layers
      • was presented in IETF87 Berlin. Changes:
        • updated terminology for consistency with terminology draft
        • made tables and text consistent
        • corrected typos.
      • shows full table of commands for control and monitoring
      • Example usage: centralized approach with a PCE (not in current charter scope) and distributed RPL routing (in current charter scope). Try to be as wide as possible not to restrict further work.
      • Example of communication between nodes at MAC layer (Information Elements in 15.4e TSCH frames). Need to discuss it further with 15.4e experts.
      • Content of this draft is wide, may warrant reshuffling between various drafts.
      • Need to distinguish description of interface (communication with upper layers) and internal operation of this layer. Also make explicit how 15.4e MLME commands are used as a result of 6top commands.
      • Further open questions : Delete cell ACK ? Hard cell removal ?
      • [Carsten Bormann] This draft seems to be a collection of verbs, describing what it does. Recommend to describe with nouns. Build data model. Much easier to understand.
      • [Thomas Watteyne] There is an agenda item which covers data model.
    • <draft-sudhaakar-6tisch-coap-00> (Pouria Zand)

      Presented version:

      • Subject of the work:
        • Data Model definition for CoAP
        • 6top on top of TSCH
        • Needs an Information Data Model to Interact Data Model
        • 6top offers the commands
        • Uses CoAP methods:
          • Mapping CoAP methods to 6top commands through URIs
        • Management Resources, R/W access
        • e.g. URI 6t/Neighbor can be use to manipulate the information of the neighbor table
        • Informational resources: Read accessibility
        • Message format:
          • GET: Content encoded using CBOR, URI query uses ABNF.
          • POST: payload encoded using CBOR.
          • DELETE: Uri-Query using ABNF.
        • Open Issues:
          • can ABNF be used?
        • Mapping of CoAP to 6top:
          • e.g. POST to URI /6t/neighbor calls Create.neighbor(address,stats)
        • [Emmanuel Baccelli] why using CoAP to manage the resources? How does this relate to the work being done at 6lo?
        • [Thomas Watteyne] We followed the 6lo discussion about SMIv2/SNMP and YANG/NETCONF closely. Ideas evolved in parallel in different groups. Will need further coordination.
        • [Don Sturek] Thomas, is 6top just an api to manage the MIB, or does it require some over-the-air protocol?
        • [Thomas Watteyne] API by now. Goals of 6TiSCH is to translate API to several over-the-air protocols.
        • [Carsten Bormann] 6top looks like an SNMP table.
        • [Mehmet Ersue] RESTCONF WG created a REST variant of NETCONF called RESTCONF. RESTCONF is a mechanism to manage MIB described in YANG. Please verify whether this draft is applicable.

          From Pieter De Mil on Jabber: RESTCONF draft at

        • [Don Sturek] Does 6top define some communication between neighbors? This is especially helpful to detect asymmetric links, by having neighbors exchange RSSI information about one another.
        • [Thomas Watteyne] The plan is to turn YANG model into a neighbor-to-neighbor communication protocol. This will allow neighbors to exchange RSSI information. This is not within charter now, so we need to clearly separate the API portion of 6top from the actual over-the-air protocol.
        • Presentation continuous with examples of operation.
        • Open Discussion: whether to define a generic data model using YANG.
        • [Michael Richardson] Any two nodes might do something like this it does not look like this in the presentations.
        • [Pouria Zand] Neighbor-to-neighbor communication is not part of this charter. It is for sure next step.
        • [Mehmet Ersue] RESTCONF provides features that are important for configuration management, such as transactions.
    • Coverage gap analysis vs. charter (Dominique Barthel)
      • Slide presents different building blocks on the current working documents.
      • The 6top draft is wide because it was created before the scope of the charter was narrowed down after IETF87.
      • discussion about how to organize the information ongoing
      • [Ted Lemon] Advice on whether to put the extra information. Put in a separated document and publish that whenever is the right time.
  • Minimal RPL support
    • <draft-vilajosana-6tisch-minimal-00> (Xavi Vilajosana)

      Presented version:

      • newly submitted draft, not presented at IETF meetings before.
      • Work item in charter to describe minimal mechanism for operation of distributed routing over static schedule.
      • Define a default (fall-back) mechanism.
      • 101 cells in slot frame, 16 channels for channel hopping, 5 well-known shared cells for communication (with contention), 3 MAC retransmission, 15ms cell duration (copes with slow hardware)
      • draft defines timing within slot.
      • draft defines content of Sync IE (Information Element) and Link IE.
      • draft defines Time Source neighbor selection: use RPL DAGrank as JoinPriority for advertisement, select neighbor with min JoinPriority as time source neighbor.
      • draft defines minimal content of neighbor table.
      • draft defines Objective Function used for RPL as OF0 with step_of_rank equals to 2 * ETX.
      • draft defines RPL non-storing as MUST, storing mode as MAY.
      • Open issues:
        • use of ASN vs timestamp
        • OF0 does not know 2*ETX
      • Content of this draft already implemented open source as part of UC Berkeley's OpenWSN project. Works.
      • [Pascal Thubert] Importance of choosing between ASN and timestamp. ASN is linked to one MAC schedule. Timestamp accommodates for multiple schedules in the same network.
  • Call for draft adoption [10min] (Chairs)
    • draft-palattella-6tisch-terminology
      • has been stable for a long time. Two new definitions in last version.
      • Anybody opposed to adopting as WG document?

        No hands raised.

      • Chairs will confirm on mailing list.
    • draft-watteyne-6tisch-tsch
      • very stable
      • Chairs feel this draft is ready for adoption
      • Anybody opposed to adopting as WG document?

        No hands raised.

      • Chairs will confirm on mailing list.
    • draft-thubert-6tisch-architecture
      • Not stable in content, but closely following discussion on the mailing list.
      • Anybody opposed to adopting as WG document?

        No hands raised.

      • Chairs will confirm on mailing list.
    • draft-vilajosana-6tisch-minimal
      • Chairs feel this draft is ready for WG adoption. There is an implementation.
      • Anybody opposed to adopting as WG document?

        No hands raised.

      • Chairs will confirm on mailing list.
    • draft-wang-6tisch-6top and draft-sudhaakar-6tisch-coap drafts were presented. Not ready yet, will propose reshuffling of content, then present again to WG for adoption.
  • Unchartered drafts if time permits [15min]
    • <draft-ohba-6tisch-security-00]> (Yoshihiro Ohba)

      Presented version:

      • Security is a key topic for us.
      • Objective is to provide a secure key management framework to dynamically update the CCM* keys
      • identify requirements for the Key Management Framework (KMF)
      • [Michael Richardson] What is the objective? management or framework?
      • [Yoshihiro Ohba] The draft is focused on the 6tisch framework. Management will go in a separate draft.
      • Framework is for 6tisch and other mesh network that requires key management.
      • 3 phases:
        • Bootstrap
        • Link establishment
        • Operational
      • draft focuses on point 1 and 2 requirements
      • 3 key modes:
        • mode 1 broadcast and unicast keys are the same
        • mode 2 broadcast and unicast are the same with bidirectional unicast keys
        • mode 3 broadcast and unicast are the same ...
      • Example sequence presented.
      • Requirements for KMP are listed for each phase.
      • Key distribution is started at the root and is distributed hop by hop.
    • Overview discussion on slot allocation principles (Pascal Thubert)
      • historically PCE is used, with central schedule
      • however, we aim for a capability to provide distributed schedule computation based on the use of RPL.
      • Problem:
        • timeSlot distributed allocation is complex:
          • scope of the next recharter.
          • how do we allocate a time slot?
            • centralized allocation
            • Fully distributed
            • parent based allocation taking advantage of the RPL draft
        • Variable Bit Rate (VBR) traffic yields poor use of reserved resources
          • VBR requires better ways to deal with scheduling
          • Statistical multiplexing
          • Best effort QoS
        • allocate dynamically (using OTF) to cope with traffic bursts.
        • having a "more bit" indicating that we will need next time slot.
      • [Don Sturek] Do you take into account the regulations (like ETSI restrictions on percentage of channel usage) when scheduling?
      • [Pascal Thubert] Thanks for the comment, this is well explained in the ISA100.11a we will take it account ETSI recommendations.
    • <draft-piro-6tisch-security-issues-00>


  • [15:48] AOB

    No other business is raised.

  • [15:50] Meeting ends.