All,

You will find a draft of the minutes of the 6TiSCH WG meetig at IETF89
London at https://bitbucket.org/6tisch/meetings/wiki/140306a_ietf89_london.
For your convenience, I'm also copy-pasting them below.

Please reply (or unicast) any suggested changes by the webex on *Friday
3/21*, after which I will submit them to the IETF89 material manager.

Thomas

---

Minutes IETF 89 WG meeting, 06 March 2014, 6TiSCH WG

Note: timestamps in GMT.
Venue

   - Thursday, March 6, 2014, 1300-1500 GMT
   - Buckingham room, Hilton London Metropole, London, UK

Taking notes *(using Etherpad)*

   1. *Dominique Barthel*
   2. *Xavi Vilajoana*

Jabber

   - Room: xmpp:6tisch@jabber.ietf.org
   - Logs: http://jabber.ietf.org/logs/6tisch/
   - Jabber scribe: *Guillaume Gaillard*

Recordings

   - audio recording<http://www.ietf.org/audio/ietf89/ietf89-buckingham-20140306-1300-pm1.mp3>
[mp3,
   155MB]
   - Jabber logs <http://www.ietf.org/jabber/logs/6tisch/2014-03-06.html>

Material

   - Consolidated Slides:
   http://www.ietf.org/proceedings/89/slides/slides-89-6tisch-0.pdf

Agenda

See IETF89 6TiSCH Agenda
page<https://datatracker.ietf.org/meeting/89/agenda/6tisch/>

6TiSCH: IPv6 over the TSCH mode of IEEE 802.15.4eWG Meeting Agenda
Meeting        :   IETF 89 Thursday, March 6, 2014Time           :
1300-1500 GMT Thursday Afternoon Session I (120min)Location       :
Buckingham room, Hilton London Metropole, London, UKChairs         :
Pascal Thubert <pthubert@cisco.com>
                   Thomas Watteyne
<watteyne@eecs.berkeley.edu>Responsible AD :   Ted Lemon
<ted.lemon@nominum.com>URLs           :
http://tools.ietf.org/wg/6tisch/
                   https://datatracker.ietf.org/wg/6tisch/
                   https://www.ietf.org/mailman/listinfo/6tisch

https://bitbucket.org/6tisch=======================================================================
Intro and Status                            [10min]    (Chairs)

    Note-Well, Blue Sheets, Scribes, Agenda Bashing
    Quick Reminders:
    * 6TiSCH charter recap
    * 6TiSCH milestones recap
Overall Architecture and Context            [15min]

    * <draft-ietf-6tisch-terminology-01>               (Maria-Rita Palattella)
    * <draft-ietf-6tisch-architecture-01>              (Pascal Thubert)
Information and Data Models                 [20min]
    * <draft-wang-6tisch-6top-interface-02>            (Xavi Vilajosana)
    * <draft-wang-6tisch-6top-sublayer-00>             (Qin Wang)
Security                                    [20min]
    * Security discussions: summary and outlook        (Michael Richardson,
                                                        Michael Behringer)
Report on plugfest                          [30min]
    * overview and goals                               (Xavi Vilajosana)
    * presentation of outcome                          <plugfest participants>
Unchartered drafts if time permits          [20min]
    * <draft-dujovne-6tisch-on-the-fly-02>             (Diego Dujovne)
    * <draft-piro-6tisch-security-issues-01>           (Giuseppe Piro)
    * <draft-svshah-tsvwg-deterministic-forwarding-00> (Shitanshu Shah)
Any Other Business                          [5min]

Minutes

   - About 40 attendees
   - *[13:02]* Intro and Status *(Chairs)*
      - Note-Well, Blue Sheets, Scribes, Agenda Bashing
         - *Thomas* introduces the session, objectives, agenda

         No issues raised about agenda. Agenda approved.

         - 6TiSCH charter recap *(Pascal Thubert)*
         - Charter mostly to create an architecture to put together pieces
         created in various IETF groups and elsewhere.
         - Produce an information model for the management of a TSCH
         network.
         - Produce a "minimal 6TiSCH configration" with static TSCH
         schedule and RPL as the routing protocol.
      - 6TiSCH milestones recap
         - adopted 4 WG documents during IETF88 (Vancouver)
         - next steps is to adopt
            - 6top document
            - data model for CoAP
            - Next year have architecture draft and minimal draft as RFC
         - *[13:09]* Overall Architecture and Context
      - *[13:09]* <draft-ietf-6tisch-terminology-01> *(Maria-Rita
      Palattella)*
         - *Maria Rita* not in the room, *Pascal Thubert* standing in
         - definition of "chunk" added: a portion of the slotframe known
         globally. Will help future work with dynamic scheduling.
