Re: [6tisch] Minutes, 22 January 2016 interim, 6TiSCH WG

"Pascal Thubert (pthubert)" <> Tue, 26 January 2016 18:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AED051B2B3D for <>; Tue, 26 Jan 2016 10:29:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IJDSABAis7xY for <>; Tue, 26 Jan 2016 10:29:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38DB91B2B41 for <>; Tue, 26 Jan 2016 10:29:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=100274; q=dns/txt; s=iport; t=1453832980; x=1455042580; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=BikZjww+rky+hSsq93wbMw1rsgLD1oljFkxBtB4mYLc=; b=Av3VB5ZxXPRlSXuLVnKwsGvjG0QbxcaTIqByodtXr9ytXP5tr7nbG0aT 45gDqQ1WhKaggsHZjsj6ukFcRc+w0GKh+dnN4xu2MHo+2GqfU4LxNwEsJ qnmekPmVefxcsRQZX5NDbx37m5UHXjY+8tzXaYLWa9xLI5iHNgFQIcgIg c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.22,351,1449532800"; d="scan'208,217";a="231792708"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jan 2016 18:29:38 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u0QITc3a029639 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jan 2016 18:29:38 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Jan 2016 12:29:37 -0600
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Tue, 26 Jan 2016 12:29:37 -0600
From: "Pascal Thubert (pthubert)" <>
To: Pat Kinney <>, "" <>
Thread-Topic: [6tisch] Minutes, 22 January 2016 interim, 6TiSCH WG
Thread-Index: AdFVNnd0TYdMQnEdSo66T8/92QdqowDYuquAAAyHJPA=
Date: Tue, 26 Jan 2016 18:29:15 +0000
Deferred-Delivery: Tue, 26 Jan 2016 18:29:04 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_c53f1df13eba479983cb1513c4a908d5XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [6tisch] Minutes, 22 January 2016 interim, 6TiSCH WG
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jan 2016 18:29:44 -0000

Thanks a lot Pat!


From: Pat Kinney []
Sent: mardi 26 janvier 2016 19:27
Cc: Pascal Thubert (pthubert) <>
Subject: Re: [6tisch] Minutes, 22 January 2016 interim, 6TiSCH WG


Sorry I missed the call due to being at the IEEE 802 session last week.