Basically grouping
         timeslots for the purpose of allocation.
         - CDU matrix: Channel Distribution Usage. Different from the node
         schedule.
      - *[13:12]* <draft-ietf-6tisch-architecture-01> *(Pascal Thubert)*
         - published version -01 recently
         - added text about chunk management. Partitioning of big matrix.
         Decided that only parents in RPL graph can allocate chunks,
then use slots
         from the chunk to talk to children. Leaf nodes only inherit slots from
         parents.
         - Related work at the IETF:
            - 6man: ARO option that needs to be propagated over the
            backbone. Flow label: currently IP flow encapsulated at
entering the RPL
            domain to be allowed to carry the Hop-by-Hop option. Could
be made simpler
            if 6man allows an exception for that.
            - 6lo: 6TiSCH is based on traditional 15.4 MAC with small
            payloads. Getting reports that fragment recovery is
needed, as anticipated.
            - transport area: Deterministic DSCP (presentation by *Shitanshu
            Shah* scheduled at end of session)
         - Related work at IEEE *(Pat Kinney)*
            - Vice-chair IEEE802.15, former chair of initial
            IEEE802.15.4-2003.
            - Many amendments to IEEE802.15.4, including since
            IEEE802.15.4e.
            - 6TiSCH interest group at IEEE formed in November 2013.
            - Goal is to help the development of 6TiSCH from the IEEE side.
            Propose amendments, etc, at IEEE to better support the
work at 6TiSCH.
            - Many things to be done together with IETF 6TiSCH WG. One
            first example is the management of Information Element
(IE) identifier
            space, for example for 6top-to-6top communication.
            - Create an study group in February 2014. *Pascal Thubert* is a
            member.
            - Combine new technologies aligned to industrial standards.
            - Interest on technologies such as 6TiSCH, RPL, CoAP, XMPP, MQTT
            - *[Carsten Bormann]* Please add 6LoWPAN to the related work.
            MQTT is not part of the IETF. New activity around
authorization, ACE.
            - *[Samita Chakrabarti]* Please add 6lo to the list of related
            work.
         - *Pascal* re-iterates that 6TiSCH will adopt work from other WGs
         such as 6lo.
         - *[Subir Das to Pat Kinney]* Anybody responsible for relationship
         between IEEE and ISA?
         - *[Pat Kinney]* Yes, I'm that person.
         - *[Pascal]* Next items to cover
            - 6LoWPAN and RPL have diverged over time
            - missing: redistribute 6LoWPAN ND into RPL. efficient-ND draft
            proposes to introduce TID. This would close the gap.
            - missing; redistributing RPL in ND: RPL root advertising DAO
            state as ARO.
            - shows how a leaf node registers through 6LR, 6LBR, 6BBR to
            the Internet.
            - Working on the flows to join RPL network with the classical
            network.
         - Started a design team for the security architecture, separate
         weekly phone calls.
      - *[13:31]* Information and Data Models *[Xavi Vilajosana and Qin
   Wang]*
      - *[Xavi]* There used to be a very large document (>100 pages). At
      last meeting, suggestions to create a data model. Created two
drafts out of
      it:
         - one interface draft
         - one sublayer draft
      - *[13:33]* <draft-wang-6tisch-6top-interface-02> *(Xavi Vilajosana)*
         - second version of the draft
         - shows representation of MIB.
         - both soft and hard cell types. Could not be added into 15.4e, so
         had to add it here.
         - new concept of chunk.
         - management command list. Compared to previous document, removed
         all security-related commands, and added commands to manage chunks.
      - *[13:37]* <draft-wang-6tisch-6top-sublayer-00> *(Qin Wang)*
         - shows content of draft:
            - 6TiSCH Operation Sublayer (6top) Overview
            - 6top Commands
            - 6top Communication Protocol
            - Statistics
            - Monitoring
         - Main change is flag for cells. "how to use" section went into
         the architecture draft.
         - Security commands are related 15.4e, removed from 6top.
         - Separated out flags for cells and link options.
         - Next steps:
            - broadcast cell flag on receive side.
            - Chunk support, a few 6top-6top communication issues.
         - Planned to get early reviews from the YANG people in August.
      - *[Pascal]* Call for adoption of interface draft through hums.

      outcome: good level of hums in favor for, no hums against.

      - *[Pascal]* Will confirm on the mailing list.
      - *[Qin]* Currently three parts in data model: 6top, 15.4 and 15.4e.
      The upper layer might need to access the 15.4 PIB or 15.4e PIB. Two
      possible approaches: put 15.4 and 15.4e PIBs merged into 6top, or keep it
      outside.
      - *[Pat Kinney]* 6top draft contains an interface called
      "delegation", which looks like a pass-through. Think that is a good
      approach. Would not encourage proxy for that interface, since we wouldn't
      gain anything.
      - *[Pascal Thubert]* Drawback is that we'll have to change 6top every
      time something changes below.
      - *[Pat Kinney]* Totally agree, stay away from those problems.
      - *[Kuor Hsin Chang]* Why separate 15.4 and 15.4e? They will
      eventually be all part of 15.4.
      - *[Pat Kinney]* revision IEEE802.15.4-2014 will include amendments,
      including IEEE802.15.4e.
   - *[13:53]* Security discussions: summary and outlook *(Michael
   Richardson, Michael Behringer)*
      - Quick dive into security. Will show a few options and invite for
      opinions.
      - Two requirements on authorization w.r.t. a mote joining
         - the mote need to know that it is joining the right network
         - the network need to know whether the mote is allowed to join
      - authorization for a PCE: authorized sessions. The PCE should be
      authorized to write the schedule to the mote.
      - 2 options exist:
         - Option 1: use same approach as ZigBeeIP. Using PANA running over
         UDP, and use EAP-TLS. Session between new mote and its
neighbor. Neighbor
         then relays it up to PANA Authorization Agent. EAP may get
put in radius
         packet. This is common approach in AAA space, except that we
have limited
         data/code space; it uses EAP-TLS, which is an adaptation for
TLS to run
         over unreliable networks. Did this with CoAP-DTLS. Major plus of this
         approach is that code is running with this approach. The
contents are not
         small, but the work is done.
         - Option 2: use same WirelessHART, or ISA100. Essentially YANG
         over CoAP protocol living right above IEEE802.15.4e. Joins a
network using
         well-known key. Communication back-and-forth between new node and
         authorization agent which reaches into new node and modifies
a number of
         objects related to security. Authorization agent handles key
management.
         Same GET/PUT requests used for the actuator. Quite common
that nodes on the
         network is super-user. We could do this with our protocols. A new mote
         starts off, joins with well-known L2 key (better than no
key), RPL DIS to
         look for parents, DIO back from parents, pick a parent, and
send in RPL DAO
         (suggests non-storing network since doesn't use any RAM and
more secure
         that storing). RPL layer L3 security mechanisms, so RPL
traffic is signed.
         You can sign that DAO which is unicast to the root. Somehow
certificate in
         the DAO. Root contacts the authentication server which
accepts the node. As
         part of the ACK, starts a DTLS-CoAP session. Throuhg
DTLS-CoAP session,
         send YANG-based network parameters. Question about security
commands in
         YANG models. Mote knows who the network is; network knows who
the mote is.
         PCE got a ticket (produced by ACE WG), which allows the PCE
to update the
         schedule
      - There is a document co-authored by Michael Behringer
      (draft-pritikin-bootstrapping-keyinfrastructure-00) which
indicates what is
      in the certificates that provided by the mote and network. Authorization
      for the network is often implicit. If explicit, there might be an ACL. If
      node is identified on the network, it implies it is the network
it intended
      to join. Uses 802.1AR, in which vendor states whether owns this
node; based
      upon the certificate trust, the node attaches to the correct network.
      - We now need to identify which security model we like. Add YANG
      resource if needed.
      - Discussion:
         - *[Bob Moskowitz]* which type of 802.1AR certificates are you
         using? We have to manage all the different PKIs from all the different
         vendors in the network. Suggest look into 1AR.
         - *[Michael Richardson]* Question for Michael Behringer. To the
         mote we can provide a single set of information I believe.
         - *[Subir Das]* Assumption is that vendor owns. Within the
         security group, we did discuss this aspect, and we really