I would like to inform you that the IEEE 802.15 work group (WG) has approved the IEEE 802.15.12 Upper Layer Interface (ULI) Project Authorization Request (PAR).  The next step is for the IEEE 802 WGs review the PAR and suggest corrective language.  Should they approve it, it will then go to the IEEE New Standards Committee (NesCom) for final approval before it becomes a fully approved project.  You can download the PAR document: 15-15-0760-06 (  I have included the Scope of the PAR below for your convenience:

802.15.12 Scope: This standard defines an Upper Layer Interface (ULI) sublayer in Layer 2 (L2), between Layer 3 (L3) and the IEEE 802.15.4 Media Access Control (MAC) sublayer.  The ULI provides interfaces for data, control, and management information.  The ULI adapts L3 protocols and provides operational configuration including network and regulation requirements of the IEEE 802.15.4 MAC.  Furthermore, the ULI integrates upper Layer 2 sub-layer (L2+) functionalities focused on interfacing to IEEE Std 802.15.4 such as Key Management Protocols (KMP), L2 routing (L2R) protocols, and Internet Engineering Task Force (IETF) 6TiSCH Operation Protocol (6TOP) for optional use.  Finally, the ULI provides protocol differentiation, using mechanisms such as EtherType, to support multiple, diverse higher layer protocols.

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, SC chair
ISA100 co-chair, ISA100.20 chair
O: +1.847.960.3715<>

On 22, Jan2016, at 11:04, Pascal Thubert (pthubert) <<>> wrote:

 Connection details

  *   Date: 7-8AM Pacific:,12,5392171,1850147&h=100&date=2016-01-22&sln=15-16
  *   Webex recording:
  *   Wiki:<>
  *   Meeting slides:
  *   Etherpad Link:

Taking notes (using Etherpad)

  1.  Thomas Watteyne
  2.  Pascal Thubert
  3.  Diego Dujovne
  4.  Keoma Brun-Laguna
  5.  Michael Richardson
  6.  Xavi Vilajosana
  7.  Simon Duquennoy

Present (alphabetically)

  1.  Thomas Watteyne
  2.  Pascal Thubert
  3.  C-Y Lee
  4.  Diego Dujovne
  5.  Jonathan Munoz
  6.  Keoma Brun
  7.  Michael Richardson
  8.  Pascal Thubert
  9.  Patrick Wetterwald
  10. Qin Wang
  11. S.V.R. Anand
  12. Sedat Gormus
  13. Shahid Raza
  14. Simon Duquennoy
  15. Simon Duquennoy
  16. Sven Akkermans
  17. Tengfei Chang
  18. Xavi Vilajosana
  19. Zhuo Chen

Action Items

  1.  QIN: will start a discussion on the ML on what we do on information and yang data model


  *   Administrivia [2min]

     *   Approval agenda
     *   Approval minutes last call
     *   rechartering news

  *   6LoRH [20min]

     *   draft(s) status
     *   ML issues, proposed formats

  *   6top-sublayer [10min]

     *   ML Discussion on recommended formats

  *   Minimal Draft [15min]

     *   impacts on main text from intro changes
     *   Suresh's issues
     *   Next steps

  *   PlugTest [10min]

     *   Walk-through (delta) tests
     *   related question about the 6lorh and 6top

  *   AOB [1min]

•        [07.04] Meeting starts
•        [07.07] Administrivia [2min]
•        Approval agenda

     *   no issues raised, agenda approved
     *   Approval minutes last call
     *   no issues raised, minutes approved
o   rechartering news

        *   mcr was asked opinion by IESG about 6tisch recharter, wrt ROLL and mcr confirmed it was good.
        *   Xavi: we need some information about the layer
        *   Pascal: let's not confuse terms
        *   Xavi:
        *   Thomas: Yang model is extensive, should we start from Draft reduce to the security ?
        *   Pascal: question from Benoit is confusing a little bit. Where is the information model ?
        *   Thomas: data model = interface draft whereas information model = sublayer draft
        *   Qin: suggest we discuss in ML
        *   Pascal: can you start thread
        *   Qin: OK (ACTION)
        *   Thomas: Can we avoid this discussion again ?
•        [07.15] 6LoRH (Pascal) [20min]

     *   draft(s) status

        *   Thomas:

     *   Pascal: 6LoRH draft adopted

        *   Paging system: two documents now.
o   topic: how do we go certain things, answers tech questions from Tengfei and Simon

        *   example 1: case where we have a packet from the DODAG toward the Root (ICMP and UDP)
        *   In this case we don't need IP-in-IP ???
        *   Where is the RPI ?
        *   slide 9: ICMP example
        *   slide 10: UDP example
        *   6LoRH goes BEFORE the IPHC, this is an important addition of the draft
        *   node which wants to add a 6LoRH will NOT have to change the IPHC packet
        *   things are reversed: IPHC and IP-in-IP goes at the END of the packet
        *   as packet progresses, the addresses in 6LoRH are being removed. Different than IPv6. In
        *   in 6LoRH:
        *   routing head is "consumed": size of 6loRH is reduced as the packet travels from root into the LLN
        *   the next hop is the first address in the 6LoRH, NOT the IPv6 destination address (final destination in inner IP-in-IP header)
        *   Thomas: Do we have to carry the full IPv6 address in all RHs?
        *   Pascal: "normal" case in 6TiSCH:
        *   only 2-byte addresses, remaining 112 bits inferred from the source
        *   you know what the source of the packet is
        *   Simon: about slide 11 removing addresses as you go is good. But how interoperable with RFC6554? all addresses are in RFC6554? Would expect from 6LoRH to compress existing 6554 headers.
        *   Pascal: you can reconstruct an RH3 from 6LoRH, but it will not be the same one as if you
        *   Michael: important for efficiency. It's possible to deploy nodes with 6LoRH but not turn it on (manageable)
        *   why does it matter?
        *   Simon: in the routing header, the addresses are not consumed
        *   Pascal: 6man might complain. problem with authentication.
        *   Simon: big problem?
        *   Pascal: we have L2 security, we can trust that routing header will not be compromised.
        *   Simon: big sec threat. 6LoRH should not impact 6LoWPAN
        *   Pascal: do you want to keep the data in the RH? -technical decision
        *   Simon: AH (authentication header). In IPv6, you have to replace the destination address.
        *   Pascal: Any RPL packet could be attacked the same way. But it is not because we have L2 security. If we wanted to keep the addresses we could add an index in 6LoRH to ... WG to decide
        *   Simon: why couldn't we remove addresses from 6554?
        *   Pascal: probably for passing 6man faster.
        *   Thomas: the idea of 6554 is to do a version for 6LoWPAN. When we implemented the last plugtest, we realized that we could ping 3 hops away
        *   Even if we add an index, we will not pass 6MAN if we have an option not to use it ??
        *   Xavi: 6554 doesn't say anything about what happens
        *   the receiver doesn't ...
        *   Thomas: we can specify how the AH is calculated
        *   Pascal discusses different use cases with the types of the addresses.
•  the new draft explain the recursive process of popping the first address in RH3-6LoRH, asking text review
•  If the packet is fragmented, same fragmentation rule as IPHC

        *   discussion about where IP-in-IP header goes. Slide 14 about proposed order.
        *   when decoding 6LoRH headers,
        *   Thomas: Why multiple RH3?
        *   Pascal: e.g. from one PAN to the next
        *   Xavi: clarifying: fragmentation header right after MAC?
        *   Pascal: yes
        *   Pascal: without order, you cannot do IP-in-IP-in-IP
        *   Pascal: discussion is about the order of the headers, proposal:

           *   1st reason: starting with RH is simpler as it is consumed
           *   2nd reason: need a clear separator

        *   Pascal: proposal: reverse all the headers (keep logic as with IPHC and 6LoRH) IPHC and 6LoRH are the separators
        *   Pascal: RH3, then RPI, then 6LoRH.
        *   Simon feels it adds complexity
        *   the draft is redesigned to work on the compressed form
        *   if you don't want that you have to rewrite everything
        *   Thomas: Do we remove addresses of the routing header ?

           *   What are the arguments to put the header before ?

        *   Pascal: the main idea was to make easy to manipulate the header

           *   When its compressed its not meant to be read. DO people read in the zipped file?
•        [08.09] PlugTest [10min]

  *   Thomas: motes sent to the people
  *   dissector available
  *   Golden version available
•        Walk-through (delta) tests
•        related question about the 6lorh and 6top

  *   poipoi
  *   [07.??] AOB [1min]
  *   poipoi
  *   [08.??] Meeting ends

6tisch mailing list<>