want to discuss
         this.
         - *[Pat Kinney]* ISA and WHART use out-of-band provisioning, keys
         are in place when node joins the network.
         - *[Thomas Watteyne]*: extremeley important work, thank you
         Micahel, lets continue on the mailing list.
         - *[Michael Richardson]* We need to decide between option 1 and 2.
      - *[14:12]* Report on plugfest
      - overview and goals *(Xavi Vilajosana)*
         - review minimal 6TiSCH draft, participants pitch, interop/demos,
         discusssions.
         - several demonstrations and interoperation, some with "minimal
         6TiSCH", one demo from Cisco Sysems and Linea Technology/Dust Networks
         showing a full network involving motes and switches.
         - Invites participants to come present.
      - presentation of outcome
         - *Pere Tuset* (Open University Catalunya)
            - Introduces new OpenMote open hardware
            - Runs OpenWSN open-source implementation
            - Communicates with other types of nodes.
            - Can be used as traffic sniffer
            - see http://openmote.com/
         - *Oleg Hahm* (RIOT community)
            - RIOT is OS for IoT, open-source, available on GitHub
            - ported OpenWSN over RIOT. Ran on the IoT-Lab mote (see next
            presenter).
            - Showed communication between pure OpenWSN and OpenWSN over
            RIOT.
         - *Cedric Adjih* (INRIA)
            - shows IoT-Lab node (Cortex M3, Atmel 15.4 radio) running
            OpenWSN.
            - Are builing a large experiment platform that can be accessed
            remotely over the Internet.
            - New version (Future Internet of Things, FIT) will augment the
            older SensLab (http://senslab.info) platform.
            - In-door GPS signal replication for fine time distribution.
         - *Nicola Accettura* (Univ Bari)
            - Showed implementation of DeTAS distributed scheduling
            algorithm on OpenWSN (on TelosB motes).
            - Nodes express their bandwidth requirements up the collection
            tree, PCE distributes allocation back down.
         - *Thomas Watteyne* (Linear Tech/Dust Networks) and *Pascal
         Thubert* (Cisco Systems)
            - joint demo involving backbone router and SmartMesh IP network.
            - Federate meshes without renumbering nodes.
            - ND-proxying for motes, multicast filtered out to avoid
            draining batteries, backbone router transparent to the way the mesh
            operates.
         - *Tengfei Chang* (UC Berkeley)
            - Minimal 6TiSCH demo
         - Lessons learnt *(Xavi Vilajosana)*
         - Wireshark dissectors needed. Effort started but not final yet.
         - Discussion about minimal draft: that number of slots and
         slotframe are static. Make them configurable? We need
in-depth study to
         determine recommended values.
      - *Thomas* thanks *Xavi* and all participants for this effective and
      exciting event.
   - *[14:32]* Unchartered drafts
      - *[14:32]* <draft-dujovne-6tisch-on-the-fly-02> *(Diego Dujovne)*
         - Draft defines a plug-in module (called On-The-Fly, or OTF) for
         distributed and dynamic scheduling in a 6TiSCH network.
         - OTF module talks to 6top. Eventually may talk to same module in
         other node.
         - Various possible policies: reactive, predictive, and hybrid.
         Comparison table on advantages and drawbacks of each.
         - Default algorithm as a proposal (input from Prof. Pister)
         - missing parts:
            - Statistics for bundles
            - Define interface between OTF and 6top
         - **[Thomas] Is the 6top interface as specified today enough to
         support OTF?
         - *[Diego]* Yes.
         - *[Pascal]* This work does not mean that allocation can only be
         local. Future work may include other approaches.
      - *[14:44]* <draft-piro-6tisch-security-issues-01> *(Giuseppe Piro)*
         - Identify security considerations, key management protocol.
         - Next version of draft in a few weeks. Will use IEs to exchange
         data between nodes.
         - Feedback requested. Will work with Security Task Force.
         - *[Bob Moskowitz]* Key management protocol is subtle. Get with
         those who have the scars, get advice from experienced
developers on the
         field.
         - *[Subir Das]* Authors of different security draft maybe should
         meet together and define profiles and practical use cases
         - *[Subir Das]* What is the time frame where the security work
         should be defined?
         - *[Thomas Watteyne]* Security is everywhere. Not in the charter
         at this time but important to start right away.
         - *[Thomas Watteyne]* Would like to ask the security task force to
         read these drafts and see how we merge/proceed.
         - *[Subir Das]* Different aspects (bootstrapping, operation, ...)
         - *[Pascal Thubert]* When we submit the first architecture we need
         to have a view of what the security architecture will be.
         - *[Yoshihiro Ohba]* Is the plan to include security architecture
         in the main architecture document?
         - *[Pascal Thubert]* We can say what our vision is in the
         architecture draft, not the overall security architecture.
         - *[Bob Moskowitz]* Hard work, it take a long time.
         - *[Robert Cragie]* Agree with Yoshihiro.
         - *[Subir Das]* as a WG we should not submit the architecture
         draft without including the security vision. Need to really
think on that.
         Need to enforce that part.
         - *[Michael Richardson]* I had never idea of what a security
         architecture is. We need to know what the threads are, we new
the tools we
         have to protect against that threads, and we know the CCM
architecture. We
         need to identify the constraints of the systems we are
addressing. This
         needs to be stated.
         - *[Robert Cragie]* Generalize it first.
      - *[15:00]* <draft-svshah-tsvwg-deterministic-forwarding-00> *(Shitanshu
      Shah)*

      By lack of time, need to push this presentation to a later meeting.

      - *[15:01]* Any Other Business

   No other business raised.

   - *[15:02]* Meeting ends