From nobody Wed Mar 1 01:18:29 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DEC129878 for <6tisch@ietfa.amsl.com>; Wed, 1 Mar 2017 01:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm5QCJZfH4HH for <6tisch@ietfa.amsl.com>; Wed, 1 Mar 2017 01:18:26 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77672129874 for <6tisch@ietf.org>; Wed, 1 Mar 2017 01:18:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9249; q=dns/txt; s=iport; t=1488359906; x=1489569506; h=from:to:subject:date:message-id:mime-version; bh=jNCeLm7zHwXcgTlom+TSHFN20EmYwcnER0OgD2bU9M0=; b=m3sh0L87mt6V8HESx7D9RLfENAz70eps95PM4OzNL+6t0HDOihWbdUuS 0IiRIZEE0rQk6BD4QyQgvgLIRJJKIUeufPl1m68ygH4xSkduP6z9Fe9Qt 9IWuMWL04XZqJje+1JQIxkkqxY475RUlYyk4eC7BcL6pC9QwXvIfI6jTH I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAQAvkbZY/5JdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm5iYYEJB41coW2DHYIPgg0qiCs/GAECAQEBAQEBAWIdC4UkXgGBACY?= =?us-ascii?q?BBBuJcQ6hQpIriyQBAQEBAQUBAQEBAR4FhkyIBociBZwoAYFQhSSLNIIEhSGKA?= =?us-ascii?q?Ig+inUBHziBAVQVPoZNdQGIZIENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,224,1484006400"; d="scan'208,217";a="212665630" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Mar 2017 09:18:25 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v219IPKV020065 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Wed, 1 Mar 2017 09:18:25 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Mar 2017 03:18:25 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 1 Mar 2017 03:18:24 -0600 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: Slot allocation for IETF 98 Thread-Index: AdKSbJH1YDv5qgE/R1WU78hMEMkDQQ== Date: Wed, 1 Mar 2017 09:18:01 +0000 Deferred-Delivery: Wed, 1 Mar 2017 09:17:57 +0000 Message-ID: <465700ee28804eaf845e527ed2ebfab2@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.38] Content-Type: multipart/alternative; boundary="_000_465700ee28804eaf845e527ed2ebfab2XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [6tisch] Slot allocation for IETF 98 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 09:18:28 -0000 --_000_465700ee28804eaf845e527ed2ebfab2XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear 6TiSCHers, The final agenda for IETF 98 has been published at: https://datatracker.iet= f.org/meeting/98/agenda.html. Keep this link, it's always useful with a num= ber of pointers to meeting needful things. Also consider the IETF applicati= on for your smartphone... So LPWAN will be meeting from 9:00 to 11:30 in the afternoon of Tuesday Mar= ch 28th in room Zurich C. Note well: - This is probably more time than we need for usual reports, so ple= ase be prepared for in-depth discussions on the main topics, the security j= oin process and the 6P protocols, so we can really progress on the remainin= g issues. - Michael Richardson will sit next to Pascal at the desk while Thom= as joins remotely. If you'd like a slot to present a draft, please send a request to the chair= s (cc) by Wednesday March 15th. Please note that the deadline for draft sub= mission is UTC 23:59 on March 13th. We kindly request to send your slides for presentations by Tuesday March 21= st. Any WG draft not being discussed/presented needs a status update sent to th= e list by Tuesday March 21st. As always - we would appreciate your help in taking notes and jabber, pleas= e do volunteer! Looking forward to seeing you in all Chicago! Cheers, Thomas and Pascal --_000_465700ee28804eaf845e527ed2ebfab2XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear 6TiSCHers,

 

The final agenda for IETF 98 has been published a= t: https://datatracker.ietf.org/meeting/98/agenda.html. Keep this link, it= 's always useful with a number of pointers to meeting needful things. Also = consider the IETF application for your smartphone...

 

So LPWAN will be meeting from 9:00 to 11:30 in th= e afternoon of Tuesday March 28th in room Zurich C.

 

Note well:

 

-       = ;  This is probably more time than we need for usual r= eports, so please be prepared for in-depth discussions on the main topics, = the security join process and the 6P protocols, so we can really progress o= n the remaining issues.

-       = ;  Michael Richardson will sit next to Pascal at the d= esk while Thomas joins remotely.

 

If you'd like a slot to present a draft, please s= end a request to the chairs (cc) by Wednesday March 15th. Please= note that the deadline for draft submission is UTC 23:59 on March 13t= h.

 

We kindly request to send your slides for present= ations by Tuesday March 21st.

 

Any WG draft not being discussed/presented needs = a status update sent to the list by Tuesday March 21st.

 

As always - we would appreciate your help in taki= ng notes and jabber, please do volunteer!

 

Looking forward to seeing you in all Chicago!

 

Cheers,

 

Thomas and Pascal

 

--_000_465700ee28804eaf845e527ed2ebfab2XCHRCD001ciscocom_-- From nobody Fri Mar 3 06:32:24 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C181295AA for <6tisch@ietfa.amsl.com>; Fri, 3 Mar 2017 06:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uQV8Z1n3iPH for <6tisch@ietfa.amsl.com>; Fri, 3 Mar 2017 06:32:21 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171DA129595 for <6tisch@ietf.org>; Fri, 3 Mar 2017 06:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9713; q=dns/txt; s=iport; t=1488551541; x=1489761141; h=from:to:subject:date:message-id:mime-version; bh=waB60ehaZTer80/hXHORqPIcJOsCCSwhR9oAAB8iAUc=; b=Og2iG1pIVBO1vYayHCDDYAdq/SiHpB2NdIPjB/pc/lrxKB21JH7C1Wu2 2YzaPHJ2VTF/e6Fb88Bh9az9zhYLWnRt/hWVVW76uR1DIJUhGy4h7BKGL i1kHih/ihmLNWkECmLiMgrpyJtsYsIKjgAHRLo3KAtDGpCO5eYwLDdMe2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQD/fblY/4oNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm5iYYEJB41hoVGFLIINKohYPxgBAgEBAQEBAQFiHQuFJF4BgQAmAQQ?= =?us-ascii?q?biXMOommSK4sFAQEBAQEBBAEBAQEBAR0Fhk6IBoEZgnCDGQWcLAGGdYs0ggSFI?= =?us-ascii?q?ooCiEOKdwEfOIEDVhU/hlJ2AYcfgTCBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,237,1484006400"; d="scan'208,217";a="393023367" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2017 14:32:20 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v23EWK0K026710 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Fri, 3 Mar 2017 14:32:20 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 08:32:19 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 3 Mar 2017 08:32:19 -0600 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: 6TiSCH @ chicago (with corrections) Thread-Index: AdKUKqAyb0eiTAN4SYSlsmhZFgVDzg== Date: Fri, 3 Mar 2017 14:32:15 +0000 Deferred-Delivery: Fri, 3 Mar 2017 14:31:17 +0000 Message-ID: <1495ff138d6946d0a3538c63885eab64@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.38] Content-Type: multipart/alternative; boundary="_000_1495ff138d6946d0a3538c63885eab64XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [6tisch] 6TiSCH @ chicago (with corrections) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 14:32:22 -0000 --_000_1495ff138d6946d0a3538c63885eab64XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear 6TiSCHers, The final agenda for IETF 98 has been published at: https://datatracker.iet= f.org/meeting/98/agenda.html. Keep this link, it's always useful with a num= ber of pointers to meeting needful things. Also consider the IETF applicati= on for your smartphone... 6TiSCH will be meeting from 9:00 to 11:30 in the morning of Tuesday March 2= 8th in room Zurich C. Note well: - This is probably more time than we need for usual reports, so pl= ease be prepared for in-depth discussions on the main topics, the security = join process and the 6P protocols, so we can really progress on the remaini= ng issues. - Michael Richardson will sit next to Pascal at the desk while Tho= mas joins remotely. - Qin, Thomas and Xavi being remote, the 6P work will be limited If you'd like a slot to present a draft, please send a request to the chair= s (cc) by Wednesday March 15th. Please note that the deadline for draft sub= mission is UTC 23:59 on March 13th. We kindly request to send your slides for presentations by Tuesday March 21= st. Any WG draft not being discussed/presented needs a status update sent to th= e list by Tuesday March 21st. As always - we would appreciate your help in taking notes and jabber, pleas= e do volunteer! Looking forward to seeing you in all Chicago! Cheers, Thomas and Pascal --_000_1495ff138d6946d0a3538c63885eab64XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear 6TiSCHers,

 

The final agenda for IETF 98 has been published a= t: https://datatracker.ietf.org/meeting/98/agenda.html. Keep this link, it= 's always useful with a number of pointers to meeting needful things. Also = consider the IETF application for your smartphone...

 

6TiSCH will be meeting from 9:00 to 11:30 in the = morning of Tuesday March 28th in room Zurich C.

 

Note well:

 

-       = ;   This is probably more time than we need for usual r= eports, so please be prepared for in-depth discussions on the main topics, = the security join process and the 6P protocols, so we can really progress o= n the remaining issues.

-       = ;   Michael Richardson will sit next to Pascal at the d= esk while Thomas joins remotely.

-       = ;   Qin, Thomas and Xavi being remote, the 6P work will= be limited

 

If you'd like a slot to present a draft, please s= end a request to the chairs (cc) by Wednesday March 15th. Please= note that the deadline for draft submission is UTC 23:59 on March 13t= h.

 

We kindly request to send your slides for present= ations by Tuesday March 21st.

 

Any WG draft not being discussed/presented needs = a status update sent to the list by Tuesday March 21st.

 

As always - we would appreciate your help in taki= ng notes and jabber, please do volunteer!

 

Looking forward to seeing you in all Chicago!

 

Cheers,

 

Thomas and Pascal

 

--_000_1495ff138d6946d0a3538c63885eab64XCHRCD001ciscocom_-- From nobody Fri Mar 3 07:54:25 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E0012948C for <6tisch@ietfa.amsl.com>; Fri, 3 Mar 2017 07:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cVLY2W0-F55 for <6tisch@ietfa.amsl.com>; Fri, 3 Mar 2017 07:54:22 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C4C12946D for <6tisch@ietf.org>; Fri, 3 Mar 2017 07:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31701; q=dns/txt; s=iport; t=1488556462; x=1489766062; h=from:to:subject:date:message-id:mime-version; bh=Dsy13udqRGzCLX6c0iQRIKuwE2T91oogqvlaXb3ZREI=; b=AZa+jMFh1UQMMTJjQ7yk8F0S/jtcL9C2SY3m3M1p/EFGy5SrQLIwwFKy O1Q0Fo+sb0wBbXMO2kc58qrCy+DAoCDH15DA3czFYknZkyURhpJFwvZlP SkpJV0z7FSt5RlqtKRTXX10kwmGtubsAgUWFQh8ukJvXkdrL//oHT1EVw s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTBAB3kLlY/40NJK1EGhsBAQEDAQEBC?= =?us-ascii?q?QEBAYJuOSlhgQkHtF6CDSyFdoJkQBcBAgEBAQEBAQFiHQuFFAoGXgEcHAgBAzw?= =?us-ascii?q?mAQQbiXMOMaI9kXE6g1SHMwEBAQEBAQEDAQEBAQEBASGGToYrgVuBXS6BfoMZB?= =?us-ascii?q?ZwsAYZ1izSCBI8kiEOKdwEhAzOBA1YVhRMdgWF2AQSIS4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,237,1484006400"; d="scan'208,217";a="215656795" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2017 15:54:21 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v23FsLT6025931 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Fri, 3 Mar 2017 15:54:21 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 09:54:20 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 3 Mar 2017 09:54:20 -0600 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: Minutes, 03 March 2017 interim, 6TiSCH WG Thread-Index: AdKUNga2uuLX38QNTjWgyMmjP/ezUw== Date: Fri, 3 Mar 2017 15:54:18 +0000 Deferred-Delivery: Fri, 3 Mar 2017 15:53:25 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.38] Content-Type: multipart/alternative; boundary="_000_ef608deb1a354aaf923a3c897857ca09XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [6tisch] Minutes, 03 March 2017 interim, 6TiSCH WG X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 15:54:24 -0000 --_000_ef608deb1a354aaf923a3c897857ca09XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Note: timestamps in PDT. Connection details * Date: 7-8am Pacific: http://www.worldtimebuddy.com/?qm=3D1&lid=3D100,= 12,5392171,1850147&h=3D100&date=3D2017-03-03&sln=3D15-16 * Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=3D6b= 12f377131944adbcab176d931c281d * Recording password: RjQNPyA3 * Material link: https://bitbucket.org/6tisch/meetings/raw/master/17030= 3_webex/slides_170303_webex.ppt Taking notes (using Etherpad) 1. xavi vilajosana 2. Pascal Thubert Present (alphabetically) 1. Diego Dujovne 2. Dominique Barthel 3. Eva Davids 4. Malisa Vucinic 5. Michael Richardson 6. Pascal Thubert 7. Qin Wang 8. Rashid Sangi 9. Simon Duquennoy 10. Xavi Vilajosana Action Items 1. Pascal to poll Tero for comments addressed in draft minimal 21 Agenda * Administrivia [2min] * Approval agenda * Approval minutes last call * Status of drafts [Pascal] [5min] * Update on security [Michael] [10min] * Update on 6P [Xavi] [10min] * Preparation for IETF 98[Pascal] [QS] * AOB [3min] Minutes * Administrivia [2min] * Approval agenda Agenda is approved. No issues raised. * Approval minutes last call Las call minutes are approved. No issues raised. * Status of drafts [Pascal] [5min] o Action item Pascal to ping Tero and Suresh about minimal status. * Minimal seems ready according to authors. Waiting for AD to com= e back. * Update on security [Michael] [10min] * meeting every 2 weeks with an extra meeting in Feb. Tuesdays. * call is to coordinate 6tisch minimal security and zero touch secur= ity. * Some real progress on that. * Minimal security: Decided to keep the rekeying outside of the docu= ment. to keep it simple. * Some updates to oscoap and edhoc that make the draft obsolete. New= version will come with updates. Complication in the proxy mechanism. * Considering a 6tisch specific coap option * not discussed yet within security design team. o considering abandoning fully passive mode for a hybrid * larger enrollement process managed centrally. Looking for COMI = interfaces to do that. No consensus on that. * EDHOC * minimal rekey document. Moves all the rekeying process from the= 2 drafts. In both of these draft we get a key and we need to rekey. This n= ew document explains this process. * PT: K1 is shared. * MR: Any one that has the K2 can decrypt the packet. When we had= a K1 that authenticate beacons only this was only doing that. K1 was thoug= ht to be as an ethertype. There is nothing that prevents us to use a single= key to both things. It could not be well-known. 6tisch minimal security wi= ll provide a unique key for the network. It is not clear if we want to prov= ide 2 keys or with one that is private is enough. o rekey draft presented at the IETF. Michael will call for adoption. * another draft created. Deciding what to be inserted in the EB. Ide= a to use RAs in the EBs. * PT: One of the implication of using RAs is to help identifying the= network to leaf nodes. Something else than the dodagid is needed. * We do not have anything in IP that will be permanent, the prefix i= s very stable and is a good candidate. * IANA considerations in 6550 will enable the allocation of a number= there. * Update on 6P [Xavi] [10min] * Not a lot of progress. * Thomas proposed a reordering that still needs to be implemented. * RELOCATE command was added. * clarification of 2-way and 3-way transactions * Not much progress on Thomas proposal * Preparation for IETF 98[Pascal] [QS] * 6P -> thomas, xavi, qin joining remotely. * Action: Xavi and Qin to agree on who presents. * Diego will present a new version of SF0. * Security has 4 drafts, that will be presented. Merge them? or 4 sl= ots? 2 WG document + 2 new drafts. * MR: 4 slots ok. * 2 hours meeting. More time to solve problems and discuss. * slots can be used for discussion. * slides will be 4:3 for this meeting. * scribes: Diego Dujovne, Dominique Barthel. * jabber: Michael Richardson * AOB [3min] * No other B. --_000_ef608deb1a354aaf923a3c897857ca09XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Note: timestamps in PDT.

Connection details=

Taking notes (us= ing Etherpad)

  1. xavi vilajosana
  2. Pascal Thubert

Present (alphabetical= ly)

  1. Diego Dujovne
  2. Dominique Barthel
  3. Eva Davids
  4. Malisa Vucinic
  5. Michael Richardson
  6. Pascal Thubert
  7. Qin Wang
  8. Rashid Sangi
  9. Simon Duquennoy
  10. Xavi Vilajosana

Action Items

  1. Pascal to poll Tero for comments addressed in draft minimal 21

Agenda

  • Administrivia [2min]
    • Approval agenda
    • Approval minutes last call
  • Status of drafts [Pascal] [5min]
  • Update on security [Michael] [10min]
  • Update on 6P [Xavi] [10min]
  • Preparation for IETF 98[Pascal] [QS]
  • AOB [3min]

Minutes

<= span style=3D"mso-list:Ignore">·         Administrivia [2min]

    • Approval agenda

Agenda is approved. No issues raised.<= /o:p>

    • Approval minutes last call

Las call minutes are approved. No issues ra= ised.

<= span style=3D"mso-list:Ignore">·         Status of drafts [Pascal] [5min]<= /p>

o    Action item Pascal to ping Tero and Suresh a= bout minimal status.

      • Minimal seems ready according to authors. Waiting for AD to come back.=

<= span style=3D"mso-list:Ignore">·         Update on security [Michael] [10min]

    • meeting every 2 weeks with an extra meeting in Feb. Tuesd= ays.
    • call is to coordinate 6tisch minimal security and zero touch security.
    • Some real progress on that.
    • Some updates to oscoap and edhoc that make the draft obsolete. New version = will come with updates. Complication in the proxy mechanism.
    • Considering a 6tisch specific coap option
    • not discussed yet within security design team.

o    considering abandoning fully passive mode fo= r a hybrid

      • larger enrollement process managed centrally. Looking for COMI interfaces t= o do that. No consensus on that.
      • EDHOC
      • minimal rekey document. Moves all the rekeying process from the 2 drafts. I= n both of these draft we get a key and we need to rekey. This new document explains this process.
      • PT: K1 is shared.
      • MR: Any one that has the K2 can decrypt the packet. When we had a K1 that a= uthenticate beacons only this was only doing that. K1 was thought to be as = an ethertype. There is nothing that prevents us to use a single key to both= things. It could not be well-known. 6tisch minimal security will provide a unique key for the network. It is n= ot clear if we want to provide 2 keys or with one that is private is enough= .

o    rekey draft presented at the IETF. Michael w= ill call for adoption.

    • another draft created. Deciding what to be inserted in the EB. Idea to use = RAs in the EBs.
    • PT: One of the implication of using RAs is to help identifying the network = to leaf nodes. Something else than the dodagid is needed.
    • We do not have anything in IP that will be permanent, the prefix is very st= able and is a good candidate.
    • IANA considerations in 6550 will enable the allocation of a number there.

<= span style=3D"mso-list:Ignore">·         Update on 6P [Xavi] [10min]

    • Not a lot of progress.
    • Thomas proposed a reordering that still needs to be implemented.
    • RELOCATE command was added.
    • clarification of 2-way and 3-way transactions
    • Not much progress on Thomas proposal

<= span style=3D"mso-list:Ignore">·         Preparation for IETF 98[Pascal] [QS]

    • 6P -> thomas, xavi, qin joining remotely.
    • Action: Xavi and Qin to agree on who presents.
    • Diego will present a new version of SF0.
    • Security has 4 drafts, that will be presented. Merge them? or 4 slots? 2 WG= document + 2 new drafts.
    • MR: 4 slots ok.
    • 2 hours meeting. More time to solve problems and discuss.
    • <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;mso-list:l5 level2 lfo6"> slots can be used for discussion.
    • slides will be 4:3 for this meeting.
    • scribes: Diego Dujovne, Dominique Barthel.
    • jabber: Michael Richardson

<= span style=3D"mso-list:Ignore">·         AOB [3min]

    • No other B.

 

--_000_ef608deb1a354aaf923a3c897857ca09XCHRCD001ciscocom_-- From nobody Fri Mar 3 16:01:11 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C19129A30; Fri, 3 Mar 2017 15:55:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , <6tisch-chairs@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858533441.15846.11123189443543987845.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:34 -0800 Archived-At: Cc: 6tisch@ietf.org, suresh.krishnan@ericsson.com Subject: [6tisch] 6tisch - Requested session has been scheduled for IETF 98 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:34 -0000 Dear Pascal Thubert, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. 6tisch Session 1 (2:00:00) Tuesday, Morning Session I 0900-1130 Room Name: Zurich C size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IPv6 over the TSCH mode of IEEE 802.15.4e Area Name: Internet Area Session Requester: Pascal Thubert Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: 6lo roll detnet lpwan core Second Priority: bier netconf intarea 6man Third Priority: lwig cbor anima People who must be present: Michael Richardson Pascal Thubert Suresh Krishnan Thomas Watteyne Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Fri Mar 3 16:24:13 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCFB12706D; Fri, 3 Mar 2017 16:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnnQo5VPF3pt; Fri, 3 Mar 2017 16:23:59 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A45127601; Fri, 3 Mar 2017 16:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v240Nsna004414; Sat, 4 Mar 2017 01:23:55 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vZmxk4fC5zDJ6g; Sat, 4 Mar 2017 01:23:54 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <74320B9C-EA99-48E5-9F5F-7BE7982EF945@tzi.org> Date: Sat, 4 Mar 2017 01:23:53 +0100 X-Mao-Original-Outgoing-Id: 510279833.492592-498b29898a422b603ef5e99a66f31ede Content-Transfer-Encoding: quoted-printable Message-Id: <47FA3876-9087-45EB-BC36-DBD642A845FE@tzi.org> References: <74320B9C-EA99-48E5-9F5F-7BE7982EF945@tzi.org> To: Routing Over Low power and Lossy networks , lo <6lo@ietf.org>, Tisch <6tisch@ietf.org>, lp-wan , lwip@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [6tisch] Constrained Node/Network Cluster @ IETF98: FINAL AGENDA X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 00:24:02 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF98. Remember that agenda definitions are never really "FINAL"... "While this is considered the final agenda for printing, changes may be made to the agenda up until and during the meeting. Updates will be reflected on the web versions of the agenda." Compared to the draft agenda, this has mostly room changes. v6ops moved around, and tsvarea got extended to an almost four-hour meeting. All times are CDT (UTC-0500) -- yes, the US will be on DST already for a couple of weeks, while Europe moves over right on Mar 26th. (The browser timezone function still is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SUNDAY, March 26, 2017 0900-1700 IRTF*** icnrg, with some t2trg-related items on the = agenda MONDAY, March 27, 2017 0900-1130 Morning Session I Zurich A ART dispatch Dispatch WG Zurich D INT homenet Home Networking WG Zurich C SEC *** ace Authentication and Authorization for = Constrained Environments WG 1300-1500 Afternoon Session I Vevey 1/2 IRTF*** t2trg Thing-to-Thing Zurich A OPS anima Autonomic Networking Integrated Model = and Approach WG Zurich B RTG bier Bit Indexed Explicit Replication WG Zurich G RTG detnet Deterministic Networking WG Zurich E/F TSV tsvarea Transport Area Open Meeting 1520-1650 Afternoon Session II Zurich A SEC tokbind Token Binding WG Zurich E/F TSV tsvarea Transport Area Open Meeting 1710-1810 Afternoon Session III Zurich E/F GEN wugh WGs Using GitHub BOF Zurich D INT *** lwig Light-Weight Implementation Guidance WG Montreux 3 SEC curdle CURves, Deprecating and a Little more = Encryption WG Zurich C SEC oauth Web Authorization Protocol WG Vevey 1/2 TSV tsvwg Transport Area Working Group WG TUESDAY, March 28, 2017 0900-1130 Morning Session I Zurich C INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Zurich D IRTF maprg Measurement and Analysis for Protocols Zurich E/F SEC tls Transport Layer Security WG 1300-1430 Afternoon Session I Zurich C ART *** core Constrained RESTful Environments WG Zurich D INT intarea Internet Area Working Group WG Zurich A RTG babel Babel routing protocol WG 1450-1620 Afternoon Session II Zurich G ART uta Using TLS in Applications WG Zurich E/F SEC *** teep A Protocol for Dynamic Trusted Execution = Environment Enablement BOF 1640-1840 Afternoon Session III Zurich B INT dnssd Extensions for Scalable DNS Service = Discovery WG Zurich E/F TSV taps Transport Services WG WEDNESDAY, March 29, 2017 0900-1130 Morning Session I Zurich A INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG 1300-1500 Afternoon Session I Zurich C INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Zurich A OPS v6ops IPv6 Operations WG Montreux 3 TSV tcpinc TCP Increased Security WG THURSDAY, March 30, 2017 0900-1130 Morning Session I Zurich D INT 6man IPv6 Maintenance WG Zurich C IRTF icnrg Information-Centric Networking Zurich E/F RTG rtgarea Routing Area Open Meeting Vevey 1/2 TSV quic QUIC WG 1300-1500 Afternoon Session I Zurich B ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Zurich G SEC acme Automated Certificate Management = Environment WG Zurich A TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Zurich D SEC saag Security Area Open Meeting 1740-1840 Afternoon Session III Zurich B RTG *** roll Routing Over Low power and Lossy = networks WG FRIDAY, March 31, 2017 0900-1130 Morning Session I Vevey 1/2 ART httpbis Hypertext Transfer Protocol WG Zurich E/F INT ipwave IP Wireless Access in Vehicular = Environments WG Zurich A OPS anima Autonomic Networking Integrated Model = and Approach WG Zurich C SEC oauth Web Authorization Protocol WG 1150-1320 Afternoon Session I Zurich C ART *** core Constrained RESTful Environments WG From nobody Sat Mar 4 18:21:08 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081541293D6 for <6tisch@ietfa.amsl.com>; Sat, 4 Mar 2017 18:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH-1cFhzhh8C for <6tisch@ietfa.amsl.com>; Sat, 4 Mar 2017 18:21:06 -0800 (PST) Received: from atl4mhob03.myregisteredsite.com (atl4mhob03.myregisteredsite.com [209.17.115.41]) by ietfa.amsl.com (Postfix) with ESMTP id A1E53126B6D for <6tisch@ietf.org>; Sat, 4 Mar 2017 18:21:06 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id v252L5iT029997 for <6tisch@ietf.org>; Sat, 4 Mar 2017 21:21:05 -0500 Received: (qmail 12624 invoked by uid 0); 5 Mar 2017 02:21:05 -0000 X-TCPREMOTEIP: 73.207.234.73 X-Authenticated-UID: rturner@amalfisystems.com Received: from unknown (HELO ?10.0.1.32?) (rturner@amalfisystems.com@73.207.234.73) by 0 with ESMTPA; 5 Mar 2017 02:21:05 -0000 From: Randy Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <5AC19D61-FD48-457E-AACF-7F05CD180A2F@amalfisystems.com> Date: Sat, 4 Mar 2017 21:20:52 -0500 To: 6tisch@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [6tisch] nits on draft-ietf-6tisch-6top-sf0-02 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 02:21:08 -0000 Hi All, After reading the current SF0 document, I had a few nits that I thought = I would pass along - hope they=E2=80=99re helpful. Section 2: Introduction (The Scheduling Algorithm) =E2=80=9C=E2=80=A6under effective use=E2=80=A6=E2=80=9D the choice of = wording seems unorthodox. Suggest the following =E2=80=9CA portion of these allocated cells will = be effectively utilized by neighbors, while the remaining cells can be = over-provisioned to handle unanticipated increases in cell = requirements=E2=80=9D (The Relocation Algorithm) =E2=80=9CAllocated cells may experiment packet loss=E2=80=9D should be = =E2=80=9CAllocated cells may experience packet loss=E2=80=A6=E2=80=9D Section 4: SF0 Triggering Events 1. =E2=80=9C=E2=80=A6change in the current number of used cells=E2=80=9D = - could this be paraphrased to say =E2=80=9C=E2=80=A6a change in the = number of required cells=E2=80=9D ? Section 5: SF0 Estimation Algorithm The Cell Estimation Algorithm steps, # 2 - What is an =E2=80=9Ceffectively= =E2=80=9D used cell? Could this just say =E2=80=9CCollect the current = number of used cells=E2=80=9D ? There is actually quite a bit of emphasis in this document on the idea = of an =E2=80=9Ceffectively used cell=E2=80=9D - perhaps we should = explain the concept of an effectively used cell (or a reference if = it=E2=80=99s already defined) - I was curious why the term = =E2=80=9Ceffective=E2=80=9D is used so often? In the =E2=80=9CCell = Estimation Algorithm=E2=80=9D Step #2, the text reads: =E2=80=9CCollect the current number of effectively used cells=E2=80=9D = =E2=80=94 which would seem to imply that ineffectively used cells = wouldn=E2=80=99t be included in this step. This may seem a too literal = interpretation, I=E2=80=99m just looking for clarity as to whether or = not the term =E2=80=9Ceffective=E2=80=9D or =E2=80=9Ceffectively=E2=80=9D = is really needed in the doc. Section 11: Relocating Cells Just for completeness, I would emphasize how PDR is calculated, or = include a reference to some other document if defined elsewhere Thanks for this work! Randy= From nobody Sun Mar 5 05:13:15 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E6B129473 for <6tisch@ietfa.amsl.com>; Sun, 5 Mar 2017 05:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JcuWBKa6tPW for <6tisch@ietfa.amsl.com>; Sun, 5 Mar 2017 05:13:12 -0800 (PST) Received: from mo.tsb.2iij.net (mo1500.tsb.2iij.net [210.149.48.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68454126D74 for <6tisch@ietf.org>; Sun, 5 Mar 2017 05:13:12 -0800 (PST) Received: by mo.tsb.2iij.net (tsb-mo1500) id v25DDAkN020833; Sun, 5 Mar 2017 22:13:10 +0900 Received: from unknown [172.27.153.190] (EHLO tsb-mr1502.hop.2iij.net) by mas1511.tsb.2iij.net(mxl_mta-7.2.4-7) with ESMTP id 6ee0cb85.0.17844.00-697.32656.mas1511.tsb.2iij.net (envelope-from ); Sun, 05 Mar 2017 22:13:10 +0900 (JST) X-MXL-Hash: 58bc0ee621afc3e6-7a0684b408be181a1d168603f654e804b5d14738 Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by relay.tsb.2iij.net (tsb-mr1502) with ESMTP id v25DDAtB018671 for <6tisch@ietf.org>; Sun, 5 Mar 2017 22:13:10 +0900 Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id v25DDAWi028286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6tisch@ietf.org>; Sun, 5 Mar 2017 22:13:10 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id v25DDAxA005135 for <6tisch@ietf.org>; Sun, 5 Mar 2017 22:13:10 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 465 for <6tisch@ietf.org>; Sun, 5 Mar 2017 22:13:10 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id v25DD9P2005132 for <6tisch@ietf.org>; Sun, 5 Mar 2017 22:13:09 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id v25DD9HG019780 for 6tisch@ietf.org; Sun, 5 Mar 2017 22:13:09 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA19779; Sun, 5 Mar 2017 22:13:09 +0900 Received: from mx12.toshiba.co.jp (mx12.toshiba.co.jp [133.199.90.142]) by ovp11.toshiba.co.jp with ESMTP id v25DD9vb017290 for <6tisch@ietf.org>; Sun, 5 Mar 2017 22:13:09 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id v25DD95a003470; Sun, 5 Mar 2017 22:13:09 +0900 (JST) Received: from [133.196.17.218] (nm-pptp218.isl.rdc.toshiba.co.jp [133.196.17.218]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id 1117715EA87; Sun, 5 Mar 2017 22:13:09 +0900 (JST) To: 6tisch@ietf.org References: <5AC19D61-FD48-457E-AACF-7F05CD180A2F@amalfisystems.com> From: Yasuyuki Tanaka Message-ID: <2dae41eb-119e-ca61-617a-74b273b9ff2d@toshiba.co.jp> Date: Sun, 5 Mar 2017 22:13:05 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <5AC19D61-FD48-457E-AACF-7F05CD180A2F@amalfisystems.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp id v25DD9P2005132 X-MAIL-FROM: X-SOURCE-IP: [172.27.153.190] X-Spam: exempt Archived-At: Subject: Re: [6tisch] nits on draft-ietf-6tisch-6top-sf0-02 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 13:13:14 -0000 Nice comments! I also want to see the definition of "effectively used cell" and how to calculate PDR. In addition, I don't think that we would count the number of cells used for 6P in terms of SF0. Is it correct? In any case, some text on how SF0 should handle traffic or cell usage by 6P would be helpful. Best, Yatch On 2017/03/05 11:20, Randy Turner wrote: > Hi All, > > After reading the current SF0 document, I had a few nits that I thought= I would pass along - hope they=E2=80=99re helpful. > > > Section 2: Introduction > > (The Scheduling Algorithm) > > =E2=80=9C=E2=80=A6under effective use=E2=80=A6=E2=80=9D the choice of= wording seems unorthodox. > > Suggest the following =E2=80=9CA portion of these allocated cells will= be effectively utilized by neighbors, while the remaining cells can be o= ver-provisioned to handle unanticipated increases in cell requirements=E2= =80=9D > > (The Relocation Algorithm) > > =E2=80=9CAllocated cells may experiment packet loss=E2=80=9D should be = =E2=80=9CAllocated cells may experience packet loss=E2=80=A6=E2=80=9D > > > > Section 4: SF0 Triggering Events > > 1. =E2=80=9C=E2=80=A6change in the current number of used cells=E2=80=9D= - could this be paraphrased to say =E2=80=9C=E2=80=A6a change in the nu= mber of required cells=E2=80=9D ? > > > > Section 5: SF0 Estimation Algorithm > > The Cell Estimation Algorithm steps, # 2 - What is an =E2=80=9Ceffectiv= ely=E2=80=9D used cell? Could this just say =E2=80=9CCollect the current= number of used cells=E2=80=9D ? > > There is actually quite a bit of emphasis in this document on the idea = of an =E2=80=9Ceffectively used cell=E2=80=9D - perhaps we should explain= the concept of an effectively used cell (or a reference if it=E2=80=99s = already defined) - I was curious why the term =E2=80=9Ceffective=E2=80=9D= is used so often? In the =E2=80=9CCell Estimation Algorithm=E2=80=9D St= ep #2, the text reads: > =E2=80=9CCollect the current number of effectively used cells=E2=80=9D = =E2=80=94 which would seem to imply that ineffectively used cells wouldn=E2= =80=99t be included in this step. This may seem a too literal interpreta= tion, I=E2=80=99m just looking for clarity as to whether or not the term = =E2=80=9Ceffective=E2=80=9D or =E2=80=9Ceffectively=E2=80=9D is really ne= eded in the doc. > > > Section 11: Relocating Cells > > Just for completeness, I would emphasize how PDR is calculated, or incl= ude a reference to some other document if defined elsewhere > > > > > Thanks for this work! > Randy > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > From nobody Fri Mar 10 06:16:15 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED121295AC for <6tisch@ietfa.amsl.com>; Fri, 10 Mar 2017 06:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1j66ffRUwAh for <6tisch@ietfa.amsl.com>; Fri, 10 Mar 2017 06:16:12 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8207A129598 for <6tisch@ietf.org>; Fri, 10 Mar 2017 06:16:12 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 55F1FE204; Fri, 10 Mar 2017 09:38:59 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5F7396381A; Fri, 10 Mar 2017 09:16:10 -0500 (EST) From: Michael Richardson To: Thomas Watteyne In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Diego Dujovne Subject: [6tisch] Thomas comments on enhanced-beacon draft (Re: [6lo] Thomas' review of draft-richardson-6lo-ra-in-ie-00) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 14:16:14 -0000 --=-=-= Content-Type: text/plain Thomas, I didn't want process your review last fall when you did it because it was clear the document would mutate. I just went through and salvaged what parts I thought still applied. https://goo.gl/xuesHh contains a diff that contains your suggestions. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljCtSYACgkQgItw+93Q 3WULvQf+Oj4Z67mbijn8BmkIpza0eHJs/ifcIhxQAid3eTYbpP7nPmejpsbDFBHm 5vlwRwm7C5/Ogjxb2H4k3VW0Ki1eD/KnXBT9LFurIfoOX9f8D73u9itGuaShacLf 8xfNSwvFu+TJ7J+i70d502HG+iFIL6nVmuScIVjc5pLXHlZK85zjkmIaYXckhz5q kdJJxwPlXlFhxjtAFxQdB30kfeLWBWx4MzpSkFA3G+dUmWw5mP63FxOvr0xFIme/ nd7Sws66UyjqCihIthOOrnhTSY6U/e2hHQ4Ee0USlBXMgz+KmN0Nqf5F2vspps23 fTPmjzzcKyYQCp4HG0ULUU79lWBnUw== =79E9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 10 07:33:17 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D123129639; Fri, 10 Mar 2017 07:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5qGmbuHMLVN; Fri, 10 Mar 2017 07:32:59 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D09E12964B; Fri, 10 Mar 2017 07:32:55 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 81EDCE207; Fri, 10 Mar 2017 10:55:43 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5AA086381A; Fri, 10 Mar 2017 10:32:54 -0500 (EST) From: Michael Richardson To: "Panos Kampanakis \(pkampana\)" In-Reply-To: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "anima-bootstrap@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "ace@ietf.org" Subject: Re: [6tisch] [Anima-bootstrap] [Ace] EST over CoAP in ACE wg X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 6tisch-security@ietf.org, anima-bootstrap@ietf.org 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 15:33:01 -0000 --=-=-= Content-Type: text/plain {to reply to an old email with some valid questions, and some questions of my own. I am also clipping the reply-To} Panos Kampanakis (pkampana) wrote: > I am curious about your workflow in > https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html You > are envisioning for the JCE to initiate the bootstrapping to the > pledge, but wouldn't that better be defined in the > anima-bootstrapping-keyinfra doc? Constrained bootstrap is not really in scope for ANIMA. The general constrained bootstrap situation is too big, but 6tisch constrains the possible solution space, which is why we feel that we can make progress there. So, I want to accomodate constrained bootstrap in anima-bootstrap, but not define it. > About 'simple system that can be used with PSKs as authentication', I > was curious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth > with PSK/RPK/Cert? Anything more detail about these usecases? This is being proposed as 6tisch-minimal-security, and it uses OSCOAP and EDHOC. > A nit in " <--- CoAP POST /cert----- [PKCS7 Certificate] ". That > message would require the private key to be included with the cert > since the pledge did not generate it by himself. EST defines CMS for > this message. PKCS12 could suffice here as well with the challenge if > the passphrase provisioning being the problem. I'm not sure I understand this. Why do you say that the pledge did not generate it by himself? I"m assuming that it did so at manufacturing time, and that an IDevID certificate was bound to the public part of the key. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljCxyMACgkQgItw+93Q 3WXhWwf/UL6gJbmBQNTQWDcOpV94AhybwzKFHvwf16x6SpTkCZaankGezId9jSic sdjLlKoU1j2YTFW2Iyf/JkV1V5cxSrzXIZFdbFAgt5Zh5XapRO4JzRz3A4u09nwc yDwRAgncVutxQOM+7M0rI/5AiJ+UoqvP0tnaB7w9KAmy1o0JEskwl8zctq1RFw0S eglLq7tgbU096kmW/BMvDwK0bq0csq/nKoR+CjMGITGFr/8Dvsl1sAj8JoclfT9f 9n952+sqgoERhd76yK694LFCG+luYq3Y8crwVli/ldjHEK4zDV/M/PBBZpGhLAYL bvasuIKq1UHCRs44itQ9lX9l6NHjVQ== =QofY -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 12 13:11:17 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3985712941C; Sun, 12 Mar 2017 13:11:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148934947620.24704.4196788145956128117@ietfa.amsl.com> Date: Sun, 12 Mar 2017 13:11:16 -0700 Archived-At: Cc: 6tisch@ietf.org Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-02.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 20:11:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e of the IETF. Title : Minimal Security Framework for 6TiSCH Authors : Malisa Vucinic Jonathan Simon Kris Pister Michael Richardson Filename : draft-ietf-6tisch-minimal-security-02.txt Pages : 24 Date : 2017-03-12 Abstract: This document describes the minimal mechanisms required to support secure enrollment of a pledge, a device being added to an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. It assumes that the pledge has been provisioned with a credential that is relevant to the deployment - the "one-touch" scenario. The goal of this configuration is to set link-layer keys, and to establish a secure end-to-end session between each pledge and the join registrar who may use that to further configure the pledge. Additional security behaviors and mechanisms may be added on top of this minimal framework. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 12 13:18:49 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7F612947B; Sun, 12 Mar 2017 13:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qC7svEvOKBI; Sun, 12 Mar 2017 13:18:46 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF5B12941C; Sun, 12 Mar 2017 13:18:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,154,1486422000"; d="scan'208";a="264218376" Received: from unknown (HELO [172.23.248.194]) ([79.143.139.170]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Mar 2017 21:18:43 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= In-Reply-To: <148934947620.24704.4196788145956128117@ietfa.amsl.com> Date: Sun, 12 Mar 2017 21:18:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148934947620.24704.4196788145956128117@ietfa.amsl.com> To: 6tisch <6tisch@ietf.org> X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6tisch-chairs@ietf.org Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-02.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 20:18:48 -0000 All, We have submitted a new version of the minimal security draft reflecting = latest work within the security design team. I would like to request a = slot to present this version (remotely) during the Chicago meeting. Regards, Mali=C5=A1a > On 12 Mar 2017, at 21:11, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 over the TSCH mode of IEEE = 802.15.4e of the IETF. >=20 > Title : Minimal Security Framework for 6TiSCH > Authors : Malisa Vucinic > Jonathan Simon > Kris Pister > Michael Richardson > Filename : draft-ietf-6tisch-minimal-security-02.txt > Pages : 24 > Date : 2017-03-12 >=20 > Abstract: > This document describes the minimal mechanisms required to support > secure enrollment of a pledge, a device being added to an IPv6 over > the TSCH mode of IEEE 802.15.4e (6TiSCH) network. It assumes that > the pledge has been provisioned with a credential that is relevant = to > the deployment - the "one-touch" scenario. The goal of this > configuration is to set link-layer keys, and to establish a secure > end-to-end session between each pledge and the join registrar who = may > use that to further configure the pledge. Additional security > behaviors and mechanisms may be added on top of this minimal > framework. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-02 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-minimal-security-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch From nobody Mon Mar 13 05:41:31 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026361295C2 for <6tisch@ietfa.amsl.com>; Mon, 13 Mar 2017 05:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcmrpHTF5ijt for <6tisch@ietfa.amsl.com>; Mon, 13 Mar 2017 05:41:28 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659B91295C0 for <6tisch@ietf.org>; Mon, 13 Mar 2017 05:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12268; q=dns/txt; s=iport; t=1489408888; x=1490618488; h=from:to:cc:subject:date:message-id:mime-version; bh=rNGSpmqXpf5bCNz5JuwKlc+y4aj107jGP/tRXNu0UH8=; b=T7fCh1yy6+OExOTgB2v3m3aytgufX/u56miAavOVABoM/qB6L6BaiYZ6 GplETP7DHKaF/3sseoAaW2gjVqcLbmRZAm1rbGieK3Jm8b7UCx7A8WBG3 GTAkUPDTqBLhdob08y2IKX4PhWXZASkvBQpVlBdEODrsLuF6Xg69uHp7r 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAQB2ksZY/5RdJa1DGhoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJuY2GBCgeNZ5JIjxSFLYIOLIV2glI/GAECAQEBAQEBAWsdC4VJTBI?= =?us-ascii?q?BHBwMPCYBBA4NiXgOMbApg1SHAAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GToYrg?= =?us-ascii?q?VuBXS6CEoJrGgWcQQGGdYs6ggSPKohFin0BHziBBFgVhRgdgWN1AYhFgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,159,1486425600"; d="scan'208,217";a="396569692" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2017 12:41:27 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v2DCfRA5013099 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Mar 2017 12:41:27 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Mar 2017 07:41:26 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Mon, 13 Mar 2017 07:41:26 -0500 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: Agenda, 17 March 2017 interim, 6TiSCH WG !!! note !!! 3PM CET !!!! Thread-Index: AdKb9taYmKuv45qNSIqZwwC5+0V63A== Date: Mon, 13 Mar 2017 12:41:21 +0000 Deferred-Delivery: Mon, 13 Mar 2017 12:40:23 +0000 Message-ID: <9b9dac86767e42f4afedec24b2768810@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.15] Content-Type: multipart/alternative; boundary="_000_9b9dac86767e42f4afedec24b2768810XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "Prof. Diego Dujovne \(diego.dujovne@mail.udp.cl\)" , Xavi Vilajosana Guillen Subject: [6tisch] Agenda, 17 March 2017 interim, 6TiSCH WG !!! note !!! 3PM CET !!!! X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 12:41:30 -0000 --_000_9b9dac86767e42f4afedec24b2768810XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Note: timestamps in PDT. Since the US are now in summer saving time EU is n= ot, the meeting takes place at 3PM CET instead of 4PM usually. Connection details * Date: 7-8am Pacific: http://www.worldtimebuddy.com/?qm=3D1&lid=3D100,= 12,5392171,1850147&h=3D100&date=3D2017-03-17&sln=3D14-15 * Webex link: https://cisco.webex.com/ciscosales/j.php?MTID=3Dmcdbbe3a4= e38d97d986b507ec12a1f9b1 * Meeting number (access code): 203 224 694 * Meeting password: sixtus (749887 from phones) * Material link: https://bitbucket.org/6tisch/meetings/raw/master/17031= 7_webex/slides_170317_webex.ppt Agenda * Administrivia [2min] * Approval agenda * Approval minutes last call * Status of drafts [Pascal] [5min] * Update on security [Michael] [15min] * Update on 6P [Xavi] [10min] * Update on SF0 [Diego] [10min] * Preparation for IETF 98[Pascal] [QS] * AOB [3min] --_000_9b9dac86767e42f4afedec24b2768810XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Note: timestamps in PDT. Since the US are now in summer saving time EU i= s not, the meeting takes place at 3PM CET instead of 4PM usually.

Connection details=

Agenda
  • Administrivia [2min]
    • Approval agenda
    • Approval minutes last call
  • Status of drafts [Pascal] [5min]
  • Update on security [Michael] [15min]
  • Update on 6P [Xavi] [10min]
  • Update on SF0 [Diego] [10min]
  • Preparation for IETF 98[Pascal] [QS]
  • AOB [3min]

 

--_000_9b9dac86767e42f4afedec24b2768810XCHRCD001ciscocom_-- From nobody Mon Mar 13 06:16:05 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F1012940B; Mon, 13 Mar 2017 06:16:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148941096324.17051.10216387222278996362@ietfa.amsl.com> Date: Mon, 13 Mar 2017 06:16:03 -0700 Archived-At: Cc: 6tisch@ietf.org Subject: [6tisch] I-D Action: draft-ietf-6tisch-6top-sf0-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 13:16:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e of the IETF. Title : 6TiSCH 6top Scheduling Function Zero (SF0) Authors : Diego Dujovne Luigi Alfredo Grieco Maria Rita Palattella Nicola Accettura Filename : draft-ietf-6tisch-6top-sf0-03.txt Pages : 12 Date : 2017-03-13 Abstract: This document defines a Scheduling Function called "Scheduling Function Zero" (SF0). SF0 dynamically adapts the number of allocated cells between neighbor nodes, based on the amount of currently allocated cells and the neighbor nodes' cell requirements. Neighbor nodes negotiate in a distributed neighbor-to-neighbor basis the number of cell(s) to be added/deleted. SF0 uses the 6P signaling messages to add/delete cells in the schedule. This function selects the candidate cells from the schedule, defines which cells will be added/deleted and triggers the allocation/deallocation process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-sf0/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-6top-sf0-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 06:17:40 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915EC129604 for <6tisch@ietfa.amsl.com>; Mon, 13 Mar 2017 06:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oK8OWMdIk0Y for <6tisch@ietfa.amsl.com>; Mon, 13 Mar 2017 06:17:36 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6305B1295E4 for <6tisch@ietf.org>; Mon, 13 Mar 2017 06:17:33 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id g10so103428531wrg.2 for <6tisch@ietf.org>; Mon, 13 Mar 2017 06:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=BmxNnZhtUPuSZQ6skMifY/jsPJwqfXWFenMJsy/mGcA=; b=QhnqraSmBunkSOcBbysAmaZd+V93k2aZr1Yll4Av5w3tJvJLzzFEuhuW8znvkPHqtv 3raEzVZsgCD6wA9+DYyYehzM4ceF7uSmwnFtz9hczInRHk0lxQjbx5zwjbGx+z4kKVwD 0zeMnpJmJZgDjDI7KTd7jzRdRY48lRrjVOFwgBxOaP/K9rpim+uqyzlCKihF4mw15CEI Z8jJ4Dru9bosVWuILB8x25oF07mTvstYwcMwiLfBJC1PXxjSJulNad1nhnh+iO2HJSbW 7YX+7vgzX2Aq8Fpe2WpLfT6Q4Nl8852u3s/6tbixmvTjtsI9fyWQsCJZjgrt7zD03QXD octQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=BmxNnZhtUPuSZQ6skMifY/jsPJwqfXWFenMJsy/mGcA=; b=O/RiBU7pwxJyd6RvCRQBYKV/PkeLVu4PcTP/F3Z3RmSbI27gU9UR/GHW9Lv7mPyRbJ G9C6pJKNjqmUeSrEUceVDSgPAlOxJbDs7Rj49Ueuv+qRdhb2zTtFYiMwqm5YESJl7J89 RDDyX4yEckOPmE+CHxsz5gI7eLvsopDMAohPCvR8AWRZsZH2eb5vBzZNwnkOGiWBr8Sy ze481fhJJqPNOEk6h7KT5r+8rPJBTK4XItg30fl/QXXQ6aQOQzGkItqdOeOK4WxT+HaP MfK/wyu7hwzuz1xGxC87oOWUoqczXVgC62eNXqWv9DuM2hP6Z1B4sm/ecbjOnmVgdGnm qrXA== X-Gm-Message-State: AMke39nfnW+vBbpflLRq0tqc5rp4h8ragR0zQZkYD7W/jNvZBqGmJ8ZstPtvxX7FUVwlEW3iubOf4w9zsaBxpQ== X-Received: by 10.223.154.225 with SMTP id a88mr27435907wrc.5.1489411051614; Mon, 13 Mar 2017 06:17:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.163.3 with HTTP; Mon, 13 Mar 2017 06:17:11 -0700 (PDT) In-Reply-To: <148941096336.17051.7079430302682817490.idtracker@ietfa.amsl.com> References: <148941096336.17051.7079430302682817490.idtracker@ietfa.amsl.com> From: "Prof. Diego Dujovne" Date: Mon, 13 Mar 2017 10:17:11 -0300 Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=f403045f55a8a80914054a9c88da Archived-At: Subject: [6tisch] Fwd: New Version Notification for draft-ietf-6tisch-6top-sf0-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 13:17:38 -0000 --f403045f55a8a80914054a9c88da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For your information, there is a new version of SF0 available. Regards, Diego Dujovne A new version of I-D, draft-ietf-6tisch-6top-sf0-03.txt has been successfully submitted by Diego Dujovne and posted to the IETF repository. Name: draft-ietf-6tisch-6top-sf0 Revision: 03 Title: 6TiSCH 6top Scheduling Function Zero (SF0) Document date: 2017-03-13 Group: 6tisch Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-ietf-6tisch-6top= - sf0-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-sf0= / Htmlized: https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-03 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-6top- sf0-03 Abstract: This document defines a Scheduling Function called "Scheduling Function Zero" (SF0). SF0 dynamically adapts the number of allocated cells between neighbor nodes, based on the amount of currently allocated cells and the neighbor nodes' cell requirements. Neighbor nodes negotiate in a distributed neighbor-to-neighbor basis the number of cell(s) to be added/deleted. SF0 uses the 6P signaling messages to add/delete cells in the schedule. This function selects the candidate cells from the schedule, defines which cells will be added/deleted and triggers the allocation/deallocation process. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --f403045f55a8a80914054a9c88da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For your information, there is = a new version of SF0 available.
Regards= ,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Diego Dujovne


A new version of= I-D, draft-ietf-6tisch-6top-sf0-03.txt
has been successfully submitted by Diego Dujovne and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-6tisch-6top-sf0 Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6TiSCH 6top Scheduling Function Ze= ro (SF0)
Document date:=C2=A0 2017-03-13
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6tisch
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-6tisch= -6top-sf0-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-sf0/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-03
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-6top= -sf0-03

Abstract:
=C2=A0 =C2=A0This document defines a Scheduling Function called "Sched= uling
=C2=A0 =C2=A0Function Zero" (SF0).=C2=A0 SF0 dynamically adapts the nu= mber of allocated
=C2=A0 =C2=A0cells between neighbor nodes, based on the amount of currently=
=C2=A0 =C2=A0allocated cells and the neighbor nodes' cell requirements.= =C2=A0 Neighbor
=C2=A0 =C2=A0nodes negotiate in a distributed neighbor-to-neighbor basis th= e
=C2=A0 =C2=A0number of cell(s) to be added/deleted.=C2=A0 SF0 uses the 6P s= ignaling
=C2=A0 =C2=A0messages to add/delete cells in the schedule.=C2=A0 This funct= ion selects
=C2=A0 =C2=A0the candidate cells from the schedule, defines which cells wil= l be
=C2=A0 =C2=A0added/deleted and triggers the allocation/deallocation process= .





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
D= IEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica y Telecomu= nicaciones
Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Ch= ile
www.ingen= ieria.udp.cl
(56 2) 676 8125
--f403045f55a8a80914054a9c88da-- From nobody Thu Mar 16 23:55:41 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49ACA1243FE for <6tisch@ietfa.amsl.com>; Thu, 16 Mar 2017 23:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg-e12qffpp0 for <6tisch@ietfa.amsl.com>; Thu, 16 Mar 2017 23:55:37 -0700 (PDT) Received: from mo.tsb.2iij.net (mo1501.tsb.2iij.net [210.149.48.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9F81242F7 for <6tisch@ietf.org>; Thu, 16 Mar 2017 23:55:36 -0700 (PDT) Received: by mo.tsb.2iij.net (tsb-mo1501) id v2H6tZhx016067; Fri, 17 Mar 2017 15:55:35 +0900 Received: from unknown [172.27.153.187] (EHLO tsb-mr1501.hop.2iij.net) by mas1506.tsb.2iij.net(mxl_mta-7.2.4-7) with ESMTP id 7688bc85.0.23143.00-696.46646.mas1506.tsb.2iij.net (envelope-from ); Fri, 17 Mar 2017 15:55:35 +0900 (JST) X-MXL-Hash: 58cb88670489c43e-29ec692ccb71cdc58a7a6d04bc8669086f548c82 Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by relay.tsb.2iij.net (tsb-mr1501) with ESMTP id v2H6tZTa000432 for <6tisch@ietf.org>; Fri, 17 Mar 2017 15:55:35 +0900 Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id v2H6tZ8i005502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6tisch@ietf.org>; Fri, 17 Mar 2017 15:55:35 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id v2H6tZY2030366 for <6tisch@ietf.org>; Fri, 17 Mar 2017 15:55:35 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 40 for <6tisch@ietf.org>; Fri, 17 Mar 2017 15:55:35 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id v2H6tYSl030353 for <6tisch@ietf.org>; Fri, 17 Mar 2017 15:55:34 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id v2H6tYBH018827 for 6tisch@ietf.org; Fri, 17 Mar 2017 15:55:34 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id RAA18801; Fri, 17 Mar 2017 15:55:33 +0900 Received: from mx12.toshiba.co.jp (mx12.toshiba.co.jp [133.199.90.142]) by ovp11.toshiba.co.jp with ESMTP id v2H6tX9A010045 for <6tisch@ietf.org>; Fri, 17 Mar 2017 15:55:33 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id v2H6tXNh006121; Fri, 17 Mar 2017 15:55:33 +0900 (JST) Received: from [133.196.16.103] (ncg-dhcp103.isl.rdc.toshiba.co.jp [133.196.16.103]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id E9D9A15F788; Fri, 17 Mar 2017 15:55:32 +0900 (JST) To: 6tisch@ietf.org References: <5AC19D61-FD48-457E-AACF-7F05CD180A2F@amalfisystems.com> <2dae41eb-119e-ca61-617a-74b273b9ff2d@toshiba.co.jp> From: Yasuyuki Tanaka Message-ID: <871cd60c-0d9b-2c47-84a3-49ebdc765ad0@toshiba.co.jp> Date: Fri, 17 Mar 2017 15:55:59 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2dae41eb-119e-ca61-617a-74b273b9ff2d@toshiba.co.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp id v2H6tYSl030353 X-MAIL-FROM: X-SOURCE-IP: [172.27.153.187] X-Spam: exempt Archived-At: Subject: [6tisch] effectively used cells - Re: nits on draft-ietf-6tisch-6top-sf0-02 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 06:55:39 -0000 Hi, I'm reading the new draft of SF0 and noticed the authors have resolved co= mments on a phrase of "effectively used cells" in it! https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-03 However, there is still one "effectively used cells" remaining in section= 2: draft> ... In order to reduce consumption, this algorithm is triggered on= ly when draft> there is a change on the number of effectively used cells or if th= ere is draft> a change on the number of requested cells from a particular node. Should this "effectively used cells" be replaced with "required cells" or= should "the number of effectively used cells" be replaced with "the current numb= er of required cells" according to section 4...? Thank you! Yatch On 2017/03/05 22:13, Yasuyuki Tanaka wrote: > Nice comments! > > I also want to see the definition of "effectively used cell" and > how to calculate PDR. > > In addition, I don't think that we would count the number of > cells used for 6P in terms of SF0. Is it correct? In any case, > some text on how SF0 should handle traffic or cell usage by 6P > would be helpful. > > Best, > Yatch > > On 2017/03/05 11:20, Randy Turner wrote: >> Hi All, >> >> After reading the current SF0 document, I had a few nits that I though= t I would pass along - hope they=E2=80=99re helpful. >> >> >> Section 2: Introduction >> >> (The Scheduling Algorithm) >> >> =E2=80=9C=E2=80=A6under effective use=E2=80=A6=E2=80=9D the choice o= f wording seems unorthodox. >> >> Suggest the following =E2=80=9CA portion of these allocated cells wil= l be effectively utilized by neighbors, while the remaining cells can be = over-provisioned to handle unanticipated increases in cell requirements=E2= =80=9D >> >> (The Relocation Algorithm) >> >> =E2=80=9CAllocated cells may experiment packet loss=E2=80=9D should be= =E2=80=9CAllocated cells may experience packet loss=E2=80=A6=E2=80=9D >> >> >> >> Section 4: SF0 Triggering Events >> >> 1. =E2=80=9C=E2=80=A6change in the current number of used cells=E2=80=9D= - could this be paraphrased to say =E2=80=9C=E2=80=A6a change in the nu= mber of required cells=E2=80=9D ? >> >> >> >> Section 5: SF0 Estimation Algorithm >> >> The Cell Estimation Algorithm steps, # 2 - What is an =E2=80=9Ceffecti= vely=E2=80=9D used cell? Could this just say =E2=80=9CCollect the curren= t number of used cells=E2=80=9D ? >> >> There is actually quite a bit of emphasis in this document on the idea= of an =E2=80=9Ceffectively used cell=E2=80=9D - perhaps we should explai= n the concept of an effectively used cell (or a reference if it=E2=80=99s= already defined) - I was curious why the term =E2=80=9Ceffective=E2=80=9D= is used so often? In the =E2=80=9CCell Estimation Algorithm=E2=80=9D St= ep #2, the text reads: >> =E2=80=9CCollect the current number of effectively used cells=E2=80=9D= =E2=80=94 which would seem to imply that ineffectively used cells wouldn= =E2=80=99t be included in this step. This may seem a too literal interpr= etation, I=E2=80=99m just looking for clarity as to whether or not the te= rm =E2=80=9Ceffective=E2=80=9D or =E2=80=9Ceffectively=E2=80=9D is really= needed in the doc. >> >> >> Section 11: Relocating Cells >> >> Just for completeness, I would emphasize how PDR is calculated, or inc= lude a reference to some other document if defined elsewhere >> >> >> >> >> Thanks for this work! >> Randy >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> From nobody Fri Mar 17 07:09:27 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F14A12943B for <6tisch@ietfa.amsl.com>; Fri, 17 Mar 2017 07:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff7C3pyUTHU2 for <6tisch@ietfa.amsl.com>; Fri, 17 Mar 2017 07:09:19 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE73F126C23 for <6tisch@ietf.org>; Fri, 17 Mar 2017 07:09:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0F093205BD for <6tisch@ietf.org>; Fri, 17 Mar 2017 10:32:32 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CE8A5636BB for <6tisch@ietf.org>; Fri, 17 Mar 2017 10:09:18 -0400 (EDT) From: Michael Richardson To: tisch <6tisch@ietf.org> X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Fri, 17 Mar 2017 10:09:18 -0400 Message-ID: <4408.1489759758@obiwan.sandelman.ca> Archived-At: Subject: [6tisch] meeting is now X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:09:26 -0000 The virtual interim meeting is now (10am EDT), rather than 11am EST. Because north americans changed our clocks... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Fri Mar 17 18:24:01 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BE1129784; Fri, 17 Mar 2017 18:23:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-6tisch-minimal@ietf.org, 6tisch-chairs@ietf.org, pthubert@cisco.com, 6tisch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148980023965.21397.18112976634202456406.idtracker@ietfa.amsl.com> Date: Fri, 17 Mar 2017 18:23:59 -0700 Archived-At: Subject: [6tisch] Kathleen Moriarty's No Objection on draft-ietf-6tisch-minimal-21: (with COMMENT) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 01:24:00 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-6tisch-minimal-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing the issues raised by the SecDir review. From nobody Mon Mar 20 14:57:51 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB7B126DFB; Mon, 20 Mar 2017 14:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9gtcqmaDIxC; Mon, 20 Mar 2017 14:57:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A311276AF; Mon, 20 Mar 2017 14:57:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 00EEEE033; Mon, 20 Mar 2017 18:21:10 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 45DD3636BB; Mon, 20 Mar 2017 17:57:46 -0400 (EDT) From: Michael Richardson To: "Ace\@ietf.org" reply-to: ace@ietf.org CC: 6tisch@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [6tisch] EDHOC and EALS use in 6tisch (minimal) bootstrap X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 21:57:49 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {I left G=C3=B6ran's links at the bottom. Please excuse the length: I didn'= t have time to make it shorter} The documents https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ and https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-secure-jo= in/ are in the process of being hybridized. Some background: There are two of them because there is some concern that a full zero-touch bootstrap will require too many round trips. In the smallest networks a completely manual bootstrap is acceptable to some. In the biggest industrial networks, nothing less than a full asymmetric key bootstrap is acceptable. This is often due to human factors as well well (installers not trusted with symmetric keys!). In between are some networks where managing a large number of (hopefully unique!) symmetric join keys that have to be provisioned at the factory is acceptable. This is how pre-6tisch 802.15.4 networks are being deployed today. We are doing this work in 6tisch because we can pin down a number of variables that would otherwise cause significant scope creep: 1) we assume a clueful network operator (or contractor) who can sanely operate our Join Registrar/Coordinator [which is in the zero-touch cas= e, is a CA]. ---> this means our solution does not scale to residential or small office situations, and that is acceptable to us. 2) we have some pretty low constraints on network bandwidth available, but we also have ways to partition available bandwidth so that we can limit the impact of DoS attacks. 3) we are very much starved for broadcast slots (one opportunity every few minutes is not unusual). So we do want to pack all our discovery into a single broadcast packet. Said discovery packet can be authenticated= , but needs to be unencrypted for a number reasons. 4) we use RPL as the routing protocol across a mesh, which forms one (or more) tree-like DAGs. Close to the root there are significant bandwid= th constraints, and the convergence of traffic there can cause congestion. If properly provisioned, upper-mesh nodes may not suffer as much from energy, it can really hurt nodes further down the tree if they transmit packets upwards, only to have them dropped due to congestion, and then are forced to carry useless retransmits. As such, we are looking for solutions that where can coordinate the join process centrally, and we can accomodate innovation at the edges in the form of DoS defenses. 5) because the is radios, there is no inherent "this is the right network, because the operator plugged you", which comes with most wired network= s. There also isn't a user to pick the right ESSID. Many of these requirements do not apply to many in-home devices that can expect to operate over high-bandwidth wifi, with mains power or easily recharged batteries. REUSE =3D=3D=3D=3D=3D One of the major goals of the 6tisch-security design team is invent as litt= le as possible! In particular, code and libraries that would be present for bootstrap and be unused during the application usage are to avoided! Code space is precious, but more precious is developers paying attention to quality of implementation issues in the core. So we are trying to reuse as much of the ACE "platform" as we can: a) CoAP is the base. b) CoAP block transfer where we need bigger blocks. c) rekeying using OSCOAP to access a CoMI defined set of 802.15.4 mgmt interfaces. d) EDHOC can provide for our initial keying process. With symmetric per-pledge one-touch keys, this is very frugle for number of bytes transfered. Asymmetric keys use zero-touch IDevID certificates, and ownership vouchers which are in common with the work in ANIMA and NETCONF. e) we think that our enrollment protocol is ideally suited to make the introductions between RS<->RO, and C<->RqP that ACE needs for bootstraping it's trust model. It might be that the OSCOAP connection created *is* the trust session keys, or could be that another connection is leveraged from that trust relationship. In particular, we want rekeying the 6tisch L2 network keys to be just "yet another" mgmt process that occurs between our network management elements and groups of nodes. ADOPTING DOCUMENTS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We (6tisch) need EDHOC, and either EALS or something like it as our equivalent to EST. We need them adopted and progressed. Working on them ourselves is not in our charter. I'm personally not sure that EDHOC and EALS belong in ACE. It could be that they really belonged in COSE, but that WG has been concluded. Given that, I don't see another place for them other than ACE, but I am concerned that it may be too distracting to other work in ACE. G=C3=B6ran Selander wrote: > * EDHOC > https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-05 > Following the last round of reviews we have updated this application > layer key exchange protocol which is used e.g. in the OSCOAP profile = of > ACE and in the 6TiSCH minimal security framework. We think this is now > ready to move forward. > Time: 15 min Objective: Call for adoption > * EALS > https://www.ietf.org/internet-drafts/draft-selander-ace-eals-00.txt > This is a strawman on certificate enrolment using the new IoT > application layer security protocols. If certificate enrolment for IoT > devices is on the agenda then we would like to present this. > Time: 10 min Objective: Ask for review =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljQUFkACgkQgItw+93Q 3WX85Af9FnlNxhkDftXJjKklNfA5408F47QCRHtKgniAf3R7hTNQbJee2/vxYlPv 37ygQ0EMwYL8A+F/biuWDacxv+2C4vlQbSICnje/Xtu9Qd7arKkdp8+INuJMfAnV tbaANuADV/RKcmxiGOd/sqfy6xE+02sCrctn3WEL19UByvf5LEJiuyKrha1FwzHe fACPvrDAvXeYaBVhD0QC5Lhvw7BpSz/cfo42kXBRifPEVtc504By+M138Em2LjZJ aYOzVXAP6FfuBmNe6D4iaScppRrI7ZZj1uhnsjzxWyiiWGoKk6b/BUYqF5iV3vMF sm1GJ6bB/yjRUWZUo6mC0W76Pyt1TA== =5u4V -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 21 05:45:46 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4F21297DE; Tue, 21 Mar 2017 05:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKy7Xv72vFwu; Tue, 21 Mar 2017 05:45:42 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C40129850; Tue, 21 Mar 2017 05:45:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,198,1486422000"; d="scan'208";a="217509691" Received: from unknown (HELO [128.93.85.17]) ([128.93.85.17]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2017 13:45:39 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= In-Reply-To: <25751.1490047066@obiwan.sandelman.ca> Date: Tue, 21 Mar 2017 13:45:38 +0100 Cc: 6tisch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <43F68CBB-147F-4C85-BE7B-33B741AFEA05@inria.fr> References: <25751.1490047066@obiwan.sandelman.ca> To: ace@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [6tisch] EDHOC and EALS use in 6tisch (minimal) bootstrap X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 12:45:45 -0000 +1 on adopting the EDHOC work in ACE.=20 To add to Michael=E2=80=99s summary, I would also like to stress that in = draft-ietf-6tisch-minimal-security the one-hop neighbor of a pledge = (joining node) plays the role of an untrusted CoAP proxy in order to = facilitate pledge=E2=80=99s communication with the Registrar. = Facilitating key agreement in such a setting, i.e. through the proxy, is = necessary and is another reason why we use EDHOC. Mali=C5=A1a > On 20 Mar 2017, at 22:57, Michael Richardson = wrote: >=20 >=20 > {I left G=C3=B6ran's links at the bottom. Please excuse the length: I = didn't have > time to make it shorter} >=20 > The documents = https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ > and = https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-secure-join/= > are in the process of being hybridized. >=20 > Some background: >=20 > There are two of them because there is some concern that a full = zero-touch > bootstrap will require too many round trips. In the smallest networks = a > completely manual bootstrap is acceptable to some. >=20 > In the biggest industrial networks, nothing less than a full = asymmetric key > bootstrap is acceptable. This is often due to human factors as well = well > (installers not trusted with symmetric keys!). In between are some = networks > where managing a large number of (hopefully unique!) symmetric join = keys > that have to be provisioned at the factory is acceptable. This is how > pre-6tisch 802.15.4 networks are being deployed today. >=20 > We are doing this work in 6tisch because we can pin down a number of > variables that would otherwise cause significant scope creep: > 1) we assume a clueful network operator (or contractor) who can = sanely > operate our Join Registrar/Coordinator [which is in the zero-touch = case, > is a CA]. > ---> this means our solution does not scale to residential or = small > office situations, and that is acceptable to us. >=20 > 2) we have some pretty low constraints on network bandwidth = available, but > we also have ways to partition available bandwidth so that we can = limit > the impact of DoS attacks. >=20 > 3) we are very much starved for broadcast slots (one opportunity = every few > minutes is not unusual). So we do want to pack all our discovery = into > a single broadcast packet. Said discovery packet can be = authenticated, but needs > to be unencrypted for a number reasons. >=20 > 4) we use RPL as the routing protocol across a mesh, which forms one = (or > more) tree-like DAGs. Close to the root there are significant = bandwidth > constraints, and the convergence of traffic there can cause = congestion. > If properly provisioned, upper-mesh nodes may not suffer as much = from > energy, it can really hurt nodes further down the tree if they = transmit > packets upwards, only to have them dropped due to congestion, and = then > are forced to carry useless retransmits. > As such, we are looking for solutions that where can coordinate = the > join process centrally, and we can accomodate innovation at the = edges > in the form of DoS defenses. >=20 > 5) because the is radios, there is no inherent "this is the right = network, > because the operator plugged you", which comes with most wired = networks. > There also isn't a user to pick the right ESSID. >=20 > Many of these requirements do not apply to many in-home devices that = can > expect to operate over high-bandwidth wifi, with mains power or easily > recharged batteries. >=20 > REUSE > =3D=3D=3D=3D=3D >=20 > One of the major goals of the 6tisch-security design team is invent as = little > as possible! In particular, code and libraries that would be present = for > bootstrap and be unused during the application usage are to avoided! = Code > space is precious, but more precious is developers paying attention to > quality of implementation issues in the core. >=20 > So we are trying to reuse as much of the ACE "platform" as we can: >=20 > a) CoAP is the base. >=20 > b) CoAP block transfer where we need bigger blocks. >=20 > c) rekeying using OSCOAP to access a CoMI defined set of 802.15.4 mgmt > interfaces. >=20 > d) EDHOC can provide for our initial keying process. With symmetric > per-pledge one-touch keys, this is very frugle for number of bytes > transfered. > Asymmetric keys use zero-touch IDevID certificates, and ownership > vouchers which are in common with the work in ANIMA and NETCONF. >=20 > e) we think that our enrollment protocol is ideally suited to > make the introductions between RS<->RO, and C<->RqP that ACE > needs for bootstraping it's trust model. > It might be that the OSCOAP connection created *is* the trust > session keys, or could be that another connection is leveraged from > that trust relationship. >=20 > In particular, we want rekeying the 6tisch L2 network keys to be = just > "yet another" mgmt process that occurs between our network = management > elements and groups of nodes. >=20 >=20 > ADOPTING DOCUMENTS > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > We (6tisch) need EDHOC, and either EALS or something like it as our > equivalent to EST. We need them adopted and progressed. > Working on them ourselves is not in our charter. >=20 > I'm personally not sure that EDHOC and EALS belong in ACE. > It could be that they really belonged in COSE, but that WG has been > concluded. >=20 > Given that, I don't see another place for them other than ACE, but I = am > concerned that it may be too distracting to other work in ACE. >=20 >=20 >=20 > G=C3=B6ran Selander wrote: >> * EDHOC >=20 >> https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-05 >=20 >> Following the last round of reviews we have updated this application >> layer key exchange protocol which is used e.g. in the OSCOAP profile = of >> ACE and in the 6TiSCH minimal security framework. We think this is = now >> ready to move forward. >=20 >> Time: 15 min Objective: Call for adoption >=20 >> * EALS >=20 >> https://www.ietf.org/internet-drafts/draft-selander-ace-eals-00.txt >=20 >> This is a strawman on certificate enrolment using the new IoT >> application layer security protocols. If certificate enrolment for = IoT >> devices is on the agenda then we would like to present this. >=20 >> Time: 10 min Objective: Ask for review >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch From nobody Tue Mar 21 13:16:33 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77161296D5 for <6tisch@ietfa.amsl.com>; Tue, 21 Mar 2017 13:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6o_9oy3AMp4E for <6tisch@ietfa.amsl.com>; Tue, 21 Mar 2017 13:16:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2229D129516 for <6tisch@ietf.org>; Tue, 21 Mar 2017 13:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=339; q=dns/txt; s=iport; t=1490127390; x=1491336990; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=noJuXUvDICoWhgXauj1gQYs3Vjs0VGs1p/knBPDsw3w=; b=Isc4ZfZ01TAqB9UUCOi72oQaMKJswjLxpF/MWKikr58f24y9K/uKq+gz m64QZsd60e60/WbuxxN52R4qSzAFnVRbI+FVuALdovIHl1S8ldQhM2cJj 5ksfdj8LasGksLDif9mtFq7KJpgTXNwu1j8mhu9IKEh4o32dXaXbjXyjl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAQCjiNFY/5FdJa1eGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1FhgQoHjWunIoIOLIkPPxgBAgEBAQEBAQFrHQuFVlEBPkImAQQbiXwOmmC?= =?us-ascii?q?SLIpGAQEBBwEBAQEBAR0Fhk6PKAWcUAGGeYtDgWwBF4UoigqTXgEfOIEEWBWHG?= =?us-ascii?q?HWINIENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,201,1486425600"; d="scan'208";a="221350651" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2017 20:16:29 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v2LKGTwk020102 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Tue, 21 Mar 2017 20:16:29 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Mar 2017 15:16:28 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Tue, 21 Mar 2017 15:16:28 -0500 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: WG agenda posted Thread-Index: AdKifzj7OdSAdKYNS6q+oGvPTNiskg== Date: Tue, 21 Mar 2017 20:16:18 +0000 Deferred-Delivery: Tue, 21 Mar 2017 20:15:47 +0000 Message-ID: <35d277b9316e4aaeb4bcdd86090dbe2e@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.216.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [6tisch] WG agenda posted X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 20:16:32 -0000 Dear all: Please note that the agenda for the 6TiSCH meeting at IETF 98 was posted: https://www.ietf.org/proceedings/98/agenda/agenda-98-6tisch-06 Presenters: please use the usual template: https://bitbucket.org/6tisch/meetings/src/master/170328_ietf98_chicago/ietf= 98_6tisch_zz_template.ppt =20 Take care, The chairs From nobody Wed Mar 22 03:28:57 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884941294CE for <6tisch@ietfa.amsl.com>; Wed, 22 Mar 2017 03:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yystYLyb30O for <6tisch@ietfa.amsl.com>; Wed, 22 Mar 2017 03:28:53 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320331316CE for <6tisch@ietf.org>; Wed, 22 Mar 2017 03:28:50 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:214]) by smtp-cloud2.xs4all.net with ESMTP id yyUn1u00F0F6qFb01yUnWF; Wed, 22 Mar 2017 11:28:48 +0100 Received: from 2001:983:a264:1:a040:505d:3433:bb87 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 22 Mar 2017 11:28:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 22 Mar 2017 11:28:47 +0100 From: peter van der Stok To: ace@ietf.org Cc: 6tisch@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <25751.1490047066@obiwan.sandelman.ca> References: <25751.1490047066@obiwan.sandelman.ca> Message-ID: <16fa51ecd0a5cc19020f0fafeb27b129@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [6tisch] [Ace] EDHOC and EALS use in 6tisch (minimal) bootstrap X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 10:28:55 -0000 Hi Michael, thanks for this extended explanation. This really helps to understand the final goals and motivation. A few questions below to remove my remaining confusion. Michael Richardson schreef op 2017-03-20 22:57: > > Some background: > > There are two of them because there is some concern that a full > zero-touch > bootstrap will require too many round trips. In the smallest networks a > completely manual bootstrap is acceptable to some. I need some more explanation here. It will help if there are some numbers comparing the two approaches. And is "completely manual" identical to "one touch"? Or do you see gradations from completely manual to fully automatic? > > In the biggest industrial networks, nothing less than a full asymmetric > key > bootstrap is acceptable. This is often due to human factors as well > well > (installers not trusted with symmetric keys!). In between are some > networks > where managing a large number of (hopefully unique!) symmetric join > keys > that have to be provisioned at the factory is acceptable. This is how > pre-6tisch 802.15.4 networks are being deployed today. The above applies to 6tisch networks only? > > We are doing this work in 6tisch because we can pin down a number of > variables that would otherwise cause significant scope creep: > 1) we assume a clueful network operator (or contractor) who can > sanely > operate our Join Registrar/Coordinator [which is in the zero-touch > case, > is a CA]. > ---> this means our solution does not scale to residential or > small > office situations, and that is acceptable to us. That is a very large logical step for me; small offices and residential are small networks in my view. And small networks do not accept zero touch? Probably, I misunderstand the reasoning. > > 4) we use RPL as the routing protocol across a mesh, which forms one > (or > more) tree-like DAGs. Close to the root there are significant > bandwidth > constraints, and the convergence of traffic there can cause > congestion. > If properly provisioned, upper-mesh nodes may not suffer as much > from > energy, it can really hurt nodes further down the tree if they > transmit > packets upwards, only to have them dropped due to congestion, and > then > are forced to carry useless retransmits. > As such, we are looking for solutions that where can coordinate > the > join process centrally, and we can accomodate innovation at the > edges > in the form of DoS defenses. Coordinate meaning a central control algorithm? The RPL bandwidth constraints at the root is a general problem. Can this not be separated out? > > REUSE > ===== > > One of the major goals of the 6tisch-security design team is invent as > little > as possible! In particular, code and libraries that would be present > for > bootstrap and be unused during the application usage are to avoided! > Code > space is precious, but more precious is developers paying attention to > quality of implementation issues in the core. > > So we are trying to reuse as much of the ACE "platform" as we can: I completely approve, this should also apply to other than 6tisch networks > > a) CoAP is the base. > > b) CoAP block transfer where we need bigger blocks. > > c) rekeying using OSCOAP to access a CoMI defined set of 802.15.4 mgmt > interfaces. interesting thought; Make re-keying a management issue. > > e) we think that our enrollment protocol is ideally suited to > make the introductions between RS<->RO, and C<->RqP that ACE > needs for bootstraping it's trust model. RS <-> RO and C<->RqP?; what is the mapping to pledge, JA and Registrar? Looking forward to the presentations, Peter From nobody Wed Mar 22 07:20:51 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD11E1243FE; Wed, 22 Mar 2017 06:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZtt43TAbs8g; Wed, 22 Mar 2017 06:31:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60EDE1201FA; Wed, 22 Mar 2017 06:31:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 96242E1EE; Wed, 22 Mar 2017 09:55:13 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2F87E636BB; Wed, 22 Mar 2017 09:31:43 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org cc: ace@ietf.org, 6tisch@ietf.org In-Reply-To: <16fa51ecd0a5cc19020f0fafeb27b129@xs4all.nl> References: <25751.1490047066@obiwan.sandelman.ca> <16fa51ecd0a5cc19020f0fafeb27b129@xs4all.nl> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [6tisch] [Ace] EDHOC and EALS use in 6tisch (minimal) bootstrap X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 13:31:46 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: >> There are two of them because there is some concern that a full >> zero-touch bootstrap will require too many round trips. In the >> smallest networks a completely manual bootstrap is acceptable to some. > I need some more explanation here. It will help if there are some > numbers comparing the two approaches. And is "completely manual" > identical to "one touch"? Or do you see gradations from completely > manual to fully automatic? "completely manual" means: attach JTAG to device, write K1 key in. Or, "burn keys into source code", deploy. If one was using one of the testbeds, that might be rather easy. >> In the biggest industrial networks, nothing less than a full >> asymmetric key bootstrap is acceptable. This is often due to human >> factors as well well (installers not trusted with symmetric keys!). >> In between are some networks where managing a large number of >> (hopefully unique!) symmetric join keys that have to be provisioned at >> the factory is acceptable. This is how pre-6tisch 802.15.4 networks >> are being deployed today. > The above applies to 6tisch networks only? I'm not claiming that the constraints and opportunities that are specific to 6tisch networks are unique to 802.15.4 TSCH in Industrial settings. I'm rather saying that these are the constraints that allow us to make progress without unweidly scope creep. >> We are doing this work in 6tisch because we can pin down a number of >> variables that would otherwise cause significant scope creep: 1) we >> assume a clueful network operator (or contractor) who can sanely >> operate our Join Registrar/Coordinator [which is in the zero-touch >> case, is a CA]. ---> this means our solution does not scale to residential or small >> office situations, and that is acceptable to us. > That is a very large logical step for me; small offices and residential > are small networks in my view. And small networks do not accept zero > touch? Probably, I misunderstand the reasoning. Such networks do not at present, by default, have clueful operators to run the JRC. If a JRC can be assumed (homenet...), if it can be packaged up to be trivial, or if an upstream ISP or service provider can provide it, then progress could be made. That's a lot of IFs however, and it can hide a lot of ratholes. >> 4) we use RPL as the routing protocol across a mesh, which forms one >> (or more) tree-like DAGs. Close to the root there are significant >> bandwidth constraints, and the convergence of traffic there can cause >> congestion. If properly provisioned, upper-mesh nodes may not suffer >> as much from energy, it can really hurt nodes further down the tree if >> they transmit packets upwards, only to have them dropped due to >> congestion, and then are forced to carry useless retransmits. As >> such, we are looking for solutions that where can coordinate the join >> process centrally, and we can accomodate innovation at the edges in >> the form of DoS defenses. > Coordinate meaning a central control algorithm? The RPL bandwidth > constraints at the root is a general problem. Can this not be separated > out? Once the network is constructed there are a number of observations. 1) if the network is for control (such lighting), P2PRPL might provide for completely different paths which are not so contrained. 2) RPL DAO projection could remove traffic away from the root. 3) a data collector (in the P2MP metering scenarios) can also do management of bandwidth 4) 6tisch includes mechanisms to allocate bandwidth for different applications via the 6p mechanisms, so bandwidth can be reserved and latency can be made deterministic. 5) 6tisch envisions (but is not yet chartered) to deal with a PCE, [such as is used in ISA100, I'm told] that could plan tracks across the mesh in a centralized way. The point is that we can't spend very much of the available bandwidth for join traffic, it would be wasteful and would make the impact of DoS attacks higher. >> e) we think that our enrollment protocol is ideally suited to make the >> introductions between RS<->RO, and C<->RqP that ACE needs for >> bootstraping it's trust model. > RS <-> RO and C<->RqP?; what is the mapping to pledge, JA and > Registrar? > Looking forward to the presentations, I haven't asked for time at ACE about the join process. I think this is a simple application of OSCOAP to generate a new set of keys. This is a partly open OSCOAP issue. I'd also like to generate keys for the CoMI (rekey) interface. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljSfL4ACgkQgItw+93Q 3WVcswgAq+yFqZVs+0Sr9bJp+1HLk+fwi6QZzgwLKXv89l6Nt4VavT7OGDMJIV84 J2jdSaZq9oytJUziyiyjCVXfdvLx3sHjPWnoqXgD9mSe5fNZh0FzRY4xRTcsUNFL JZYCQR7cBRog1n4Nk49BzQhYFoCvvk+Q/Gchi5NpujtF0zVv7nqt5hVTBHeYBsJb l4OaJW2mDf6NyOs9SYJ5iVWJnWfcZB9JSJVxtbhJeIBajt6cN5KSiX8jPk0Yrr6c SyTpEEh91WMpsXgCvCHNBz6dUQFlQtaoRJvzms2iY3TKPbIdEKs4ewcXaoVqZ97j qdsxAz041qfxdbdKkKz8rnxKoPhKuA== =I4y3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 22 07:29:43 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDE9129810; Wed, 22 Mar 2017 06:38:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , pthubert@cisco.com, draft-ietf-6tisch-minimal@ietf.org, suresh.krishnan@ericsson.com, 6tisch-chairs@ietf.org, 6tisch@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149018989569.10592.3782424673268985116.idtracker@ietfa.amsl.com> Date: Wed, 22 Mar 2017 06:38:15 -0700 Archived-At: Subject: [6tisch] Protocol Action: 'Minimal 6TiSCH Configuration' to Best Current Practice (draft-ietf-6tisch-minimal-21.txt) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 13:38:16 -0000 The IESG has approved the following document: - 'Minimal 6TiSCH Configuration' (draft-ietf-6tisch-minimal-21.txt) as Best Current Practice This document is the product of the IPv6 over the TSCH mode of IEEE 802.15.4e Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ Technical Summary This document describes the minimal set of rules to run IPv6 over an IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) network, including the operation of the RPL routing protocol and the procedures to forward packets using a static schedule of shared time slots in a slotted-aloha fashion. Working Group Summary Like for the other 6TiSCH documents, it took a long time and great care to achieve consensus on the security piece. Considering the complexity (and issues) in IEEE802.15.4-2011, the group decided to provide reference examples of how the MAC can be set in order to achieve interoperability. Though MAC level messages are widely discussed and many references to undated IEEE802.15.4 specs are made, and apart from a particular problem with the IEEE802.15.4e spec that has to be treated in section 4, the example section 11 is the only place in the document that has dated IEEE references. The rest of the document uses undated references so it is preserved through future backward compatible updates of IEEE802.15.4. The draft was the subject to an ETSI PlugTest and the Hackathon in Prague. 4 different implementation on multiple platforms and OSes were tested. Document Quality There are 3 different open source implementations, Contiki, TinyOS and Open WSN. Multiple derivatives of Open WSN are also available and were confronted at the ETSI PlugTest in Prague. There are also shipping products in the AMI/AMR domain (Wi-NAN) that operate in pre-standard variations of this work and we expect them to move to the standard version at some point of time. There were also discussions on how IEEE specs should be referenced; the authors followed the best practices obtained from multiple parties, including the RFC editor and the IEEE-IETF coordination, of using undated references whenever possible. Personnel The document shepherd is Pascal Thubert. The Responsible Area Director is Suresh Krishnan. From nobody Wed Mar 22 07:31:43 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FD612967B; Wed, 22 Mar 2017 06:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7azJOqDQgNLr; Wed, 22 Mar 2017 06:40:30 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C27129416; Wed, 22 Mar 2017 06:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2779; q=dns/txt; s=iport; t=1490190029; x=1491399629; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2yaybNPHIe3IQTxUF8TgTI7IJp5t3SMqgNEm8RgA5cg=; b=GLObvMJtA24wKeHjOTK1j5QP58WJEF53/ETD6mgoOXjF9ZmSEsDD8NN+ Uv6FWOI9UnyeD99MXjnac7jAVMCBpJyLLklIL8sxoAT8+YbqNXKnKNPnq PBwASLGCqMgTeUcDLGh5xq7KC/FxR8hLxbaClmazUSJzLgbc0Z/YOOr1f 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQAVftJY/4cNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1FhgQqNcpFilUeCDiqFeAKDIj8YAQIBAQEBAQEBax0LhRYBBAF5BQs?= =?us-ascii?q?CAQg7CzIlAgQOBYl8CA6saopAAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGToIFg?= =?us-ascii?q?WGBCYRUgzSCMQWQHowzAYZ5gymIJJEvk18BHziBBFkVUgGEfIFKdYoaAQEB?= X-IronPort-AV: E=Sophos;i="5.36,205,1486425600"; d="scan'208";a="397648390" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2017 13:40:28 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2MDeSrQ024677 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Mar 2017 13:40:28 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Mar 2017 08:40:28 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 22 Mar 2017 08:40:28 -0500 From: "Pascal Thubert (pthubert)" To: "draft-ietf-6tisch-minimal@ietf.org" CC: "6tisch-chairs@ietf.org" <6tisch-chairs@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: Protocol Action: 'Minimal 6TiSCH Configuration' to Best Current Practice (draft-ietf-6tisch-minimal-21.txt) Thread-Index: AQHSoxGQSEiGVQs6SUe7pRU9EkcVM6Gg3ZhC Date: Wed, 22 Mar 2017 13:40:28 +0000 Message-ID: <908A7C6D-A698-49CD-8C83-A0C74A5E48F9@cisco.com> References: <149018989569.10592.3782424673268985116.idtracker@ietfa.amsl.com> In-Reply-To: <149018989569.10592.3782424673268985116.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [6tisch] Protocol Action: 'Minimal 6TiSCH Configuration' to Best Current Practice (draft-ietf-6tisch-minimal-21.txt) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 13:40:32 -0000 Congrats to the authors!!! A long journey :) Pascal > Le 22 mars 2017 =E0 14:38, The IESG a =E9crit : >=20 > The IESG has approved the following document: > - 'Minimal 6TiSCH Configuration' > (draft-ietf-6tisch-minimal-21.txt) as Best Current Practice >=20 > This document is the product of the IPv6 over the TSCH mode of IEEE > 802.15.4e Working Group. >=20 > The IESG contact persons are Suresh Krishnan and Terry Manderson. >=20 > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ >=20 >=20 >=20 >=20 >=20 > Technical Summary >=20 > This document describes the minimal set of rules to run IPv6 over > an IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) network,=20 > including the operation of the RPL routing protocol and the > procedures to forward packets using a static schedule of shared=20 > time slots in a slotted-aloha fashion. >=20 > Working Group Summary >=20 > Like for the other 6TiSCH documents, it took a long time and great > care to achieve consensus on the security piece. Considering the > complexity (and issues) in IEEE802.15.4-2011, the group decided > to provide reference examples of how the MAC can be set in order to=20 > achieve interoperability.=20 >=20 > Though MAC level messages are widely discussed and many references > to undated IEEE802.15.4 specs are made, and apart from a particular > problem with the IEEE802.15.4e spec that has to be treated in=20 > section 4, the example section 11 is the only place in the document that > has dated IEEE references.=20 >=20 > The rest of the document uses undated references so it is preserved=20 > through future backward compatible updates of IEEE802.15.4.=20 >=20 > The draft was the subject to an ETSI PlugTest and the Hackathon in Pragu= e. > 4 different implementation on multiple platforms and OSes were tested. >=20 > Document Quality >=20 >=20 > There are 3 different open source implementations, Contiki, TinyOS=20 > and Open WSN. Multiple derivatives of Open WSN are also available > and were confronted at the ETSI PlugTest in Prague. There are=20 > also shipping products in the AMI/AMR domain (Wi-NAN) that operate=20 > in pre-standard variations of this work and we expect them > to move to the standard version at some point of time. > There were also discussions on how IEEE specs should be > referenced; the authors followed the best practices obtained > from multiple parties, including the RFC editor and the > IEEE-IETF coordination, of using undated references whenever possible. >=20 > Personnel >=20 > The document shepherd is Pascal Thubert. The Responsible Area Director is= Suresh Krishnan. From nobody Wed Mar 22 08:17:22 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25431297F1 for <6tisch@ietfa.amsl.com>; Wed, 22 Mar 2017 08:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=livebournemouthac.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hgq5Ig4ibpov for <6tisch@ietfa.amsl.com>; Wed, 22 Mar 2017 08:17:18 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0138.outbound.protection.outlook.com [104.47.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B099C127369 for <6tisch@ietf.org>; Wed, 22 Mar 2017 08:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=livebournemouthac.onmicrosoft.com; s=selector1-bournemouth-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vSA/4sa+tZyyyF7F05VRQzVCHr0jzFF0Z1K9QcXzhkI=; b=VyCgTZLc8IvdMc+H7ki+6akF1kxYbybIb+kmUUWjSytaJrSno3TSYN0oEXphmHwyEoc4SasPj+2UaMWeol3yaAHVrt+/ZiBL7rOuvF0Wcge7cKbiuferGViGIcByWLzkZ/jxD8yLt1bCOUKTIOHigRMqT8NudvUW8yek5313eOY= Received: from AM5PR0101CA0015.eurprd01.prod.exchangelabs.com (10.169.240.25) by VI1PR0101MB2158.eurprd01.prod.exchangelabs.com (10.169.130.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Wed, 22 Mar 2017 15:17:13 +0000 Received: from AM1FFO11FD010.protection.gbl (2a01:111:f400:7e00::103) by AM5PR0101CA0015.outlook.office365.com (2603:10a6:203:2d::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11 via Frontend Transport; Wed, 22 Mar 2017 15:17:12 +0000 Authentication-Results: spf=pass (sender IP is 194.80.70.242) smtp.mailfrom=bournemouth.ac.uk; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=bournemouth.ac.uk; Received-SPF: Pass (protection.outlook.com: domain of bournemouth.ac.uk designates 194.80.70.242 as permitted sender) receiver=protection.outlook.com; client-ip=194.80.70.242; helo=taw.bournemouth.ac.uk; Received: from taw.bournemouth.ac.uk (194.80.70.242) by AM1FFO11FD010.mail.protection.outlook.com (10.174.65.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.7 via Frontend Transport; Wed, 22 Mar 2017 15:17:11 +0000 Received: from Mailand.bournemouth.ac.uk (10.254.36.10) by Monimail.bournemouth.ac.uk (10.254.36.11) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 22 Mar 2017 15:17:11 +0000 Received: from Mailand.bournemouth.ac.uk ([fe80::701b:f751:f42a:b146]) by Mailand.bournemouth.ac.uk ([fe80::701b:f751:f42a:b146%14]) with mapi id 15.00.1236.000; Wed, 22 Mar 2017 15:17:11 +0000 From: Muhammad Akbar To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: 6tisch suitability for Wireless body area sensor networks Thread-Index: AQHSoxz+OP4RqZRi/0SgNUhcZ7s0Aw== Date: Wed, 22 Mar 2017 15:17:10 +0000 Message-ID: <1490195830574.16181@bournemouth.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.190.13.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.80.70.242; IPV:NLI; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(2980300002)(438002)(189002)(199003)(9170700003)(7736002)(102836003)(53936002)(23756003)(42882006)(8746002)(81166006)(8676002)(50466002)(36756003)(2501003)(8936002)(53416004)(106466001)(189998001)(86362001)(6916009)(5640700003)(54356999)(6116002)(2906002)(117636001)(305945005)(74482002)(2351001)(110136004)(3846002)(38730400002)(5660300001)(50986999)(47776003)(356003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0101MB2158; H:taw.bournemouth.ac.uk; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD010; 1:ATh3c8sK1E6ujtVlFKVxhLQ42UAE3DnfktHAN0hAz++I72z5NWtlcIe4ph2mxxCNoOgidu20zmjROHNCDk/8L4AFz8irmjdYWwNLHrOyD8BTfWIBJ2vb+lv5qY9suCmEb79HxKsKVAYMpBs2m5p2KbjeptWh8d7+XUpkXzYilY4f7V3ucKT8Q7HINc+hGSC+SVjoE7NK5ZLw0UwOtK7U9dX3GLIBEqoUzIkbMHtrqIHkjcj7cYFsAZsfBxeR59C7cFQTipICMbyf6WU1/3+2tbqvVY2bS+T4fKxBedgyiQCtHyB0z11XEARso5hj8rawAkR3GXL13wNY5JLjLdR0kQ107a37nlGCSOMje+peTLAb2GfTKUxrhXZeLFNuujodHaGrytjN9HYv8J7+3kOh5gemFNCweLsuNq00vXf9S5RyTWKY200ArrFMegoKc8+ADJr+l3B2ozJefx0jd6jqhQ== X-MS-Office365-Filtering-Correlation-Id: 292fb8db-6d15-4a03-4ce9-08d4713683a1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(2017030254075); SRVR:VI1PR0101MB2158; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0101MB2158; 3:13qQvcQ7aZcrPUpDQUtFKfRh86eqlocKcYrcpquSm4baCs5oQYchbEdGfXbykr/j2rnQrFV1y1TQ/FDaJ6mIP/rdchLIvsHJCcZisIStpSCDGOVJXyLcil1VRmZ696dxdhhzGS7vOqqE6qs191vrljEtzcWSbkedn5ZNVYoEB717tEkvOUYJcjBOOikvbyJw5Mt939nbZqlHXRXbGgiTCEkVoUKzV0ZlMdf7MCqQ7y8EToBUZ4bUprgSV57gev8xahakQIPt2nTEldNzu8VlMdAYjaYKFg7j/qpB9b7BUFSgjQ8eT5ykIW2B/aE8qQWQfypnaU/ZXwekdBzeZX2JNkzCQuk5lTpc9YJlkFIXZXeDO14pN5OUEuOfJjAMShr9F6piIqkBNYpzzJO7dJWrPD65wHMvz/uoXidfkf5qVfc=; 25:WbH6HT737B/+0nZ5yNi52DgFi092VV+Nvpx1mwfekpN2CozheYaQHvbmsOz6tB2l4qxh7/DEJ1X+XyF1Cwc7cXx22ShajKPw3C17IWeQLV3CvLbK5En8+TC3Om22LBrMy9WDieeee6glGzsb5J9YeKCuREMAUk/sH7chY0WO5zZ7OCKvX5DME2Diq0vCf40Podsu02T/SNcZn06dQzkHP3yqhH5DFHBaat99aA5qwWzWnopVF1NIWLWNjiQcViQZ8IuqNHk2RIsHFQKHtCdDrjZIpQVLH1cz6p+EvDErmaMQOoTxo971/i+HLD09UlNd3SMf1qAzt8oyL/9mbwU+yE8Yis9GgUOadz4PJUYrJqdMNYloKH2Ld5iZDb1Q7SGCBlMyP7J8TYlxH3ZjitTOGqWTpetpl1QfbIZFiXDVgtiHe1Mm+DaujSEJn1mA+SYH/hBv8qCwl99hQsBNVSSbog== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0101MB2158; 31:owc2rxoZew3KcOHXYEEBgqHjYXc+OC7dHfeqWNa/Nr9pcbuzbo7sy5NUFmFzPe4a+B4kMqsr0a3g61h4WU8IZVPrqsmkJfVlwdEeLnLiBCBnTI08OUyadjafmdDUN8gyTYdEj7L/DqzTXv/hUfRMOn3oGVADU6rnrySaWFQH8eW9i4mRv/I9la2VT0KdPbWlwKeqj45iXb47mWh3SNZTzeEAkmzqkC2zMJOWN4yD7Ste5gJF1PbO7PiEhomegP65; 20:kx5vMc/64qUO+La8g3dvQCXMIrz14wWXyBA9LgHFMD5w/abeoAdRrpqP5TOs4PsfJ/jGko5SbD7yUjCyyXTttiBP7Nzaa2t7o15D4gMkJfwminbB1t/B7qvsPMpx7GxfDQ75N5QFu69LuFijTyL1huFV1NCCWLVZjqtMuP/Nm9sT2ksTHv8Ax/iacegaSqP16XIHLaRMQxcACmT7dRN1dzKT/lunY8bQC3oD8Qf+VEI6JdIjhopYiYxPFmdOCrHb5wqs3RNn5xydCVCS55sy08w2Ij8vnxw+E4lwRB7/0UOhuqb2UOTjrdYIb6Er4EKB5Qed64THpWgyfRQTbkhZCnNBA3BxnHh3o0pSLMDd1vAfm/DvR96qb+AmlVjFRYqW4A4/w1Vtnuy0KZqI51rRDMdCqU9EBsf7tP3FGd6oonrBZ4S+7h4w6MNNJXxSRN+IVKB0BDoWcdi6ZI6tmFnDLp+yAyP7ug8u7bx2bfoMbuKrmbHiGh5FVTD5ZwQ/Z4fJ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13016025)(8121501046)(5005006)(13018025)(3002001)(10201501046)(6041248)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:VI1PR0101MB2158; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0101MB2158; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0101MB2158; 4:tzZbmARLivkPfSMCrs/HyWf5uGPR1HPbIhJNbQWu/LD429q+PZeVcNN2eHpVPrqZOWCFCH7MuYOjzRxN3el8gj4K+dvRETbx9lqY2afj/KHFxsXTAuZ//Rqnz2RuzMhLpHnaxgQ5yn73B+6im3bcxWDfbKDpRa3muQWwT3uadZ1bSlnZnyT6Dp6xTpFimESC2AeHXipQmkfkFJYsq4VA/HC6LOTBOhocU10pA+h9JYo6AoMwcN2liK21G1w7lCfNQ3NMBr+vpeYWEROQfS/F8DCcfogozGmH4VcHycSIt7Hwje+Cb+CCsqurMjv62f6kCKi2SJTDatRws5npiAXVKm0K9t2niVpuZo4BeQI5bs67NupG3ZUDN8MkB8bu2dzgNlG29vSEO1Deb+uEZGKHlUDyHkleYTWWVwkUeX3qLDDihmzLi8uYbHQ0dCkJKHG9t2hlaVupIdZxhVn1yJHzMm4GLsvoInjZDQtpex4DHPGeTeVz98ypAYDtA28sTBJJQFkQxCp5hsCb7uZN2mo/FLWDGBEitUtmRH5CrYfiscf045HwJ8tktqTTKzOl+OGNWxwMWTzsJmDjLhGpcpHFG97qQxezXHYpAvGLc/Gpv+JzJSPe5mPkQOzd7uPmKiEpvOLb+whFn6M+ja5yW1Yr6w== X-Forefront-PRVS: 02543CD7CD X-Microsoft-Exchange-Diagnostics: 1; VI1PR0101MB2158; 23:/qjkPzsP1RWi1aTZvc1zeJyNRVivRndeKaGSGjvoSR6WQ9hUSD9cRiNHp6Dacoeo6NZJlrxCjZ7oyt/mJYoREey/BlgjeC5i0pb7brPUqQqYskMhyVcV+HoSzc/nvKh0aKNMR+i7oh3wuMLSOD7CTx5fuV0g4r8C6LQyGBjKc5IGSkTI5W+jMWQZfIYaeCyRzRwjHWaG/FG8vNDHNRdphywLsr36viFrAYVVtS4sFigMKOTTZw0jfC5unBFoYX1qchyAtsVM6ICy801MwIOd1yspcLxGMOaMa23zHaCnu3A7DjDjWDSZYmx0qTZUytDvPuAUMksf9eYJQWvt4bf1bOHvbamav6lkWbJMlCq+Y9WrBpORLe78g9+yusFFbXiZ9xKTxSUNc6cc5gk8AIKAgfdGtZ0hzUxbPIdDsrdz6FoiDX0spEts8WKNuFpsrAGWgPb+Gw0rmdMntvdTLMYgIq2mLxP8pyd1Gb69B3s0rX01IMm+7JZ1a3cb5DeGD4aEn4G2XlBVA3fbXu1l3Ry9F1jOGsJamNFO9vwKZjWzGwv19vi8mz3+G5L5a+4uVzErEY/QCmEfef1RZKUBKZRF8BgcCZMNoMspi+R6CwqxCHrZoxmVOjf0SfQPMbom2xUo3CQbG/fmzl0Bh7+j0bTldFN1/KUYFgqkxcPHMd5Weth575hXGOPU/C7vzu/Ye+xRKRTMoDhBT9/35I/5hJyDs8suaHcerkLDjaQRlLMtWpQHfIAlNzl0q345ELf4Ng4u2vi+RfUlRzt3MYYQFCh2DWhsyOFHO41B9T9CzqR6qJD41dZ1zm2FPEV74NBEpDnHWp/ZOiUUR3CTYnDOgIC9rGLwMnX6b0Ilahfb7SAbuawrQJM9o9ijGlPVjdHF95V6BM5CLxJUbv7eyuKLT8+KUB88i6Q8Qa2iQzsnBezFSxY7lDeNJ2N9iRDvp5X49xwz X-Microsoft-Exchange-Diagnostics: 1; VI1PR0101MB2158; 6:AiqXiRR7QLwwoXG422LBILoFGrZsf8yZAmt2xtyLJsIPmqJjmHHZvn2zOl8I7ldMwqzEbSKbLAOJmMmIGO49bFu3XwYremVbJuvPZCuTo9E9yWIw5Va9s64IPwQDHaDqD5Tx6dnYO64P2sjVz449o6OZPshTmkLNaWKYoZfsiap/GxzKvSnvMEOV8ter6NOVUfZ0MtLCybHx07PGq/XUc6f/otD9/0f2kWDuicD0mCHF5UcaTlLLAa9WQsKWe26bsh+qGpptpiNirzpCpPH1mdh14sfxMuWSv9h1A5AZ2SfUKlqDw5uRVn315ssa/kqPhZrKt3FyPGSUg3suwKCiMvbaoy0qkN3gVYgPl2zmLI0Z5Yd0dPoVpuxjktH6b9ocysk3KPu+y4y6q+PneShQ9w==; 5:Hq4xSQI2zUnbXckq/1+ZGo6c52GTPwkqvxqcjlrfEe5qQuDPG7zQf7cx4eEWnNPxv1u/zIohFbebktqrUT6qkcMo4PVf9hcS2ZaDdUNJUICMujcL8PDrWEcOr922YJ6xXvSunFRtH3d5hszNMar8FA==; 24:Fj/FV0xmhs+tp1f+Lfi+FtinpI9JyEbaWqRp0uLmgqEtAYHuB7V2P0EoC4JmzGTYYW3ImSMK4yQo7mrwEe3Q6Veyhubd3+LE0W9tB2aSsOU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0101MB2158; 7:BsO/MF+3x3MNrbY6z2jmlcuhXYpwp2mT4KN/pdidz9lo3m31rYrLkis5y1DdITO3rXYAudkS7uBxGfkM6I63JO6rzFE1nHt4dn+HgMVCyqNp1xokrTxShPmm5Iq/QXXnmIcOd0EU0pMh+CPM77yqMYiXvjQrCDIFWV0EyEN/SZBeRF67NzVPwBtZRiBeyvVH7Cg+B/vT3MQ7vjzbXuV/EKndSEY3pSO6cmm3Ke26hymqUvLCo5aaaej/t9QFHbkSdYTUmot9VFb/O4VxWyw+Wn0YFrtNfBzfaNQvovA5DG0eGhh17xOfaeKWE6NGklYxkrel1itD6LbLNwfwFRDnBA== X-OriginatorOrg: bournemouth.ac.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2017 15:17:11.5705 (UTC) X-MS-Exchange-CrossTenant-Id: ede29655-d097-42e4-bbb5-f38d427fbfb8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=ede29655-d097-42e4-bbb5-f38d427fbfb8; Ip=[194.80.70.242]; Helo=[taw.bournemouth.ac.uk] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0101MB2158 Archived-At: Subject: [6tisch] 6tisch suitability for Wireless body area sensor networks X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 15:17:21 -0000 Hello I am a PhD student in Bournemouth University UK and my thesis is related to= link layer technologies suitability for WBAN and connectivity issues with = IoTs. As for my understanding, TSCH/6tisch targets only specified industril= a application at scalable level. Moreover, its power utilization mechanism = is almost same like 802.15.4 channel access mechanism. Do you think its val= ueable to make a usecase of 6tisch for WBAN? Sajjad BU is a Disability Two Ticks Employer and has signed up to the Mindful Empl= oyer charter. Information about the accessibility of University buildings c= an be found on the BU DisabledGo webpages. This email is intended only for = the person to whom it is addressed and may contain confidential information= . If you have received this email in error, please notify the sender and de= lete this email, which must not be copied, distributed or disclosed to any = other person. Any views or opinions presented are solely those of the autho= r and do not necessarily represent those of Bournemouth University or its s= ubsidiary companies. Nor can any contract be formed on behalf of the Univer= sity or its subsidiary companies via email. From nobody Wed Mar 22 09:40:49 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3CC129B37; Wed, 22 Mar 2017 09:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_84fp2IINk6; Wed, 22 Mar 2017 09:40:45 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9C1129B52; Wed, 22 Mar 2017 09:40:11 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id w204so874743wmd.1; Wed, 22 Mar 2017 09:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+nw0WSCyE5o3w7ongDZy2i0EA//PN2tcXoRf5cQg5Uc=; b=nzkrPWwHgKIesBvQ+7Ck/T1WfecH3AB0EIm1Ge/WT8f0CYLJ7gapRx5kuh8+0qBb1p TZ1B2o+KzUa4fr/NoF0uG8nuLjBgZi0WMp6q0dbz/lFcm4TA2f6fpHtBg4XzdaKJ9G4s sstMaG6Fvn21B0awGogm8Usskzo0bt+0rL+ipkbCX281hlbLdNIiYelpP4Gs3dWfszUX WItVTEXVcw+MowlNgA5HgB6aq2Ax30ObFazwWlqYtoU050iKEu/8POlxtZs1+bu8/dhB sp/YvO8WGobxLB2cFUYI1OwjuyKpA7bHYt3zwSNJ6oiocKF/FArP8l7Wp9PjQ9tkMtQU tPVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+nw0WSCyE5o3w7ongDZy2i0EA//PN2tcXoRf5cQg5Uc=; b=ic2xfhiNKepDs5PgBqKqnOSrhdAQc4f7ZxeDV6U+QTdXAuK+dVlEIkMIOYpH9qMVfA 3ttgl9nT9o6eOyyfazoemLk0wJx9i6CTdh3pHsJyeRmSgVgDirveQtCF/DX/U5vwdHlt gGKAy1PPi+OIT0CYyujsHN8fspkFCQGICjb/Ou03Oh/hBUytJSf/0yqMOfabAdQQw++y eV2gUn5NqUURoKkwgqalvFp99QkI+zJ1WPnObQv5/XI2ir11okZs8XWYkzu7N4UZNnrn agpH8PDBWxpXcQ82xPOKwxukPnAcTOuF9OLWrFYfpIoiLBQWRm9CRVIzPjR6XRC4Hzz5 a89Q== X-Gm-Message-State: AFeK/H39d5BShR7KR9rN4dwgpJhdHOD+VIr62xGFJ0e6CNpgMyIY8QsLuuFtNKym4sLS1uas/g/AQIAmtIG14Q== X-Received: by 10.25.181.73 with SMTP id e70mr11382654lff.98.1490200810026; Wed, 22 Mar 2017 09:40:10 -0700 (PDT) MIME-Version: 1.0 Sender: xvilajosana@gmail.com Received: by 10.25.20.200 with HTTP; Wed, 22 Mar 2017 09:40:09 -0700 (PDT) In-Reply-To: <908A7C6D-A698-49CD-8C83-A0C74A5E48F9@cisco.com> References: <149018989569.10592.3782424673268985116.idtracker@ietfa.amsl.com> <908A7C6D-A698-49CD-8C83-A0C74A5E48F9@cisco.com> From: Xavier Vilajosana Date: Wed, 22 Mar 2017 17:40:09 +0100 X-Google-Sender-Auth: CksZr-OSlwLzvT1lcfKbv32gDvM Message-ID: To: "Pascal Thubert (pthubert)" Cc: "draft-ietf-6tisch-minimal@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-chairs@ietf.org" <6tisch-chairs@ietf.org> Content-Type: multipart/alternative; boundary=001a113c4414ecfda4054b546920 Archived-At: Subject: Re: [6tisch] Protocol Action: 'Minimal 6TiSCH Configuration' to Best Current Practice (draft-ietf-6tisch-minimal-21.txt) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 16:40:47 -0000 --001a113c4414ecfda4054b546920 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable great news! all this started back on 2013 :) X 2017-03-22 14:40 GMT+01:00 Pascal Thubert (pthubert) : > > Congrats to the authors!!! > > A long journey :) > > Pascal > > > Le 22 mars 2017 =C3=A0 14:38, The IESG a =C3= =A9crit : > > > > The IESG has approved the following document: > > - 'Minimal 6TiSCH Configuration' > > (draft-ietf-6tisch-minimal-21.txt) as Best Current Practice > > > > This document is the product of the IPv6 over the TSCH mode of IEEE > > 802.15.4e Working Group. > > > > The IESG contact persons are Suresh Krishnan and Terry Manderson. > > > > A URL of this Internet Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ > > > > > > > > > > > > Technical Summary > > > > This document describes the minimal set of rules to run IPv6 over > > an IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) network, > > including the operation of the RPL routing protocol and the > > procedures to forward packets using a static schedule of shared > > time slots in a slotted-aloha fashion. > > > > Working Group Summary > > > > Like for the other 6TiSCH documents, it took a long time and great > > care to achieve consensus on the security piece. Considering the > > complexity (and issues) in IEEE802.15.4-2011, the group decided > > to provide reference examples of how the MAC can be set in order to > > achieve interoperability. > > > > Though MAC level messages are widely discussed and many references > > to undated IEEE802.15.4 specs are made, and apart from a particular > > problem with the IEEE802.15.4e spec that has to be treated in > > section 4, the example section 11 is the only place in the document th= at > > has dated IEEE references. > > > > The rest of the document uses undated references so it is preserved > > through future backward compatible updates of IEEE802.15.4. > > > > The draft was the subject to an ETSI PlugTest and the Hackathon in > Prague. > > 4 different implementation on multiple platforms and OSes were tested. > > > > Document Quality > > > > > > There are 3 different open source implementations, Contiki, TinyOS > > and Open WSN. Multiple derivatives of Open WSN are also available > > and were confronted at the ETSI PlugTest in Prague. There are > > also shipping products in the AMI/AMR domain (Wi-NAN) that operate > > in pre-standard variations of this work and we expect them > > to move to the standard version at some point of time. > > There were also discussions on how IEEE specs should be > > referenced; the authors followed the best practices obtained > > from multiple parties, including the RFC editor and the > > IEEE-IETF coordination, of using undated references whenever possible. > > > > Personnel > > > > The document shepherd is Pascal Thubert. The Responsible Area Director > is Suresh Krishnan. > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > --001a113c4414ecfda4054b546920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
great news! all this started back on 2013 :)

X

2017-03-22 14:40 GMT+01:00 Pascal Thubert (pthubert) &l= t;pthubert@cisco.co= m>:

Congrats to the authors!!!

A long journey :)

Pascal

> Le 22 mars 2017 =C3=A0 14:38, The IESG <iesg-secretary@ietf.org> a =C3=A9crit :
>
> The IESG has approved the following document:
> - 'Minimal 6TiSCH Configuration'
>=C2=A0 (draft-ietf-6tisch-minimal-21.txt) as Best Current Practice=
>
> This document is the product of the IPv6 over the TSCH mode of IEEE > 802.15.4e Working Group.
>
> The IESG contact persons are Suresh Krishnan and Terry Manderson.
>
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/do= c/draft-ietf-6tisch-minimal/
>
>
>
>
>
> Technical Summary
>
>=C2=A0 =C2=A0This document describes the minimal set of rules to run IP= v6 over
>=C2=A0 =C2=A0an IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) networ= k,
>=C2=A0 =C2=A0including the operation of the RPL routing protocol and th= e
>=C2=A0 =C2=A0procedures to forward packets using a static schedule of s= hared
>=C2=A0 =C2=A0time slots in a slotted-aloha fashion.
>
> Working Group Summary
>
>=C2=A0 Like for the other 6TiSCH documents, it took a long time and gre= at
>=C2=A0 care to achieve consensus on the security piece. Considering the=
>=C2=A0 complexity (and issues) in IEEE802.15.4-2011, the group decided<= br> >=C2=A0 to provide reference examples of how the MAC can be set in order= to
>=C2=A0 achieve interoperability.
>
>=C2=A0 Though MAC level messages are widely discussed and many referenc= es
>=C2=A0 to undated IEEE802.15.4 specs are made, and apart from a particu= lar
>=C2=A0 problem with the IEEE802.15.4e spec that has to be treated in >=C2=A0 section 4, the example section 11 is the only place in the docum= ent that
>=C2=A0 has dated IEEE references.
>
> The rest of the document uses undated references so it is preserved >=C2=A0 through future backward compatible updates of IEEE802.15.4.
>
>=C2=A0 The draft was the subject to an ETSI PlugTest and the Hackathon = in Prague.
>=C2=A0 4 different implementation on multiple platforms and OSes were t= ested.
>
> Document Quality
>
>
>=C2=A0 There are 3 different open source implementations, Contiki, Tiny= OS
>=C2=A0 and Open WSN. Multiple derivatives of Open WSN are also availabl= e
>=C2=A0 and were confronted at the ETSI PlugTest in Prague. There are >=C2=A0 also shipping products in the AMI/AMR domain (Wi-NAN) that opera= te
>=C2=A0 in pre-standard variations of this work and we expect them
>=C2=A0 to move to the standard version at some point of time.
>=C2=A0 There were also discussions on how IEEE specs should be
>=C2=A0 referenced; the authors followed the best practices obtained
>=C2=A0 from multiple parties, including the RFC editor and the
>=C2=A0 IEEE-IETF coordination, of using undated references whenever pos= sible.
>
> Personnel
>
> The document shepherd is Pascal Thubert. The Responsible Area Director= is Suresh Krishnan.

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

--001a113c4414ecfda4054b546920-- From nobody Thu Mar 23 04:04:36 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED8D1296B7 for <6tisch@ietfa.amsl.com>; Thu, 23 Mar 2017 04:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=livebournemouthac.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyTio1I5cyh9 for <6tisch@ietfa.amsl.com>; Thu, 23 Mar 2017 04:04:31 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0111.outbound.protection.outlook.com [104.47.0.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844761294D3 for <6tisch@ietf.org>; Thu, 23 Mar 2017 04:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=livebournemouthac.onmicrosoft.com; s=selector1-bournemouth-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Do95w2IcAS5ThiMBZ+T8z8/j3gKZc2P1fddOeryx3ig=; b=FtzgxO6OUM4ONGmC47PfhK8f4bf+fxfgvzbZl/P4XHkjs7gDeUAnoP8ntydBO/+1c04sFd87Xw7o9Qq+DvQHIXC+LFs14yARjeaWtnnVZrLGvOZvB4TE/wwxCC/b9p4vFXHelCR9Pm/giTrUd6RPRuyW/CTTM2cEjRQxUxYEai4= Received: from AM3PR01CA021.eurprd01.prod.exchangelabs.com (10.141.191.11) by HE1PR0101MB2153.eurprd01.prod.exchangelabs.com (10.168.29.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 23 Mar 2017 11:04:27 +0000 Received: from DB3FFO11FD042.protection.gbl (2a01:111:f400:7e04::125) by AM3PR01CA021.outlook.office365.com (2a01:111:e400:8828::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14 via Frontend Transport; Thu, 23 Mar 2017 11:04:28 +0000 Authentication-Results: spf=pass (sender IP is 194.80.70.242) smtp.mailfrom=bournemouth.ac.uk; ece.iisc.ernet.in; dkim=none (message not signed) header.d=none;ece.iisc.ernet.in; dmarc=bestguesspass action=none header.from=bournemouth.ac.uk; Received-SPF: Pass (protection.outlook.com: domain of bournemouth.ac.uk designates 194.80.70.242 as permitted sender) receiver=protection.outlook.com; client-ip=194.80.70.242; helo=taw.bournemouth.ac.uk; Received: from taw.bournemouth.ac.uk (194.80.70.242) by DB3FFO11FD042.mail.protection.outlook.com (10.47.217.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.7 via Frontend Transport; Thu, 23 Mar 2017 11:04:26 +0000 Received: from Mailand.bournemouth.ac.uk (10.254.36.10) by Monimail.bournemouth.ac.uk (10.254.36.11) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 23 Mar 2017 11:02:56 +0000 Received: from Mailand.bournemouth.ac.uk ([fe80::701b:f751:f42a:b146]) by Mailand.bournemouth.ac.uk ([fe80::701b:f751:f42a:b146%14]) with mapi id 15.00.1236.000; Thu, 23 Mar 2017 11:02:56 +0000 From: Muhammad Akbar To: "anand@ece.iisc.ernet.in" , "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [6tisch] 6tisch suitability for Wireless body area sensor networks Thread-Index: AQHSoxz+OP4RqZRi/0SgNUhcZ7s0A6Gh0a2AgABtqwQ= Date: Thu, 23 Mar 2017 11:02:56 +0000 Message-ID: <1490266977684.80959@bournemouth.ac.uk> References: <1490195830574.16181@bournemouth.ac.uk>, <50749382-e60b-4eda-7b02-b0cc06c8c602@ece.iisc.ernet.in> In-Reply-To: <50749382-e60b-4eda-7b02-b0cc06c8c602@ece.iisc.ernet.in> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.190.13.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.80.70.242; IPV:NLI; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(2980300002)(438002)(189002)(199003)(51914003)(24454002)(377454003)(9170700003)(53936002)(106466001)(6116002)(229853002)(23756003)(2950100002)(76176999)(7736002)(2906002)(38730400002)(356003)(2900100001)(42882006)(305945005)(53546009)(36756003)(6306002)(5660300001)(189998001)(53416004)(50466002)(5250100002)(8936002)(86362001)(8746002)(8676002)(102836003)(6246003)(117636001)(54356999)(50986999)(3846002)(74482002)(81166006)(47776003)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0101MB2153; H:taw.bournemouth.ac.uk; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD042; 1:w4jkUGAaovfb28UzLvvH5dSDiE2/u2l3dZRdoydxsLIYgc0EmpM+6pSpHvzDOAueYLCGlDBQA7XKTVQnFUeGkG6CcgWEqQJHDfTo/w5sRv4QOJIYAv6dIs/s1MoSVmjr4i7FPknyzeCpjRn0XniuoSR+4uywc/hTV/QCbtb8uUQQp19tcBVHv2YF+aePFHsVkCzmzs3NlN49MttCCrUHKN9dHtg/km9tPig98piUUa2C4An2DREvrUpwnctstWcbLQkOhVk3onjHOW7P+IIiYZPDOck4MUdSBLXnlwT2r5bD/4ppsbedGfJ6TuAtLeLuOIJTrkyRTTxVbdlG0oE4SJlMwU1MK9JKCSr/TzfleAnJt5/XgLlgvGSDdUpHX2ckSP5IJeppvEjWFWHpNiRTpX/E39AH/j3Dy+dgHePFfDVryI0erLwpTNTdJ9bnfekAbrnN3gSkEODuiB7dgbyM3Q== X-MS-Office365-Filtering-Correlation-Id: a1205479-295d-48d4-8c1a-08d471dc5ef2 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(2017030254075); SRVR:HE1PR0101MB2153; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2153; 3:SbDDUyVfllXLmz6NXjOA1mrPxlbdSXYakFcaUXFws0DNhgoa2zbJ/1benQC9aJU9gGrZD2t0RgTAQQ+RTrti/SpN640SmCVUnZLa72OaXRC4NkEwy50vn78S+52rgqRIzS4GZB9GgoVDHppksThDLEnDuCVqyVZobv45FLkEwHMWWUJIA5zEfInSTsnyxS/wp5g1D9ILJ3cBrMFZsctOdpYgrSCIwtWVFx3diVetf2H/eiQb0KllgWFsmK1f/jqkCb0y84l13i7AjNSYgHo+Dn84LYqkVrag5CYVmg5Vm7+f8oPZa0QbYd1/b+I2ytOABY5RD54M4+eqjPepnsR2DS3kDEBGYlSzeNIilGAHXLeGdXVmjKOapqITD3YcA0lUDzYSe1pSHiCtncj78BVRPDyNtcTiC326501zfVSHR1U=; 25:d2Yme0cm5E8kx9LRu4s3rMDRvJOE17FBLEHCbcr25RrKg8W7KgR055fkyejrAvzDJQVG/LPX6GmMXYpVov/Tq95fvP+4tyldBcAqg+NnPEJ8lJ7+2E5dAHPirBo6WlBPfv4rnKVLTcTO9gLaN6Zy8uB+2AkrXIMOKCfx5cAJJWokyZS/W2TwOLJ599LXU8MwI/QsjXQlZn0OBbAWcDyQAqumfQZm5+YOZcGbgoxPpol8OiTFb6tKM4OMeXecuEl0kvW/OwuOiyYLe1ye3s8Fo60wE+Apps5mQ7q4DVGs3y15WGErDSsRlUXTchwRKAp3475J+lMgp2+ZCe3MwCbC8OYZbmLMnVp5WYBQCkT0a+l1WwVjnPIHVPp3dPnkt8uHs7wtsAg3acVh0SKqaWIvmVZ0Wm+gH0anESELWLapJg+7o7CQ91aa8E26QTEmoyHt5tDFUOjuYwB3NfcTu5X5Zw== X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2153; 31:GcavcBKqSiYUQrBiDjbZyoNvGxixjiDEje0Ejj1ortiPOYKLZFSg7IfbJVgllXOhqd/wvLu979JCPQMUgY+yDZL2vYwj0C27QGNaWsPP5x/okehfsZ/KAAr5Nq7omcA99hgsT5DE1yzYqA8XvJRKkbJmZnqmk+SosmUKzFymGiI+ZeBDCcXWirqQN+Fl+DzYmZQoIFWYMdCxlIfJBOOp8kmF/ZqSpOyFDTvG9NiHkxTZ0rlbno1q9KsTjJRa0Kl5jEDnZlRG9Rz/7ejxDJpP9w==; 20:nfC/V2Dl552zHsjPsugrjDmaRJm0Vw31Dt9YMUm41yeJYp6Pd0HCGDF7bxUITb9zhOh7pcq5tFx2GYE3ayjujlhmAY1txR9CzUFFbZRVXqNKrBG5DVk0gODTed+6xMxDdLfq3QnAvv0iy8E32GHsHU71YljPq1S9fPiLOPXAwbmKMW+nN4y6z2cqWA2LaN4xPB2DMBeCQfDxLursAULMNuMJFwfQNxjclvBgA8T8dXfOW2NbhTcRB5AVJlcHi/Vqc3zMp3aIy6jz+VttU7dxZXukr4NVUcULEQ3UKo01Eh2BJ/2nfESmytft70lRf/yCj5FU9UJIbscx8LvKoexilyPSSrUVywFafsJJzqYH1vgfO4JGrAxxA75oXmr1L9o6stj+yTqmIBjNfOazKLB937hrbKMs73sKd3lKwPzBEZKeNhAfLkyvxmaQcjw3yNsVh8eEzv/TQZgTYq2W3jlhGTDCbFY6+jekEsCwNzwhb7aJzTTd4QZYaJHT0dbwN5eh X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13016025)(13018025)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(20161123558025)(6072148); SRVR:HE1PR0101MB2153; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0101MB2153; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2153; 4:4UHp1baccQPLx+cxYfD5rKLlEiHrCijpks1UgdQDaIFRXpF7dzuoipBHSN7GtBEUaxHnKlJYMCqDwl3GkG/U78Hf6KQc8+jZTQjWt5o5taZLiM5OQ4zvwmGWSeZZ7FIIT05UsEMAwh3f1szcuyl7uz7Izfo9C61DqgmM3q+gJ2mLT6pTz2gJtopEkyABYpBi4DEze2MjY53jCUXzRKra7x3nI5aDFlaRMC2y10ZqGElxyUG84peneAyXmMOGnrLLH4t7em0DCcBCRfNTRryVljro4xrvW5VercSMh5cv4piYw7DoBwCnZS76gcUgGeBkoCZxGeaBstTZqr1TgBSiysCdb2RTWnvRIqLrmyUZAcNvMKrCaIQD2Ylih0p9IKzMZEzi+Zy+vRFzBBeNyTk9X/3hyZuXc39+5ExQu985cywrXma2AsYN1WOJNX4KL3+/iRTwUfUO+mo8AxjKy6rzhzYwUl4G/Ughu7RaDxsEq9Ko8384J2MC5fen/XMkyQB4r7aTBf0IW3YcbcbdK6NUIq/q0niGgWmshuoEEeH0KzAlc3oR33uvVMDmknGlJr+pI/a6P1i3jOm63b5g8dj9NPgf+s0hh1xgA279GcOa2SzsmEiAMq0kGKZjRfmG2iFkZzxoiLboj/dnCrm2eZFPww== X-Forefront-PRVS: 0255DF69B9 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0101MB2153; 23:KGGhfMPRM1EqYmywspvxgFPQsL9bEi5wnfIPe?= =?iso-8859-1?Q?K4chC7XtcUdZP9MFVAFYmVTrDFOaXiVP15pgpy3y46k8J4aVzHPPZwCEWt?= =?iso-8859-1?Q?wjwv1ykHVl0aLKJQ+7tEf2Fu7RNLHZbbdFVv/xJyY+7g5mbXE8Sk9B/tTE?= =?iso-8859-1?Q?h6fjJYV0B5KMu0M46Fbug/nATwC4C7CcvYmaBiGCX5fsIiLe53S5KG1TU0?= =?iso-8859-1?Q?Cosp3WfhDot+yRGMmpD0zageT1OWTECvzM/BuvKtFfyzF7tDUMrduqDXYU?= =?iso-8859-1?Q?ZU4XqJPHc/RCUre9ghn0vpUV+7z7e0C5B9O3PhD5eyhCSX7K3Rj40D0B6C?= =?iso-8859-1?Q?JYjevSHs6M8YzDWTeK/qtxhrS5zphnUBfW2S1L7kCYmw7MI1aJIsQWk6/e?= =?iso-8859-1?Q?T8+Pb+Meno7+LplR+A2FzkrTDYkiwfz/K5INKpZTNorZB+FmEhSZ91tf47?= =?iso-8859-1?Q?nCrRfufnKOdte4cfHalXteJOK6FoanYKKjJ08FqTOlstoOPCqBCx8JbG2V?= =?iso-8859-1?Q?CzyCSOM0ylCHvkCVfOhHam7xEV8NnOuJzK3mFLG9YxIqd2/F2oB0Vy1XjN?= =?iso-8859-1?Q?Eo/PcvU7czfaChx+dPPxLi4+fY4G5kHr+WPj8Kjf1t7rd+CA1K4KAaNK2D?= =?iso-8859-1?Q?wyS23QJivxl3NWBv+xi1KsDcnEv3UL7XfCFI+t2WdcfjBh09x7Pjbn+4jL?= =?iso-8859-1?Q?JymfcIuiDO8+YRss30zGTUSZU6Qt6YNGNolHzk6SozBBUgxu4ekE4nzXTk?= =?iso-8859-1?Q?JWM4akygl3O3vGK49SNcylhMnoKv7aPnJZuQmv/04ZZlHJaxDDFz0fVXOY?= =?iso-8859-1?Q?YeHoP92uGrX2O1VeJyWOAXnGdFskFlTdYk1t4A7TmIY83s82md8Ql7brr+?= =?iso-8859-1?Q?KkH9I5drg9f4J9DseqzS7FR3NUumxGdKjbESxFd3qQbjidzsuhTEBtmuxZ?= =?iso-8859-1?Q?PLmN0uZWIIiq4Hyt+EtBD6F+YcEOz/KB3PRjk1i3fOoZ0Pr72AkloKJvCf?= =?iso-8859-1?Q?hKKRaVGq0huWC+eg+6WAkj2oRq/NPbeEWwEOJneLBhCW91ngOg2HppIWmN?= =?iso-8859-1?Q?Cz5Z06ADUU5HqWm6FyQzlAGpSPx8bYEHpnI/Xp0QlD5DpXUNYBay7nmWK5?= =?iso-8859-1?Q?jWq+lq++g+1Xo7/G9mJBwgq9ojFEzi58iS1AV+n0R0zWIJSkSA=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2153; 6:bniGWuhaSGiV9MmudNlvswaLguxgmVuEcvifhnSIxbhoRYkIl+V1wSijG5rLfRZ2qiYWS8kn1hel81uFZSkClIwd/oTZZxNQ4lCltuXTIiL+k8JhklPdOhiNoqPogzI6Gul5eYZdqnLo9ecI0Y/Nkp9+gGFwdnoAsaEN1r6a/4GqTgoSf2O1nhS5gQp4Ehp1W/CTNuqi+QQFK5scmHB5paqg8T10k/wqoUN4tu8BlQNuRAJwClaPXOHX189u+p+c+s7uplqR5XUC3dDZyEq7UHDYncPunKo/LF2J3LarWY4RorstEjLejTXPty3dNBP8m89EqUoS3ylpg74dbvKotuyysoatT5QavZAWxUoLANICLUMNTpJnoTlkCm4r6Yr0syZiHrOjoWmQzLLKpH9GhA==; 5:vSmXcbLIGTa6iDWGEPWM5BG+89Jk53RRHjmaFgyeLIzljEmGbAULN4QF8/H+Z7QWgnQ9YXLX/4wQwGOwx2I1irCns3vIqfeGP76tWzFPvM/SFWuGpVcJiYdRuO3qO4bia9If/g1shIErtQVaNODNHQ==; 24:NtOcRBzxF9/0eTt/T6FfOghJ6/NSSGIVTZ/CEmrbXSGzLn6p4yZKD1L160ewCpPkynLNLZklSh2Xc4uYJX3TghTox8Ol2vDKaFZ6saAnP3w= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2153; 7:z830+8M9GAQgTyYl1LqBhIybQUc0Ned4rt1k8aQOPVfq+mH2nO3+aTbYj4QYNW2WpA8X9hYBW+Y/BUqlN1S10cLakGOUC+iU33zTXSX7sW2Y3Kc/npXx+eVS5w+EleS5eE0il4AkCJOpuyt9sKAD7lJu2JyPShkY7TEFuhsPyqh9NslxyqiHwQHUHvnys6bz7ON4hVmYYp9zMK5eE2mlYrRmohRznQWaUTxdyhimYkUjSqErj4imDgfNK215jtVAT8bgDwsvCOcDSeKqknUOzC27tfjpb42CxaW1Fe9BATX/63wYyavdtjdgi70eylRv0W77cnn7/rgb6t4kIx1TEw== X-OriginatorOrg: bournemouth.ac.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2017 11:04:26.4844 (UTC) X-MS-Exchange-CrossTenant-Id: ede29655-d097-42e4-bbb5-f38d427fbfb8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=ede29655-d097-42e4-bbb5-f38d427fbfb8; Ip=[194.80.70.242]; Helo=[taw.bournemouth.ac.uk] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0101MB2153 Archived-At: Subject: Re: [6tisch] 6tisch suitability for Wireless body area sensor networks X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 11:04:34 -0000 Hello Thanks for the reply. Actually, I am doing requirement mapping of WBAN with= 6TiSCH, the option of determinacy is a good option,however, the other QoS = factor like power consumption and CSMA/CA mechanismis almost same like in 8= 02.15.4 with 6LoWPAN. Specifically,in hospital environment, I found 802.15.= 4 with 6LoWPAN more suitable option. I will appreciate any feedback. Regards Sajjad ________________________________ From: S.V.R.Anand Sent: 23 March 2017 04:14 To: Muhammad Akbar Subject: Re: [6tisch] 6tisch suitability for Wireless body area sensor netw= orks Hello Sajjad, The problem you are addressing in very interesting. 6TiSCH brings in determinacy that is required for the critical WBAN application. What is challenging is the aspect of mobility which WBAN brings in, unless you are assuming the person is immobile. It calls for dynamic cell management to en= sure the required bandwidth is available as the person is moving around. Regards Anand On Wednesday 22 March 2017 08:47 PM, Muhammad Akbar wrote: > Hello > > > I am a PhD student in Bournemouth University UK and my thesis= is related to link layer technologies suitability for WBAN and connectivit= y issues with IoTs. As for my understanding, TSCH/6tisch targets only speci= fied industrila application at scalable level. Moreover, its power utilizat= ion mechanism is almost same like 802.15.4 channel access mechanism. Do you= think its valueable to make a usecase of 6tisch for WBAN? > > > > Sajjad >= > BU is a Disability Two Ticks Employer and has signed up to the Mindful E= mployer charter. Information about the accessibility of University building= s can be found on the BU DisabledGo webpages. This email is intended only f= or the person to whom it is addressed and may contain confidential informat= ion. If you have received this email in error, please notify the sender and= delete this email, which must not be copied, distributed or disclosed to a= ny other person. Any views or opinions presented are solely those of the au= thor and do not necessarily represent those of Bournemouth University or it= s subsidiary companies. Nor can any contract be formed on behalf of the Uni= versity or its subsidiary companies via email. > > ________________________= _______________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > From nobody Mon Mar 27 14:01:55 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D9412967A; Mon, 27 Mar 2017 14:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEMwC0u9x-I5; Mon, 27 Mar 2017 14:01:28 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC0C1279EB; Mon, 27 Mar 2017 14:01:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,233,1486422000"; d="scan'208,217";a="266445830" Received: from mail-vk0-f47.google.com ([209.85.213.47]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 27 Mar 2017 23:01:22 +0200 Received: by mail-vk0-f47.google.com with SMTP id d188so66874625vka.0; Mon, 27 Mar 2017 14:01:22 -0700 (PDT) X-Gm-Message-State: AFeK/H0XJ02QLTrmUtaQUM5Bnk12rveW3fg0tpGfLsmRM2z0/ajt5e6TeomnKxawRaS15XLPS/A1kYG8AyrHxg== X-Received: by 10.176.92.36 with SMTP id q36mr5450303uaf.93.1490648479754; Mon, 27 Mar 2017 14:01:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.194.149 with HTTP; Mon, 27 Mar 2017 14:00:59 -0700 (PDT) From: Thomas Watteyne Date: Mon, 27 Mar 2017 23:00:59 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "6lo@ietf.org" <6lo@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=f403043621d61ef647054bbca593 Archived-At: Subject: [6tisch] Thomas' review of draft-thubert-6lo-forwarding-fragments-04 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 21:01:37 -0000 --f403043621d61ef647054bbca593 Content-Type: text/plain; charset=UTF-8 Authors, all, [CC'ing the 6TiSCH ML as this draft has been discussed quite a number of times at 6TiSCH] After a couple of weeks disconnected, I'm back just in time for reviewing draft-thubert-6lo-forwarding-fragments-04 before the 6lo WG meeting. I'll be (remotely) attending the 6lo WG meeting on Wednesday, happy to further discuss there. What follows are a couple of high level discussion points. This being a relatively short draft, the entire document is copied at the end of this e-mail, with corrections/suggestions directly inline. I left questions and comments with the "TW>" prefix. Please use Diff to report them to the XML. Overall, I believe the draft addresses a very important point, and I'm surprised about the relatively low number of people that stand up to support this work. Are we all happy to reassemble at every hop? really? I believe it is time to adopt this work in 6lo. Thomas --- point 1: clearer intro needed from my understanding, this draft introduces two things: (1) a way of forwarding fragments so as to avoid to have to reassemble at every hop and (2) an end-to-end protocol to request lost fragments to be retransmitted. I think item (1) is really the main contribution of the draft, and (2) is a necessary corollary to making (1) work. The abstract and intro, however, seem to focus almost exclusively on (2), not clearly stating (1). A single sentence at the very beginning stressing the two contributions would go a long way IMO. --- point 2: justification Section 3 provides a rationale as to why this draft is needed. It focuses almost exclusively on reliability: if the link is 99% reliable, then the probability that 5 fragments, etc. IMO that doesn't make much sense as each fragment will be link-layer ACK'ed and retransmitted (at the link layer, i.e."transparently" to 6LoWPAN). There is of course a probability that all retries fail, but justifying the draft by assuming there are no link-layer ACKs make little sense. I may completely misunderstand, in which case, please point that out. The major rationale IMO for this draft is that it doesn't require intermediary nodes to reassemble! Why not just say that? Reassembly at each hop yields several problems, the biggest one in my experience is that of memory management (if I'm missing one fragment from a packet, and a fragment from a second packet arrive, and I have only one assembly buffer, what should I do?). I feel like I'm missing something, or even reading a draft that is not what I expected it to be... --- point 3: Section 5 Overview is not an overview Section 5 is called "Overview" and appears before the actual proposal is described. From the title, I was expecting a couple of paragraphs with the main idea, maybe a diagram or two to make the big picture clear. Instead, the section contains a discussion about very subtle points, including congestion control, interaction with link-layer protocols, timeout calculation and security. To summarize, the text in this section is interesting and should certainly appear in the specification, but as discussion points AFTER the main idea is presented. --- point 4: the confusing use of the word "acknowledgment" While understandable, the use of acknowledgment which can refer to L2 ACKs or RFRAG-ACK messages is confused. I suggest to use the term "RFRAG-ACK" rather than the generic "Acknowledgement". --- point 5: label switching The label switching mechanism is elegant as the labels are locally significant only, with no need to maintain a network-wide label registry. The document should state so. === 6lo P. Thubert, Ed. Internet-Draft Cisco Systems Intended status: Standards Track J. Hui Expires: July 14, 2017 Nest Labs January 10, 2017 LLN Fragment Forwarding and Recovery draft-thubert-6lo-forwarding-fragments-04 Abstract In order to be routed, a fragmented 6LoWPAN packet must be reassembled at every hop of a multihop link where lower layer fragmentation occurs. Considering that the IPv6 minimum MTU is 1280 bytes, and that an 802.15.4 frame can have a payload limited to 74 bytes in the worst case, a packet might end up fragmented into as many as 18 fragments by 6LoWPAN. TW> not sure the term "shim layer" is widely used. I suggest to replace simply by "6LoWPAN" (done already) If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This specification introduces a simple protocol to forward and recover individual fragments that might be lost over multiple hops between 6LoWPAN endpoints. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 14, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Thubert & Hui Expires July 14, 2017 [Page 1] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. New Dispatch types and headers . . . . . . . . . . . . . . . 8 6.1. Recoverable Fragment Dispatch type and Header . . . . . . 8 6.2. Fragment acknowledgment Dispatch type and Header . . . . 8 7. Fragments Recovery . . . . . . . . . . . . . . . . . . . . . 10 8. Forwarding Fragments . . . . . . . . . . . . . . . . . . . . 11 8.1. Upon the first fragment . . . . . . . . . . . . . . . . . 12 8.2. Upon the next fragments . . . . . . . . . . . . . . . . . 13 8.3. Upon the fragment acknowledgments . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction In most Low Power and Lossy Network (LLN) applications, the bulk of the traffic consists of small chunks of data (in the order few bytes to a few tens of bytes) at a time. Given that an 802.15.4 frame can carry 74 bytes or more in all cases, fragmentation is usually not required. However, and though this happens only occasionally, a number of mission-critical applications do require the capability to transfer larger chunks of data, for instance to support firmware update of the LLN nodes, or an extraction of logs from LLN nodes. In the former case, the large chunk of data is transferred to the LLN node, whereas in the latter, the large chunk flows away from the LLN node. In both cases, the size can be on the order of 10 kB or more, and an end-to-end reliable transport is required. Mechanisms such as TCP or application-layer segmentation will be used to support end-to-end reliable transport. One option to support bulk Thubert & Hui Expires July 14, 2017 [Page 2] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 data transfer over a frame-size-constrained LLN is to set the Maximum Segment Size to fit within the link maximum frame size. Doing so, however, can add significant header overhead to each 802.15.4 frame. This causes the end-to-end transport to be intimately aware of the delivery properties of the underlaying LLN, which is a layer violation. An alternative mechanism uses 6LoWPAN fragmentation in addition to transport or application-layer segmentation. Increasing the Maximum Segment Size reduces header overhead by the end-to-end transport protocol. It also encourages the transport protocol to reduce the number of outstanding datagrams, ideally to a single datagram, thus reducing the need to support out-of-order delivery common to LLNs. [RFC4944] defines a datagram fragmentation mechanism for LLNs. However, because [RFC4944] does not define a mechanism for recovering fragments that are lost, datagram forwarding fails if even one fragment is not delivered properly to the next IP hop. End-to-end transport mechanisms will require retransmission of all fragments, wasting resources in an already resource-constrained network. Past experience with fragmentation has shown that mis-associated or lost fragments can lead to poor network behavior and, eventually, trouble at application layer. The reader is encouraged to read [RFC4963] and follow the references for more information. That experience led to the definition of the Path MTU discovery [RFC1191] protocol that limits fragmentation over the Internet. For one-hop communications, a number of media propose a local acknowledgment mechanism that is enough to protect the fragments. In a multihop environment, an end-to-end fragment recovery mechanism might be a good complement to a hop-by-hop MAC level recovery. This draft introduces a simple protocol to recover individual fragments between 6LoWPAN endpoints. Specifically in the case of UDP, valuable additional information can be found in UDP Usage Guidelines for Application Designers [RFC5405]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Readers are expected to be familiar with all the terms and concepts that are discussed in "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Thubert & Hui Expires July 14, 2017 [Page 3] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]. ERP Error Recovery Procedure. 6LoWPAN endpoints The LLN nodes in charge of generating or expanding a 6LoWPAN header from/to a full IPv6 packet. The 6LoWPAN endpoints are the points where fragmentation and reassembly take place. TW> should we add a sentence that states that one of those point is NOT necessarily the LBR? 3. Rationale There are a number of use cases for large packets in Wireless Sensor Networks. Such usages may not be the most typical or represent the largest amount of traffic over the LLN; however, the associated functionality can be critical enough to justify extra care for ensuring effective transport of large packets across the LLN. The list of those use cases includes: Towards the LLN node: Packages of Commands: A number of commands or a full configuration can be packaged as a single message to ensure consistency and enable atomic execution or complete rollback. Until such commands are fully received and interpreted, the intended operation will not take effect. Firmware update: For example, a new version of the LLN node software is downloaded from a system manager over unicast or multicast services. Such a reflashing operation typically involves updating a large number of similar LLN nodes over a relatively short period of time. From the LLN node: Waveform captures: A number of consecutive samples are measured at a high rate for a short time and then transferred from a sensor to a gateway or an edge server as a single large report. Data logs: LLN nodes may generate large logs of sampled data for later extraction. LLN nodes may also generate system logs to assist in diagnosing problems on the node or network. Thubert & Hui Expires July 14, 2017 [Page 4] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 Large data packets: Rich data types might require more than one fragment. Uncontrolled firmware download or waveform upload can easily result in a massive increase of the traffic and saturate the network. When a fragment is lost in transmission, all fragments are resent, further contributing to the congestion that caused the initial loss, and potentially leading to congestion collapse. This saturation may lead to excessive radio interference, or random early discard (leaky bucket) in relaying nodes. Additional queuing and memory congestion may result while waiting for a low power next hop to emerge from its sleeping state. To demonstrate the severity of the problem, consider a fairly reliable 802.15.4 frame delivery rate of 99.9% over a single 802.15.4 hop. The expected delivery rate of a 5-fragment datagram would be about 99.5% over a single 802.15.4 hop. However, the expected delivery rate would drop to 95.1% over 10 hops, a reasonable network diameter for LLN applications. The expected delivery rate for a 1280-byte datagram is 98.4% over a single hop and 85.2% over 10 hops. TW> I don't think this paragraph makes much sense. TW> You would have link-layer ACKs and retries to ensure that all fragments reach the next hop. Considering that [RFC4944] defines an MTU is 1280 bytes and that in most incarnations (but 802.15.4G) a 802.15.4 frame can limit the MAC payload to as few as 74 bytes, a packet might be fragmented into at least 18 fragments by 6LoWPAN. Taking into account the worst-case header overhead for 6LoWPAN Fragmentation and Mesh Addressing headers will increase the number of required fragments to around 32. This level of fragmentation is much higher than that traditionally experienced over the Internet with IPv4 fragments. At the same time, the use of radios increases the probability of transmission loss and Mesh-Under techniques compound that risk over multiple hops. 4. Requirements This specification proposes a method to recover individual fragments between LLN endpoints. TW> add that endpoints can be multiple hops away from one another? The method is designed to fit the following requirements of a LLN (with or without a Mesh-Under routing protocol): Number of fragments The recovery mechanism must support highly fragmented packets, with a maximum of 32 fragments per packet. TW> resulting length of the packet? The abstract implies a 32*74=2368 byte limit. Is that correct? Minimum acknowledgment overhead Thubert & Hui Expires July 14, 2017 [Page 5] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 Because the radio is half duplex, and because of silent time spent in the various medium access mechanisms, an acknowledgment consumes roughly as many resources as data fragment. The recovery mechanism should be able to acknowledge multiple fragments in a single message and not require an acknowledgment at all if fragments are already protected at a lower layer. TW> maybe specify here that we are talking about end-to-end ACKs between endpoints, not L2 ACKs Controlled latency The recovery mechanism must succeed or give up within the time boundary imposed by the recovery process of the Upper Layer Protocols. Support for out-of-order fragment delivery A Mesh-Under load balancing mechanism such as the ISA100 Data Link Layer can introduce out-of-sequence packets. TW> I don't fully understand why we focus so much on mesh-under. TW> If you have a fully mesh-under network, 4944 fragmentation results in fragment forwarding. TW> I would remove the repeated mentioning on mesh-under (as well as ISA100) The recovery mechanism must account for packets that appear lost but are actually only delayed over a different path. Optional congestion control The aggregation of multiple concurrent flows may lead to the saturation of the radio network and congestion collapse. The recovery mechanism should provide means for controlling the number of fragments in transit over the LLN. 5. Overview Considering that a multi-hop LLN can be a very sensitive environment due to the limited queuing capabilities of a large population of its nodes, this specification recommends a simple and conservative approach to congestion control, based on TCP congestion avoidance. TW> "based on" or "inspired by" TW> The "overview" section delves immediately into subtle discussions about congestion control. TW> At this point, the reader (e.g. me) have no idea what the basic principle is. TW> Discussions about subtleties such as congestion control seem out of place here. Congestion on the forward path is assumed in case of packet loss, and packet loss is assumed upon time out. This specification allows to control the number of outstanding fragments, that have been transmitted but for which an acknowledgment was not received yet. It must be noted that the number of outstanding fragments should not exceed the number of hops in the network, but the way to figure the number of hops is out of scope for this document. Congestion on the forward path can also be indicated by an Explicit Congestion Notification (ECN) mechanism. Though whether and how ECN [RFC3168] is carried out over the LoWPAN is out of scope, this draft Thubert & Hui Expires July 14, 2017 [Page 6] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 provides a way for the destination endpoint to echo an ECN indication back to the source endpoint in an acknowledgment message as represented in Figure 5 in Section 6.2. TW> The following paragraph talks about how a link-layer transmits multiple frames in a row. TW> The link-layer does so whether those frames are fragments or regular packets. TW> I would remove this discussion, which seems to be link-layer only, and not specific to fragment forwarding. It must be noted that congestion and collision are different topics. In particular, when a mesh operates on a same channel over multiple hops, then the forwarding of a fragment over a certain hop may collide with the forwarding of a next fragment that is following over a previous hop but in a same interference domain. This draft enables an end-to-end flow control, but leaves it to the sender stack to pace individual fragments within a transmit window, so that a given fragment is sent only when the previous fragment has had a chance to progress beyond the interference domain of this hop. In the case of 6TiSCH [I-D.ietf-6tisch-architecture], which operates over the TimeSlotted Channel Hopping [I-D.ietf-6tisch-tsch] (TSCH) mode of operation of IEEE802.14.5, a fragment is forwarded over a different channel at a different time and it make full sense to fire a next fragment as soon as the previous fragment has had its chance to be forwarded at the next hop, retry (ARQ) operations included. From the standpoint of a source 6LoWPAN endpoint, an outstanding fragment is a fragment that was sent but for which no explicit acknowledgment was received yet. This means that the fragment might be on the way, received but not yet acknowledged, or the acknowledgment might be on the way back. It is also possible that either the fragment or the acknowledgment was lost on the way. Because a meshed LLN might deliver frames out of order, it is virtually impossible to differentiate these situations. In other words, from the sender's standpoint, all outstanding fragments might still be in the network and contribute to its congestion. There is an assumption, though, that after a certain amount of time, a frame is either received or lost, so it is not causing congestion anymore. This amount of time can be estimated based on the round trip delay between the 6LoWPAN endpoints. The method detailed in [RFC6298] is recommended for that computation. The reader is encouraged to read through "Congestion Control Principles" [RFC2914]. Additionally [RFC2309] and [RFC5681] provide deeper information on why this mechanism is needed and how TCP handles Congestion Control. Basically, the goal here is to manage the amount of fragments present in the network; this is achieved by to reducing the number of outstanding fragments over a congested path by throttling the sources. Section 7 describes how the sender decides how many fragments are (re)sent before an acknowledgment is required, and how the sender adapts that number to the network conditions. Thubert & Hui Expires July 14, 2017 [Page 7] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 6. New Dispatch types and headers This specification extends "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944] with 4 new dispatch types, for Recoverable Fragments (RFRAG) headers with or without Acknowledgment Request, and for the Acknowledgment back, with or without ECN Echo. Pattern Header Type +------------+-----------------------------------------------+ | 11 101000 | RFRAG - Recoverable Fragment | | 11 101001 | RFRAG-AR - RFRAG with Ack Request | | 11 101010 | RFRAG-ACK - RFRAG Acknowledgment | | 11 101011 | RFRAG-AEC - RFRAG Ack with ECN Echo | +------------+-----------------------------------------------+ Figure 1: Additional Dispatch Value Bit Patterns In the following sections, the semantics of "datagram_tag", "datagram_offset" and "datagram_size" and the reassembly process are changed from [RFC4944] Section 5.3. "Fragmentation Type and Header". The size and offset are expressed on the compressed packet per [RFC6282] as opposed to the uncompressed - native packet - form. 6.1. Recoverable Fragment Dispatch type and Header 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 0 X|datagram_offset| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sequence | datagram_size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ X set == Ack Requested Figure 2: Recoverable Fragment Dispatch type and Header X: 1 bit; When set, the sender requires an Acknowledgment from the receiver Sequence: 5 bits; The sequence number of the fragment. Fragments are numbered [0..N] where N is in [0..31]. 6.2. Fragment acknowledgment Dispatch type and Header The specification also defines a 4-octet acknowledgment bitmap that is used to carry selective acknowledgments for the received fragments. A given offset in the bitmap maps one to one with a given sequence number. Thubert & Hui Expires July 14, 2017 [Page 8] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 The offset of the bit in the bitmap indicates which fragment is acknowledged as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Bitmap | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ | | bitmap indicating whether: | +--- Fragment with sequence 10 was received +----------------------- Fragment with sequence 00 was received Figure 3: Acknowledgment bitmap encoding TW> rewrote the paragraph below Figure 4 shows an example Acknowledgment bitmap which indicates that all fragments from sequence 0 to 20 were received, except for fragments 1, 2 and 16 that were either lost or are still in the network over a slower path. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 1 1 1 1 1|1 1 1 1 1 1 1 1|0 1 1 1 1 0 0 0|0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Example acknowledgment bitmap The acknowledgment bitmap is carried in a Fragment Acknowledgment as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 1 Y| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Bitmap (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Fragment Acknowledgment Dispatch type and Header Y: 1 bit; Explicit Congestion Notification (ECN) signaling When set, the sender indicates that at least one of the acknowledged fragments was received with an Explicit Congestion Notification, indicating that the path followed by the fragments is subject to congestion. Acknowledgment Bitmap Thubert & Hui Expires July 14, 2017 [Page 9] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 An acknowledgment bitmap, whereby but at offset x indicates that fragment x was received. 7. Fragments Recovery The Recoverable Fragments header RFRAG and RFRAG-AR deprecate the original fragment headers from [RFC4944] and replace them in the fragmented packets. TW> are we really deprecating 4944 fragmentation, or adding another option? The Fragment Acknowledgment RFRAG-ACK is introduced as a standalone header in a message that is sent back to the fragment source endpoint as known by its MAC address. This assumes that the source MAC address in the fragment (if any) and datagram_tag are enough information to send the Fragment Acknowledgment back to the source fragmentation endpoint. TW> I get confused. Isn't the source MAC address changed at each hop? The 6LoWPAN endpoint that fragments the packets at the 6LoWPAN level (the sender) controls the Fragment Acknowledgments. If may do that at any fragment to implement its own policy or perform congestion control which is out of scope for this document. TW> I don't understand the previous sentence. When the sender of the fragment knows that an underlying mechanism protects TW> "protects" -> "ensures delivery of"? the Fragments already it MAY refrain from using the Acknowledgment mechanism, and never set the ACK Requested bit. The 6LoWPAN endpoint that recomposes the packets at 6LoWPAN level (the receiver) MUST acknowledge the fragments it has received when asked to, and MAY slightly defer that acknowledgment. The sender transfers a controlled number of fragments and MAY flag the last fragment of a series with an acknowledgment request. The received MUST acknowledge a fragment with the acknowledgment request bit set. TW> reword to "the receiver which receives a fragment with the ACK Request bit set MUST send back an acknowledgment"? If any fragment immediately preceding an acknowledgment request is still missing, the receiver MAY intentionally delay its acknowledgment to allow in-transit fragments to arrive. Delaying the acknowledgment might defeat the round trip delay computation so it should be configurable and not enabled by default. The receiver interacts with the sender using an Acknowledgment message with a bitmap that indicates which fragments were actually received. The bitmap is a 32 bit SWORD TW> why SWORD? , which accommodates up to 32 fragments and is sufficient for the 6LoWPAN MTU. For all n in [0..31], bit n is set to 1 in the bitmap to indicate that fragment with sequence n was received, otherwise the bit is set to 0. All zeros is a NULL bitmap that indicates that the fragmentation process was canceled by the receiver for that datagram. The receiver MAY issue unsolicited acknowledgments. An unsolicited acknowledgment enables the sender endpoint to resume sending if it had reached its maximum number of outstanding fragments or indicate that the receiver has canceled the process of an individual datagram. Note that acknowledgments might consume precious resources Thubert & Hui Expires July 14, 2017 [Page 10] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 so the use of unsolicited acknowledgments should be configurable and not enabled by default. The sender arms a retry timer to cover the fragment that carries the Acknowledgment request. Upon time out, the sender assumes that all the fragments on the way are received or lost. The process must have completed within an acceptable time that is within the boundaries of upper layer retries. The method detailed in [RFC6298] is recommended for the computation of the retry timer. It is expected that the upper layer retries obey the same or friendly rules in which case a single round of fragment recovery should fit within the upper layer recovery timers. Fragments are sent in a round robin fashion: the sender sends all the fragments for a first time before it retries any lost fragment; lost fragments are retried in sequence, oldest first. This mechanism enables the receiver to acknowledge fragments that were delayed in the network before they are actually retried. When the sender decides that a packet should be dropped and the fragmentation process canceled, it sends a pseudo fragment with the datagram_offset, sequence and datagram_size all set to zero, and no data. Upon reception of this message, the receiver should clean up all resources for the packet associated to the datagram_tag. If an acknowledgment is requested, the receiver responds with a NULL bitmap. The receiver might need to cancel the process of a fragmented packet for internal reasons, for instance if it is out of recomposition buffers, or considers that this packet is already fully recomposed and passed to the upper layer. In that case, the receiver SHOULD indicate so to the sender with a NULL bitmap. Upon an acknowledgment with a NULL bitmap, the sender MUST drop the datagram. 8. Forwarding Fragments This specification enables intermediate routers to forward fragments with no intermediate reconstruction of the entire packet. Upon the first fragment, the routers lay a label along the path that is followed by that fragment (that is IP routed), and all further fragments are label switched along that path. As a consequence, alternate routes are not possible for individual fragments. The datagram_tag is used to carry the label, that is swapped at each hop. Thubert & Hui Expires July 14, 2017 [Page 11] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 8.1. Upon the first fragment In route over the L2 source changes at each hop. TW> something's wrong with the previous sentence The label that is formed and placed in the datagram_tag is associated to the source MAC and only valid (and unique) for that source MAC. Say the first fragment has: Source IPv6 address = IP_A (may be multiple hops away) Destination IPv6 address = IP_B (maybe be multiple hops away) Source MAC = MAC_prv (prv as previous) Datagram_tag= DT_prv The intermediate router that forwards individual fragments does the following: a route lookup to get Next hop IPv6 towards IP_B, which resolves as IP_nxt (nxt as next) a MAC address resolution to get the MAC address associated to IP_nxt, which resolves as MAC_nxt Since it is a first fragment of a packet from that source MAC address MAC_prv for that tag DT_prv, the router: cleans up any leftover resource associated to the tuple (MAC_prv, DT_prv) allocates a new label for that flow, DT_nxt, from a Least Recently Used pool or some similar procedure. allocates a Label swap structure indexed by (MAC_prv, DT_prv) that contains (MAC_nxt, DT_nxt) allocates a Label swap structure indexed by (MAC_nxt, DT_nxt) that contains (MAC_prv, DT_prv) swaps the MAC info to from self to MAC_nxt Swaps the datagram_tag to DT_nxt At this point the router is all set and can forward the packet to nxt. TW> this assumes the first fragment is long enough to contain the source/destination IP addresses, right? Thubert & Hui Expires July 14, 2017 [Page 12] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 8.2. Upon the next fragments Upon next fragments (that are not first fragment), the router expects to have already Label swap structure indexed by (MAC_prv, DT_prv). The router: looks up the Label swap entry for (MAC_prv, DT_prv), which resolves as (MAC_nxt, DT_nxt) swaps the MAC info to from self to MAC_nxt; Swaps the datagram_tag to DT_nxt At this point the router is all set and can forward the packet to nxt. if the Label swap entry for (MAC_src, DT_src) is not found, the router builds an RFRAG-ACK to indicate the error. The acknowledgment message has the following information: MAC info set to from self to MAC_prv as found in the fragment TW> "to from"? Swaps the datagram_tag set to DT_prv Bitmap of all zeroes to indicate the error At this point the router is all set and can send the RFRAG-ACK back to the previous router. 8.3. Upon the fragment acknowledgments Upon fragment acknowledgments next fragments TW> reads strange (that are not first fragment), the router expects to have already Label swap structure indexed by (MAC_nxt, DT_nxt). The router: looks up the Label swap entry for (MAC_nxt, DT_nxt), which resolves as (MAC_prv, DT_prv) swaps the MAC info to from self to MAC_prv; swaps the datagram_tag to DT_prv At this point the router is all set and can forward the RFRAG-ACK to prv. If the Label swap entry for (MAC_nxt, DT_nxt) is not found, it simply drops the packet. Thubert & Hui Expires July 14, 2017 [Page 13] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 If the RFRAG-ACK indicates either an error or that the fragment was fully receive, the router schedules the Label swap entries for recycling. If the RFRAG-ACK is lost on the way back, the source may retry the last fragments, which will result as an error RFRAG-ACK from the first router on the way that has already cleaned up. 9. Security Considerations The process of recovering fragments does not appear to create any opening for new threat compared to "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]. 10. IANA Considerations Need extensions for formats defined in "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]. 11. Acknowledgments The author wishes to thank Jay Werb, Christos Polyzois, Soumitri Kolavennu, Pat Kinney, Margaret Wasserman, Richard Kelsey, Carsten Bormann and Harry Courtice for their contributions and review. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, . [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, . [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, . Thubert & Hui Expires July 14, 2017 [Page 14] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 12.2. Informative References [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work in progress), June 2016. [I-D.ietf-6tisch-tsch] Watteyne, T., Palattella, M., and L. Grieco, "Using IEEE802.15.4e TSCH in an IoT context: Overview, Problem Statement and Goals", draft-ietf-6tisch-tsch-06 (work in progress), March 2015. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, . [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, . [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, July 2007, . Thubert & Hui Expires July 14, 2017 [Page 15] Internet-Draft LLN Fragment Forwarding and Recovery January 2017 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, . [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, . Authors' Addresses Pascal Thubert (editor) Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 MOUGINS - Sophia Antipolis 06254 FRANCE Phone: +33 497 23 26 34 Email: pthubert@cisco.com Jonathan W. Hui Nest Labs 3400 Hillview Ave Palo Alto, California 94304 USA Email: jonhui@nestlabs.com Thubert & Hui Expires July 14, 2017 [Page 16] -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --f403043621d61ef647054bbca593 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Authors, all,
=C2=A0
[CC'ing = the 6TiSCH ML as this draft has been discussed quite a number of times at 6= TiSCH]
=C2=A0
After a couple of weeks disconnected, I&#= 39;m back just in time for reviewing draft-thubert-6lo-forwarding-fragments= -04 before the 6lo WG meeting. I'll be (remotely) attending the 6lo WG = meeting on Wednesday, happy to further discuss there.
=C2=A0
What follows are a couple of high level discussion points.
<= div>This being a relatively short draft, the entire document is copied at t= he end of this e-mail, with corrections/suggestions directly inline.
I left questions and comments with the "TW>" prefix.
Please use Diff to report them to the XML.
=C2=A0
Overall, I believe the draft addresses a very important point, and = I'm surprised about the relatively low number of people that stand up t= o support this work. Are we all happy to reassemble at every hop? really?
=C2=A0
I believe it is time to adopt this work in 6lo.

Thomas
=C2=A0
---
=
=C2=A0
point 1: clearer intro needed
=C2=A0
<= div>from my understanding, this draft introduces two things: (1) a way of f= orwarding fragments so as to avoid to have to reassemble at every hop and (= 2) an end-to-end protocol to request lost fragments to be retransmitted. I = think item (1) is really the main contribution of the draft, and (2) is a n= ecessary corollary to making (1) work. The abstract and intro, however, see= m to focus almost exclusively on (2), not clearly stating (1). A single sen= tence at the very beginning stressing the two contributions would go a long= way IMO.
=C2=A0
---
=C2=A0
point 2= : justification
=C2=A0
Section 3 provides a rationale a= s to why this draft is needed. It focuses almost exclusively on reliability= : if the link is 99% reliable, then the probability that 5 fragments, etc. = IMO that doesn't make much sense as each fragment will be link-layer AC= K'ed and retransmitted (at the link layer, i.e."transparently"= ; to 6LoWPAN). There is of course a probability that all retries fail, but = justifying the draft by assuming there are no link-layer ACKs make little s= ense. I may completely misunderstand, in which case, please point that out.=
=C2=A0
The major rationale IMO for this draft is that = it doesn't require intermediary nodes to reassemble! Why not just say t= hat? Reassembly at each hop yields several problems, the biggest one in my = experience is that of memory management (if I'm missing one fragment fr= om a packet, and a fragment from a second packet arrive, and I have only on= e assembly buffer, what should I do?).
=C2=A0
I feel li= ke I'm missing something, or even reading a draft that is not what I ex= pected it to be...
=C2=A0
---
=C2=A0
point 3: Section 5 Overview is not an overview
=C2=A0
Section 5 is called "Overview" and appears before the actual pro= posal is described. From the title, I was expecting a couple of paragraphs = with the main idea, maybe a diagram or two to make the big picture clear. I= nstead, the section contains a discussion about very subtle points, includi= ng congestion control, interaction with link-layer protocols, timeout calcu= lation and security.
=C2=A0
To summarize, the text in t= his section is interesting and should certainly appear in the specification= , but as discussion points AFTER the main idea is presented.
=C2= =A0
---

point 4: the confusing use of th= e word "acknowledgment"

While understand= able, the use of acknowledgment which can refer to L2 ACKs or=C2=A0RFRAG-AC= K messages is confused. I suggest to use the term "RFRAG-ACK" rat= her than the generic "Acknowledgement".

= ---

point 5: label switching

<= div>The label switching mechanism is elegant as the labels are locally sign= ificant only, with no need to maintain a network-wide label registry. The d= ocument should state so.

=3D=3D=3D

<= /div>
6lo =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0P. Thubert, Ed.
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cisco Systems
Intended status: Standards Track =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0J. Hui
Expires: July 14, 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Nest Labs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 January = 10, 2017


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 LLN Fragment Forwarding and Recovery
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0draft-thubert-6lo-forwarding-fragments-04

Abstract

=C2=A0 =C2=A0I= n order to be routed, a fragmented 6LoWPAN packet must be
= =C2=A0 =C2=A0reassembled at every hop o= f a multihop link where lower layer
=C2=A0 =C2=A0fragmentation occurs.=C2=A0 Considering that the= IPv6 minimum MTU is 1280
=C2=A0 =C2=A0bytes, and that an 802.15.4 frame can have a payload limit= ed to 74
=C2=A0 =C2=A0= bytes in the worst case, a packet might end up fragmented into as
=C2=A0 =C2=A0many as 18 fragmen= ts by 6LoWPAN.
TW> = not sure the term "shim layer" is widely used. I suggest to repla= ce simply by "6LoWPAN" (done already)
=C2=A0 =C2=A0If a single one of
= =C2=A0 =C2=A0those fragments is lost in= transmission, all fragments must be
=C2=A0 =C2=A0resent, further contributing to the congestion = that might have caused
=C2=A0 =C2=A0the initial packet loss.=C2=A0 This specification introduces = a simple protocol to
= =C2=A0 =C2=A0forward and recover individual fragments that might be lost ov= er
=C2=A0 =C2=A0multip= le hops between 6LoWPAN endpoints.

Stat= us of This Memo

=C2=A0 =C2=A0This Inter= net-Draft is submitted in full conformance with the
=C2=A0 =C2=A0provisions of BCP 78 and BCP 79.=

=C2=A0 =C2=A0Internet-Drafts are worki= ng documents of the Internet Engineering
=C2=A0 =C2=A0Task Force (IETF).=C2=A0 Note that other gr= oups may also distribute
=C2=A0 =C2=A0working documents as Internet-Drafts.=C2=A0 The list of cur= rent Internet-

=C2=A0 =C2=A0Internet-Drafts are draft documents valid for a maxi= mum of six months
=C2= =A0 =C2=A0and may be updated, replaced, or obsoleted by other documents at = any
=C2=A0 =C2=A0time.= =C2=A0 It is inappropriate to use Internet-Drafts as reference
=
=C2=A0 =C2=A0material or to cite t= hem other than as "work in progress."

=C2=A0 =C2=A0This Internet-Draft will expire on July 14, 2017.

Copyright Notice

=C2=A0 =C2=A0Copyright (c) 2017 IETF Trust and the persons ident= ified as the
=C2=A0 = =C2=A0document authors.=C2=A0 All rights reserved.

=C2=A0 =C2=A0This document is subject to BCP 78 and the IETF Tr= ust's Legal
=C2=A0= =C2=A0Provisions Relating to IETF Documents



=
Thubert & Hui =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires July 14, 2017 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 1]
=0C
= Internet-Draft =C2=A0 =C2=A0LLN Fragmen= t Forwarding and Recovery =C2=A0 =C2=A0 =C2=A0January 2017


=C2=A0 =C2=A0(http://tr= ustee.ietf.org/license-info) in effect on the date of
= =C2=A0 =C2=A0publication of this docume= nt.=C2=A0 Please review these documents
=C2=A0 =C2=A0carefully, as they describe your rights and = restrictions with respect
=C2=A0 =C2=A0to this document.=C2=A0 Code Components extracted from thi= s document must
=C2=A0= =C2=A0include Simplified BSD License text as described in Section 4.e of
=C2=A0 =C2=A0the Trust = Legal Provisions and are provided without warranty as
=C2=A0 =C2=A0described in the Simplified BS= D License.

=
Table of Contents

=C2=A0 =C2=A01.=C2=A0 Introduction =C2=A0. . . . = . . . . . . . . . . . . . . . . . . . . =C2=A0 2
=C2=A0 =C2=A02.=C2=A0 Terminology . . . . . . . = . . . . . . . . . . . . . . . . . . =C2=A0 3
=C2=A0 =C2=A03.=C2=A0 Rationale . . . . . . . . . . = . . . . . . . . . . . . . . . . =C2=A0 4
=C2=A0 =C2=A04.=C2=A0 Requirements =C2=A0. . . . . . . .= . . . . . . . . . . . . . . . . =C2=A0 5
=C2=A0 =C2=A05.=C2=A0 Overview =C2=A0. . . . . . . . . = . . . . . . . . . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A06.=C2=A0 New Dispatch types and headers = =C2=A0. . . . . . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A0 =C2=A06.1.=C2=A0 Recoverable Fragment = Dispatch type and Header . . . . . . =C2=A0 8
=C2=A0 =C2=A0 =C2=A06.2.=C2=A0 Fragment acknowled= gment Dispatch type and Header =C2=A0. . . . =C2=A0 8
=C2=A0 =C2=A07.=C2=A0 Fragments Recovery = =C2=A0. . . . . . . . . . . . . . . . . . . . . =C2=A010
<= font face=3D"monospace, monospace">=C2=A0 =C2=A08.=C2=A0 Forwarding Fragmen= ts =C2=A0. . . . . . . . . . . . . . . . . . . . =C2=A011
= =C2=A0 =C2=A0 =C2=A08.1.=C2=A0 Upon the= first fragment . . . . . . . . . . . . . . . . . =C2=A012
=C2=A0 =C2=A0 =C2=A08.2.=C2=A0 Upon th= e next fragments . . . . . . . . . . . . . . . . . =C2=A013
=C2=A0 =C2=A0 =C2=A08.3.=C2=A0 Upon t= he fragment acknowledgments . . . . . . . . . . . . =C2=A013
=C2=A0 =C2=A09.=C2=A0 Security Consi= derations . . . . . . . . . . . . . . . . . . . =C2=A014
<= font face=3D"monospace, monospace">=C2=A0 =C2=A010. IANA Considerations . .= . . . . . . . . . . . . . . . . . . . =C2=A014
=C2=A0 =C2=A011. Acknowledgments . . . . . . . . = . . . . . . . . . . . . . . . =C2=A014
=C2=A0 =C2=A012. References =C2=A0. . . . . . . . . . . . = . . . . . . . . . . . . . =C2=A014
=C2=A0 =C2=A0 =C2=A012.1.=C2=A0 Normative References . . . . .= . . . . . . . . . . . . . =C2=A014
=C2=A0 =C2=A0 =C2=A012.2.=C2=A0 Informative References . . . = . . . . . . . . . . . . . . =C2=A015
=C2=A0 =C2=A0Authors' Addresses =C2=A0. . . . . . . . . = . . . . . . . . . . . . . . =C2=A016

1.= =C2=A0 Introduction
=C2=A0 =C2=A0In mos= t Low Power and Lossy Network (LLN) applications, the bulk of
<= div>=C2=A0 =C2=A0the traffic consists o= f small chunks of data (in the order few bytes
=C2=A0 =C2=A0to a few tens of bytes) at a time.= =C2=A0 Given that an 802.15.4 frame can
=C2=A0 =C2=A0carry 74 bytes or more in all cases, fragmen= tation is usually not
= =C2=A0 =C2=A0required.=C2=A0 However, and though this happens only occasion= ally, a
=C2=A0 =C2=A0n= umber of mission-critical applications do require the capability to<= /div>
=C2=A0 =C2=A0transfer larger = chunks of data, for instance to support firmware
=C2=A0 =C2=A0update of the LLN nodes, or an extr= action of logs from LLN nodes.
=C2=A0 =C2=A0In the former case, the large chunk of data is transf= erred to the LLN
=C2= =A0 =C2=A0node, whereas in the latter, the large chunk flows away from the = LLN
=C2=A0 =C2=A0node.= =C2=A0 In both cases, the size can be on the order of 10 kB or
=
=C2=A0 =C2=A0more, and an end-to-e= nd reliable transport is required.

=C2= =A0 =C2=A0Mechanisms such as TCP or application-layer segmentation will be = used
=C2=A0 =C2=A0to s= upport end-to-end reliable transport.=C2=A0 One option to support bulk



Th= ubert & Hui =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires July 14, = 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 2]
=0C
Internet-Draf= t =C2=A0 =C2=A0LLN Fragment Forwarding and Recovery =C2=A0 =C2=A0 =C2=A0Jan= uary 2017

<= /div>

=C2=A0 =C2=A0data transfer over a frame-size-c= onstrained LLN is to set the Maximum
=C2=A0 =C2=A0Segment Size to fit within the link maximum fra= me size.=C2=A0 Doing so,
=C2=A0 =C2=A0however, can add significant header overhead to each 802.15= .4 frame.
=C2=A0 =C2= =A0This causes the end-to-end transport to be intimately aware of the
=C2=A0 =C2=A0delivery prope= rties of the underlaying LLN, which is a layer
=C2=A0 =C2=A0violation.

=C2=A0 =C2=A0An alternative mechanism uses 6LoWPAN fragmentation= in
=C2=A0 =C2=A0addit= ion to transport or application-layer segmentation.=C2=A0 Increasing=
=C2=A0 =C2=A0the Maximum Seg= ment Size reduces header overhead by the end-to-end
=C2=A0 =C2=A0transport protocol.=C2=A0 It als= o encourages the transport protocol to
=C2=A0 =C2=A0reduce the number of outstanding datagrams, i= deally to a single
=C2= =A0 =C2=A0datagram, thus reducing the need to support out-of-order delivery=
=C2=A0 =C2=A0common t= o LLNs.

=C2=A0 =C2=A0[RFC4944] defines = a datagram fragmentation mechanism for LLNs.
=C2=A0 =C2=A0However, because [RFC4944] does not def= ine a mechanism for recovering
=C2=A0 =C2=A0fragments that are lost, datagram forwarding fails if= even one
=C2=A0 =C2= =A0fragment is not delivered properly to the next IP hop.=C2=A0 End-to-end<= /font>
=C2=A0 =C2=A0transport= mechanisms will require retransmission of all fragments,
= =C2=A0 =C2=A0wasting resources in an al= ready resource-constrained network.

=C2= =A0 =C2=A0Past experience with fragmentation has shown that mis-associated = or
=C2=A0 =C2=A0lost f= ragments can lead to poor network behavior and, eventually,
=C2=A0 =C2=A0trouble at application l= ayer.=C2=A0 The reader is encouraged to read
=C2=A0 =C2=A0[RFC4963] and follow the references for= more information.=C2=A0 That
=C2=A0 =C2=A0experience led to the definition of the Path MTU disco= very [RFC1191]
=C2=A0 = =C2=A0protocol that limits fragmentation over the Internet.

=C2=A0 =C2=A0For one-hop communications, a number of m= edia propose a local
= =C2=A0 =C2=A0acknowledgment mechanism that is enough to protect the fragmen= ts.=C2=A0 In
=C2=A0 = =C2=A0a multihop environment, an end-to-end fragment recovery mechanism
=C2=A0 =C2=A0might be a g= ood complement to a hop-by-hop MAC level recovery.=C2=A0 This
<= div>=C2=A0 =C2=A0draft introduces a sim= ple protocol to recover individual fragments
=C2=A0 =C2=A0between 6LoWPAN endpoints.=C2=A0 Specif= ically in the case of UDP, valuable
=C2=A0 =C2=A0additional information can be found in UDP Usage= Guidelines for
=C2=A0= =C2=A0Application Designers [RFC5405].

2.=C2=A0 Terminology
=
=C2=A0 =C2=A0The = key words "MUST", "MUST NOT", "REQUIRED", &qu= ot;SHALL", "SHALL NOT",
=C2=A0 =C2=A0"SHOULD", "SHOULD NOT", &= quot;RECOMMENDED", "MAY", and "OPTIONAL" in this
=C2=A0 =C2=A0document a= re to be interpreted as described in [RFC2119].

=C2=A0 =C2=A0Readers are expected to be familiar with all the term= s and concepts
=C2=A0 = =C2=A0that are discussed in "IPv6 over Low-Power Wireless Personal Are= a
=C2=A0 =C2=A0Network= s (6LoWPANs): Overview, Assumptions, Problem Statement, and




Thubert & Hui =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires July 14, 2017 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 3]
=0C
= Internet-Draft =C2=A0 =C2=A0LLN Fragmen= t Forwarding and Recovery =C2=A0 =C2=A0 =C2=A0January 2017


=C2=A0 =C2=A0Goals" [RFC4919] and "Transmission of IPv6 Packet= s over IEEE 802.15.4
= =C2=A0 =C2=A0Networks" [RFC4944].

= =C2=A0 =C2=A0ERP

<= /font>
=C2=A0 =C2=A0 =C2=A0 E= rror Recovery Procedure.

=C2=A0 =C2=A06= LoWPAN endpoints

<= /font>
=C2=A0 =C2=A0 =C2=A0 T= he LLN nodes in charge of generating or expanding a 6LoWPAN
=C2=A0 =C2=A0 =C2=A0 header from/to a= full IPv6 packet.=C2=A0 The 6LoWPAN endpoints are the
=C2=A0 =C2=A0 =C2=A0 points where fragment= ation and reassembly take place.
TW> should we add a sentence that states that one of those po= int is NOT necessarily the LBR?

3.=C2= =A0 Rationale

=C2=A0 =C2=A0There are a = number of use cases for large packets in Wireless Sensor
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0Networks.=C2=A0 Such usages= may not be the most typical or represent the
=C2=A0 =C2=A0largest amount of traffic over the L= LN; however, the associated
=C2=A0 =C2=A0functionality can be critical enough to justify extra ca= re for
=C2=A0 =C2=A0en= suring effective transport of large packets across the LLN.

=C2=A0 =C2=A0The list of those use cases includes:

=C2=A0 =C2=A0Towards the LLN node:<= /div>

=C2=A0 =C2=A0 =C2=A0 Packages of Commands: =C2= =A0A number of commands or a full
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration can be packaged= as a single message to ensure
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0consistency and enable atomic ex= ecution or complete rollback.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Until such commands are fully rec= eived and interpreted, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0intended operation will not take eff= ect.

=
=C2=A0 =C2=A0 =C2=A0 Firmware upda= te: =C2=A0For example, a new version of the LLN node
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0software i= s downloaded from a system manager over unicast or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multicast se= rvices.=C2=A0 Such a reflashing operation typically
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0involves up= dating a large number of similar LLN nodes over a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0relatively sh= ort period of time.
=C2=A0 =C2=A0From t= he LLN node:

=C2=A0 =C2=A0 =C2=A0 Wavef= orm captures: =C2=A0A number of consecutive samples are measured
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0at a high rate for a short time and then transferred from a
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= sensor to a gateway or an edge server as a single large report.

=C2=A0 =C2=A0 =C2=A0 Data logs: =C2=A0LLN nodes m= ay generate large logs of sampled data for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0later extraction.=C2= =A0 LLN nodes may also generate system logs to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0assist in diagn= osing problems on the node or network.

=

=


Thubert & Hui =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expire= s July 14, 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Pa= ge 4]
=0C
In= ternet-Draft =C2=A0 =C2=A0LLN Fragment Forwarding and Recovery =C2=A0 =C2= =A0 =C2=A0January 2017


=C2=A0 =C2=A0 =C2=A0 Large data p= ackets: =C2=A0Rich data types might require more than one
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fragm= ent.

=
=C2=A0 =C2=A0Uncontrolled firmware= download or waveform upload can easily result
=C2=A0 =C2=A0in a massive increase of the traffic= and saturate the network.

=C2=A0 =C2= =A0When a fragment is lost in transmission, all fragments are resent,
=C2=A0 =C2=A0further contri= buting to the congestion that caused the initial loss,
=C2=A0 =C2=A0and potentially leading to co= ngestion collapse.
=C2=A0 =C2=A0This sa= turation may lead to excessive radio interference, or random
=C2=A0 =C2=A0early discard (leaky bu= cket) in relaying nodes.=C2=A0 Additional queuing
=C2=A0 =C2=A0and memory congestion may result w= hile waiting for a low power next
=C2=A0 =C2=A0hop to emerge from its sleeping state.

=C2=A0 =C2=A0To demonstrate the severity of the p= roblem, consider a fairly
=C2=A0 =C2=A0reliable 802.15.4 frame delivery rate of 99.9% over a sing= le 802.15.4
=C2=A0 =C2= =A0hop.=C2=A0 The expected delivery rate of a 5-fragment datagram would be<= /font>
=C2=A0 =C2=A0about 99.= 5% over a single 802.15.4 hop.=C2=A0 However, the expected
=C2=A0 =C2=A0delivery rate would drop = to 95.1% over 10 hops, a reasonable network
=C2=A0 =C2=A0diameter for LLN applications.=C2=A0 The= expected delivery rate for a
=C2=A0 =C2=A01280-byte datagram is 98.4% over a single hop and 85.2= % over 10 hops.
TW>= I don't think this paragraph makes much sense.
TW> You would have link-layer ACKs and ret= ries to ensure that all fragments reach the next hop.

=C2=A0 =C2=A0Considering that [RFC4944] defines an MTU is 12= 80 bytes and that in
= =C2=A0 =C2=A0most incarnations (but 802.15.4G) a 802.15.4 frame can limit t= he MAC
=C2=A0 =C2=A0pa= yload to as few as 74 bytes, a packet might be fragmented into at
=C2=A0 =C2=A0least 18 fragments= by 6LoWPAN.=C2=A0 Taking into account
=C2=A0 =C2=A0the worst-case header overhead for 6LoWPAN Fr= agmentation and Mesh
= =C2=A0 =C2=A0Addressing headers will increase the number of required fragme= nts to
=C2=A0 =C2=A0ar= ound 32.=C2=A0 This level of fragmentation is much higher than that<= /div>
=C2=A0 =C2=A0traditionally ex= perienced over the Internet with IPv4 fragments.=C2=A0 At
= =C2=A0 =C2=A0the same time, the use of = radios increases the probability of
=C2=A0 =C2=A0transmission loss and Mesh-Under techniques comp= ound that risk over
= =C2=A0 =C2=A0multiple hops.
=C2=A0 =C2=A0
4.= =C2=A0 Requirements
=C2=A0 =C2=A0This s= pecification proposes a method to recover individual fragments between
=C2=A0 =C2=A0LLN endpoints= .
TW> add that endp= oints can be multiple hops away from one another?
=C2=A0 =C2=A0The method is designed to fit the = following
=C2=A0 =C2= =A0requirements of a LLN (with or without a Mesh-Under routing
=
=C2=A0 =C2=A0protocol):

=C2=A0 =C2=A0Number of fragments

=C2=A0 =C2=A0 =C2=A0 The recovery mechanism must suppor= t highly fragmented packets,
=C2=A0 =C2=A0 =C2=A0 with a maximum of 32 fragments per packet.
TW> resulting length of= the packet? The abstract implies a 32*74=3D2368 byte limit. Is that correc= t?

=C2=A0 =C2=A0Minimum acknowledgment = overhead



Thubert & Hui =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expi= res July 14, 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [= Page 5]
=0C
= Internet-Draft =C2=A0 =C2=A0LLN Fragment Forwarding and Recovery =C2=A0 =C2= =A0 =C2=A0January 2017


=C2=A0 =C2=A0 =C2=A0 Because the = radio is half duplex, and because of silent time spent
=C2=A0 =C2=A0 =C2=A0 in the various medium= access mechanisms, an acknowledgment
=C2=A0 =C2=A0 =C2=A0 consumes roughly as many resources as = data fragment.

=C2=A0 =C2=A0 =C2=A0 The= recovery mechanism should be able to acknowledge multiple
=C2=A0 =C2=A0 =C2=A0 fragments in a si= ngle message and not require an acknowledgment at
=C2=A0 =C2=A0 =C2=A0 all if fragments are alrea= dy protected at a lower layer.

TW> m= aybe specify here that we are talking about end-to-end ACKs between endpoin= ts, not L2 ACKs

=C2=A0 =C2=A0Controlled= latency

=C2=A0 =C2=A0 =C2=A0 The recov= ery mechanism must succeed or give up within the time
=C2=A0 =C2=A0 =C2=A0 boundary imposed by th= e recovery process of the Upper Layer
=C2=A0 =C2=A0 =C2=A0 Protocols.

=C2=A0 =C2=A0Support for out-of-order fragment delivery

=C2=A0 =C2=A0 =C2=A0 A Mesh-Under load balancing = mechanism such as the ISA100 Data Link
=C2=A0 =C2=A0 =C2=A0 Layer can introduce out-of-sequence p= ackets.
TW> I don&#= 39;t fully understand why we focus so much on mesh-under.
= TW> If you have a fully mesh-under n= etwork, 4944 fragmentation results in fragment forwarding.
TW> I would remove the repeated men= tioning on mesh-under (as well as ISA100)

=C2=A0 =C2=A0 =C2=A0 The recovery mechanism must account for packets tha= t appear lost
=C2=A0 = =C2=A0 =C2=A0 but are actually only delayed over a different path.

=C2=A0 =C2=A0Optional congestion control=

=C2=A0 =C2=A0 =C2=A0 The aggregation of multi= ple concurrent flows may lead to the
=C2=A0 =C2=A0 =C2=A0 saturation of the radio network and con= gestion collapse.

=
=C2=A0 =C2=A0 =C2=A0 = The recovery mechanism should provide means for controlling the
=C2=A0 =C2=A0 =C2=A0 number of fr= agments in transit over the LLN.

5.=C2= =A0 Overview

=C2=A0 =C2=A0Considering t= hat a multi-hop LLN can be a very sensitive environment
=C2=A0 =C2=A0due to the limited queuing c= apabilities of a large population of its
=C2=A0 =C2=A0nodes, this specification recommends a simp= le and conservative approach to
=C2=A0 =C2=A0congestion control, based on TCP congestion avoidanc= e.
TW> "based = on" or "inspired by"

TW&= gt; The "overview" section delves immediately into subtle discuss= ions about congestion control.
TW> At this point, the reader (e.g. me) have no idea what the b= asic principle is.
TW&= gt; Discussions about subtleties such as congestion control seem out of pla= ce here.

=C2=A0 =C2=A0Congestion on the= forward path is assumed in case of packet loss, and
=C2=A0 =C2=A0packet loss is assumed upon tim= e out.=C2=A0 This specification allows to control
=C2=A0 =C2=A0the number of outstanding fragment= s, that have been transmitted but
=C2=A0 =C2=A0for which an acknowledgment was not received yet.= =C2=A0 It must be noted
=C2=A0 =C2= =A0of hops in the network, but the way to figure the number of hops is
=C2=A0 =C2=A0out of scope = for this document.
=C2=A0 =C2=A0Congest= ion on the forward path can also be indicated by an Explicit
=C2=A0 =C2=A0Congestion Notification= (ECN) mechanism.=C2=A0 Though whether and how ECN
=C2=A0 =C2=A0[RFC3168] is carried out over the= LoWPAN is out of scope, this draft


Thubert & Hui =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Expires July 14, 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 6]
=0C
Internet-Draft =C2=A0 =C2=A0LLN Fragment Forwa= rding and Recovery =C2=A0 =C2=A0 =C2=A0January 2017


=C2= =A0 =C2=A0provides a way for the destination endpoint to echo an ECN indica= tion
=C2=A0 =C2=A0back= to the source endpoint in an acknowledgment message as
=C2=A0 =C2=A0represented in Figure 5 in S= ection 6.2.

TW> The following paragr= aph talks about how a link-layer transmits multiple frames in a row.=
TW> The link-layer does s= o whether those frames are fragments or regular packets.
<= font face=3D"monospace, monospace">TW> I would remove this discussion, w= hich seems to be link-layer only, and not specific to fragment forwarding.<= /font>
=C2=A0 =C2=A0
=C2=A0 =C2=A0It must be noted = that congestion and collision are different topics.
=C2=A0 =C2=A0In particular, when a mesh opera= tes on a same channel over multiple
=C2=A0 =C2=A0hops, then the forwarding of a fragment over a c= ertain hop may
=C2=A0 = =C2=A0collide with the forwarding of a next fragment that is following over=
=C2=A0 =C2=A0a previo= us hop but in a same interference domain.=C2=A0 This draft enables
=C2=A0 =C2=A0an end-to-end flo= w control, but leaves it to the sender stack to pace
=C2=A0 =C2=A0individual fragments within a t= ransmit window, so that a given
=C2=A0 =C2=A0fragment is sent only when the previous fragment has= had a chance to
=C2= =A0 =C2=A0progress beyond the interference domain of this hop.=C2=A0 In the= case of
=C2=A0 =C2=A0= 6TiSCH [I-D.ietf-6tisch-architecture], which operates over the
=
=C2=A0 =C2=A0TimeSlotted Channel H= opping [I-D.ietf-6tisch-tsch] (TSCH) mode of
=C2=A0 =C2=A0operation of IEEE802.14.5, a fragment i= s forwarded over a different
=C2=A0 =C2=A0channel at a different time and it make full sense to f= ire a next
=C2=A0 =C2= =A0fragment as soon as the previous fragment has had its chance to be
=C2=A0 =C2=A0forwarded at t= he next hop, retry (ARQ) operations included.

=C2=A0 =C2=A0From the standpoint of a source 6LoWPAN endpoint, an = outstanding
=C2=A0 =C2= =A0fragment is a fragment that was sent but for which no explicit
=C2=A0 =C2=A0acknowledgment was= received yet.=C2=A0 This means that the fragment might
=C2=A0 =C2=A0be on the way, received but = not yet acknowledged, or the
=C2=A0 =C2=A0acknowledgment might be on the way back.=C2=A0 It is al= so possible that
=C2= =A0 =C2=A0either the fragment or the acknowledgment was lost on the way.

=C2=A0 =C2=A0Because a meshed LLN might d= eliver frames out of order, it is
=C2=A0 =C2=A0virtually impossible to differentiate these situat= ions.=C2=A0 In other
= =C2=A0 =C2=A0words, from the sender's standpoint, all outstanding fragm= ents might
=C2=A0 =C2= =A0still be in the network and contribute to its congestion.=C2=A0 There is=
=C2=A0 =C2=A0an assum= ption, though, that after a certain amount of time, a frame
=C2=A0 =C2=A0is either received or lo= st, so it is not causing congestion anymore.
=C2=A0 =C2=A0This amount of time can be estimated ba= sed on the round trip delay
=C2=A0 =C2=A0between the 6LoWPAN endpoints.=C2=A0 The method detailed= in [RFC6298] is
=C2= =A0 =C2=A0recommended for that computation.

=C2=A0 =C2=A0The reader is encouraged to read through "Congestion= Control
=C2=A0 =C2=A0= Principles" [RFC2914].=C2=A0 Additionally [RFC2309] and [RFC5681] prov= ide
=C2=A0 =C2=A0deepe= r information on why this mechanism is needed and how TCP
= =C2=A0 =C2=A0handles Congestion Control= .=C2=A0 Basically, the goal here is to manage
=C2=A0 =C2=A0the amount of fragments present in t= he network; this is achieved by
=C2=A0 =C2=A0to reducing the number of outstanding fragments over= a congested path
=C2= =A0 =C2=A0by throttling the sources.

= =C2=A0 =C2=A0Section 7 describes how the sender decides how many fragments = are
=C2=A0 =C2=A0(re)s= ent before an acknowledgment is required, and how the sender
=C2=A0 =C2=A0adapts that number to t= he network conditions.



Thubert & Hui =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Expires July 14, 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 [Page 7]
=0C
Internet-Draft =C2=A0 =C2=A0LLN Fragment Forwarding and Reco= very =C2=A0 =C2=A0 =C2=A0January 2017

<= br>
6.=C2=A0 New Dispa= tch types and headers
=
=C2=A0 =C2=A0This= specification extends "Transmission of IPv6 Packets over IEEE<= /div>
=C2=A0 =C2=A0802.15.4 Network= s" [RFC4944] with 4 new dispatch types, for
=C2=A0 =C2=A0Recoverable Fragments (RFRAG) heade= rs with or without Acknowledgment
=C2=A0 =C2=A0Request, and for the Acknowledgment back, with or = without ECN Echo.

=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Pattern =C2=A0 =C2=A0Header Type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-------= -----+-----------------------------------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 11 = =C2=A0101000 | RFRAG =C2=A0 =C2=A0 =C2=A0- Recoverable Fragment =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 11 =C2=A0101001 | RFRAG-AR= =C2=A0 - RFRAG with Ack Request =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 | 11 =C2=A0101010 | RFRAG-ACK =C2=A0- RFRAG Acknowledgment =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 11 =C2=A0101011 | RFRAG= -AEC =C2=A0- RFRAG Ack with ECN Echo =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +------------+-----------------------------------------------+

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Figure 1: Additional Dispatch Value Bit Patterns

=C2=A0 =C2=A0In the following sections, the semantics o= f "datagram_tag",
=C2=A0 =C2=A0"datagram_offset" and "datagram_size"= ; and the reassembly process are
=C2=A0 =C2=A0changed from [RFC4944] Section 5.3. =C2=A0"Fra= gmentation Type and Header".
=C2=A0 =C2=A0The size and offset are expressed on the compresse= d packet per
=C2=A0 = =C2=A0[RFC6282] as opposed to the uncompressed - native packet - form.

6.1.=C2=A0 Recoverable Fragment Dispatch ty= pe and Header

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 1 2 3 4 5= 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0|1 1 1 0 1 0 0 X|data= gram_offset| =C2=A0 =C2=A0 =C2=A0 =C2=A0 datagram_tag =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
=C2=A0 = =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
=C2=A0 =C2= =A0 =C2=A0 =C2=A0|Sequence | =C2=A0 =C2=A0datagram_size =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2= =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 X set =3D=3D Ack Requested=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 2: = Recoverable Fragment Dispatch type and Header

=C2=A0 =C2=A0X: 1 bit; When set, the sender requires an Acknowledg= ment from the
=C2=A0 = =C2=A0 =C2=A0 receiver

=C2=A0 =C2=A0Seq= uence: =C2=A05 bits; The sequence number of the fragment.=C2=A0 Fragments
=C2=A0 =C2=A0 =C2=A0 ar= e numbered [0..N] where N is in [0..31].


=C2=A0 =C2=A0The specification also defines a 4-octe= t acknowledgment bitmap that
=C2=A0 =C2=A0is used to carry selective acknowledgments for the rece= ived
=C2=A0 =C2=A0frag= ments.=C2=A0 A given offset in the bitmap maps one to one with a given
=C2=A0 =C2=A0sequence numb= er.

<= div>

Thubert & Hui =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires J= uly 14, 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page = 8]
=0C
Inter= net-Draft =C2=A0 =C2=A0LLN Fragment Forwarding and Recovery =C2=A0 =C2=A0 = =C2=A0January 2017

=C2=A0 =C2=A0The offset of the bit in= the bitmap indicates which fragment is
=C2=A0 =C2=A0acknowledged as follows:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 3
=C2= =A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
=C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Acknowledgment Bit= map =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0bitmap indicating whether:
=C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--- Frag= ment with sequence 10 was received
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +----------------------- Fragment = with sequence 00 was received

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 3: Acknowledg= ment bitmap encoding
= =C2=A0 =C2=A0
TW> r= ewrote the paragraph below
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0Figure 4 shows an example Acknowledgment bitmap which indic= ates that all fragments from
=C2=A0 =C2=A0sequence 0 to 20 were received, except for fragments 1,= 2 and 16 that were
= =C2=A0 =C2=A0either lost or are still in the network over a slower path.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0|1 0 0 1 1 1 1 1|1 1 1 1 1 1 1 1|0 1 1= 1 1 0 0 0|0 0 0 0 0 0 0 0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 4: Example ac= knowledgment bitmap
=C2=A0 =C2=A0The ac= knowledgment bitmap is carried in a Fragment Acknowledgment as
=
=C2=A0 =C2=A0follows:
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|1 1 1 0 1 0 1 Y| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 datagram_tag =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Acknowledgment Bitmap (32 bits) =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2= =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 5: Fragmen= t Acknowledgment Dispatch type and Header

=C2=A0 =C2=A0Y: 1 bit; Explicit Congestion Notification (ECN) signaling<= /font>

= =C2=A0 =C2=A0 =C2=A0 When set, the send= er indicates that at least one of the
=C2=A0 =C2=A0 =C2=A0 acknowledged fragments was received wi= th an Explicit Congestion
=C2=A0 =C2=A0 =C2=A0 Notification, indicating that the path followed by= the fragments
=C2=A0 = =C2=A0 =C2=A0 is subject to congestion.

=C2=A0 =C2=A0Acknowledgment Bitmap


Thubert & Hui =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Expires July 14, 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 9]
=0C
Internet-Draft =C2=A0 =C2=A0LLN Fragment Forwa= rding and Recovery =C2=A0 =C2=A0 =C2=A0January 2017


=C2= =A0 =C2=A0 =C2=A0 An acknowledgment bitmap, whereby but at offset x indicat= es that
=C2=A0 =C2=A0 = =C2=A0 fragment x was received.

7.=C2= =A0 Fragments Recovery

=C2=A0 =C2=A0The= Recoverable Fragments header RFRAG and RFRAG-AR deprecate the
=
=C2=A0 =C2=A0original fragment hea= ders from [RFC4944] and replace them in the
=C2=A0 =C2=A0fragmented packets.
TW> are we really deprecating 4944 frag= mentation, or adding another option?
=C2=A0 =C2=A0The Fragment Acknowledgment RFRAG-ACK is=
=C2=A0 =C2=A0introduced as a= standalone header in a message that is sent back to the
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0fragment source endpoint as= known by its MAC address.=C2=A0 This assumes
=C2=A0 =C2=A0that the source MAC address in the f= ragment (if any) and datagram_tag
=C2=A0 =C2=A0are enough information to send the Fragment Acknow= ledgment back to
=C2= =A0 =C2=A0the source fragmentation endpoint.
TW> I get confused. Isn't the source MAC addr= ess changed at each hop?

=C2=A0 =C2=A0T= he 6LoWPAN endpoint that fragments the packets at the 6LoWPAN level (the
=C2=A0 =C2=A0sender) con= trols the Fragment Acknowledgments.=C2=A0 If may do that at any
=C2=A0 =C2=A0fragment to implemen= t its own policy or perform congestion control
=C2=A0 =C2=A0which is out of scope for this docum= ent.
TW> I don'= t understand the previous sentence.
=C2=A0 =C2=A0When the sender of the
=C2=A0 =C2=A0fragment knows that an underlying = mechanism protects
TW&= gt; "protects" -> "ensures delivery of"?
=C2=A0 =C2=A0the Fragments=
=C2=A0 =C2=A0already it MAY = refrain from using the Acknowledgment mechanism, and
=C2=A0 =C2=A0never set the ACK Requested bit= .=C2=A0 The 6LoWPAN endpoint that
=C2=A0 =C2=A0recomposes the packets at 6LoWPAN level (the recei= ver) MUST
=C2=A0 =C2= =A0acknowledge the fragments it has received when asked to, and MAY<= /div>
=C2=A0 =C2=A0slightly defer t= hat acknowledgment.
= =C2=A0 =C2=A0
=C2=A0 = =C2=A0The sender transfers a controlled number of fragments and MAY flag
=C2=A0 =C2=A0the last fr= agment of a series with an acknowledgment request.=C2=A0 The
=C2=A0 =C2=A0received MUST acknowled= ge a fragment with the acknowledgment request
=C2=A0 =C2=A0bit set.
TW> reword to "the receiver which receive= s a fragment with the ACK Request bit set MUST send back an acknowledgment&= quot;?
=C2=A0 =C2=A0If= any fragment immediately preceding an acknowledgment
=C2=A0 =C2=A0request is still missing, the = receiver MAY intentionally delay its
=C2=A0 =C2=A0acknowledgment to allow in-transit fragments to= arrive. Delaying the
= =C2=A0 =C2=A0acknowledgment might defeat the round trip delay computation s= o it
=C2=A0 =C2=A0shou= ld be configurable and not enabled by default.

=C2=A0 =C2=A0The receiver interacts with the sender using an Ackno= wledgment
=C2=A0 =C2= =A0message with a bitmap that indicates which fragments were actually
=C2=A0 =C2=A0received.=C2= =A0 The bitmap is a 32 bit SWORD
TW> why SWORD?
=C2=A0 =C2=A0, which accommodates up to 32
=C2=A0 =C2=A0fragments and is sufficient for th= e 6LoWPAN MTU.=C2=A0 For all n in
=C2=A0 =C2=A0[0..31], bit n is set to 1 in the bitmap to indica= te that fragment
=C2= =A0 =C2=A0with sequence n was received, otherwise the bit is set to 0.=C2= =A0 All
=C2=A0 =C2=A0z= eros is a NULL bitmap that indicates that the fragmentation process<= /div>
=C2=A0 =C2=A0was canceled by = the receiver for that datagram.

=C2=A0 = =C2=A0The receiver MAY issue unsolicited acknowledgments.=C2=A0 An unsolici= ted
=C2=A0 =C2=A0ackno= wledgment enables the sender endpoint to resume sending if it
<= div>=C2=A0 =C2=A0had reached its maximu= m number of outstanding fragments or indicate
=C2=A0 =C2=A0that the receiver has canceled the p= rocess of an individual



Thubert & Hui =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Expires July 14, 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[Page 10]
=0C
Internet-Draft =C2=A0 =C2=A0LLN Fragment Forwarding and Recovery = =C2=A0 =C2=A0 =C2=A0January 2017


=C2=A0 =C2=A0so the use= of unsolicited acknowledgments should be configurable and
=C2=A0 =C2=A0not enabled by default.

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0The sender arms a retry tim= er to cover the fragment that carries the
=C2=A0 =C2=A0Acknowledgment request.=C2=A0 Upon time ou= t, the sender assumes that all
=C2=A0 =C2=A0the fragments on the way are received or lost.=C2=A0 = The process must have
= =C2=A0 =C2=A0completed within an acceptable time that is within the boundar= ies of
=C2=A0 =C2=A0up= per layer retries.=C2=A0 The method detailed in [RFC6298] is recommended
=C2=A0 =C2=A0for the com= putation of the retry timer.=C2=A0 It is expected that the
=C2=A0 =C2=A0upper layer retries obey = the same or friendly rules in which case a
=C2=A0 =C2=A0single round of fragment recovery should = fit within the upper layer
=C2=A0 =C2=A0recovery timers.

=C2= =A0 =C2=A0Fragments are sent in a round robin fashion: the sender sends all= the
=C2=A0 =C2=A0frag= ments for a first time before it retries any lost fragment; lost
=C2=A0 =C2=A0fragments are retri= ed in sequence, oldest first.=C2=A0 This mechanism
=C2=A0 =C2=A0enables the receiver to acknowled= ge fragments that were delayed in
=C2=A0 =C2=A0the network before they are actually retried.

=C2=A0 =C2=A0When the sender decides that a= packet should be dropped and the
=C2=A0 =C2=A0fragmentation process canceled, it sends a pseudo = fragment with the
=C2= =A0 =C2=A0datagram_offset, sequence and datagram_size all set to zero, and = no
=C2=A0 =C2=A0data.= =C2=A0 Upon reception of this message, the receiver should clean up<= /div>
=C2=A0 =C2=A0all resources fo= r the packet associated to the datagram_tag.=C2=A0 If an
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0acknowledgment is requested= , the receiver responds with a NULL
=C2=A0 =C2=A0bitmap.

=C2= =A0 =C2=A0The receiver might need to cancel the process of a fragmented pac= ket
=C2=A0 =C2=A0for i= nternal reasons, for instance if it is out of recomposition
=C2=A0 =C2=A0buffers, or considers th= at this packet is already fully recomposed
=C2=A0 =C2=A0and passed to the upper layer.=C2=A0 In t= hat case, the receiver SHOULD
=C2=A0 =C2=A0indicate so to the sender with a NULL bitmap.=C2=A0 Up= on an acknowledgment
= =C2=A0 =C2=A0with a NULL bitmap, the sender MUST drop the datagram.<= /div>

8.=C2=A0 Forwarding Fragments

=C2=A0 =C2=A0This specification enables intermediate ro= uters to forward fragments
=C2=A0 =C2=A0with no intermediate reconstruction of the entire packet.= =C2=A0 Upon the
=C2=A0= =C2=A0first fragment, the routers lay a label along the path that is
=C2=A0 =C2=A0followed by th= at fragment (that is IP routed), and all further
=C2=A0 =C2=A0fragments are label switched along = that path.=C2=A0 As a consequence,
=C2=A0 =C2=A0alternate routes are not possible for individual = fragments.=C2=A0 The
= =C2=A0 =C2=A0datagram_tag is used to carry the label, that is swapped at ea= ch hop.








= Thubert & Hui =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires July 14= , 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 11]
=0C
Internet-Dr= aft =C2=A0 =C2=A0LLN Fragment Forwarding and Recovery =C2=A0 =C2=A0 =C2=A0J= anuary 2017


8.1.=C2=A0 Upon the first fragment

=C2=A0 =C2=A0In route over the L2 source changes= at each hop.
TW> s= omething's wrong with the previous sentence
=C2=A0 =C2=A0The label that is
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0formed and placed in the da= tagram_tag is associated to the source MAC
=C2=A0 =C2=A0and only valid (and unique) for that sour= ce MAC.=C2=A0 Say the first
=C2=A0 =C2=A0fragment has:

=C2=A0= =C2=A0 =C2=A0 Source IPv6 address =3D IP_A (may be multiple hops away)

=C2=A0 =C2=A0 =C2=A0 Destination IPv6 addr= ess =3D IP_B (maybe be multiple hops away)

=C2=A0 =C2=A0 =C2=A0 Source MAC =3D MAC_prv (prv as previous)

=C2=A0 =C2=A0 =C2=A0 Datagram_tag=3D DT_prv

=C2=A0 =C2=A0The intermediate router that f= orwards individual fragments does the
=C2=A0 =C2=A0following:

=C2=A0 =C2=A0 =C2=A0 a route lookup to get Next hop IPv6 towards IP_B, whi= ch resolves
=C2=A0 =C2= =A0 =C2=A0 as IP_nxt (nxt as next)

=C2= =A0 =C2=A0 =C2=A0 a MAC address resolution to get the MAC address associate= d to
=C2=A0 =C2=A0 =C2= =A0 IP_nxt, which resolves as MAC_nxt

= =C2=A0 =C2=A0Since it is a first fragment of a packet from that source MAC = address
=C2=A0 =C2=A0M= AC_prv for that tag DT_prv, the router:

=C2=A0 =C2=A0 =C2=A0 cleans up any leftover resource associated to the tup= le (MAC_prv,
=C2=A0 = =C2=A0 =C2=A0 DT_prv)
=
=C2=A0 =C2=A0 =C2= =A0 allocates a new label for that flow, DT_nxt, from a Least Recently
=C2=A0 =C2=A0 =C2=A0 Used = pool or some similar procedure.

=C2=A0 = =C2=A0 =C2=A0 allocates a Label swap structure indexed by (MAC_prv, DT_prv)= that
=C2=A0 =C2=A0 = =C2=A0 contains (MAC_nxt, DT_nxt)

=C2= =A0 =C2=A0 =C2=A0 allocates a Label swap structure indexed by (MAC_nxt, DT_= nxt) that
=C2=A0 =C2= =A0 =C2=A0 contains (MAC_prv, DT_prv)

= =C2=A0 =C2=A0 =C2=A0 swaps the MAC info to from self to MAC_nxt

=C2=A0 =C2=A0 =C2=A0 Swaps the datagram_tag to DT= _nxt

=
=C2=A0 =C2=A0At this point the rou= ter is all set and can forward the packet to
=C2=A0 =C2=A0nxt.
=C2=A0 =C2=A0
TW> this assumes the first fragment is long enough to contain= the source/destination IP addresses, right?



=



Thub= ert & Hui =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires July 14, 20= 17 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 12]<= /div>
=0C
Internet-Draft = =C2=A0 =C2=A0LLN Fragment Forwarding and Recovery =C2=A0 =C2=A0 =C2=A0Janua= ry 2017


8.2.=C2=A0 Upon the next fragments
<= div>
=C2=A0 =C2=A0Upon next fragments (that are not first= fragment), the router expects
=C2=A0 =C2=A0to have already Label swap structure indexed by (MAC_= prv, DT_prv).
=C2=A0 = =C2=A0The router:

=
=C2=A0 =C2=A0 =C2=A0 = looks up the Label swap entry for (MAC_prv, DT_prv), which
=C2=A0 =C2=A0 =C2=A0 resolves as (MAC_= nxt, DT_nxt)

=C2=A0 =C2=A0 =C2=A0 swaps= the MAC info to from self to MAC_nxt;

= =C2=A0 =C2=A0 =C2=A0 Swaps the datagram_tag to DT_nxt

=C2=A0 =C2=A0At this point the router is all set and can for= ward the packet to
=C2= =A0 =C2=A0nxt.

=C2=A0 =C2=A0if the Labe= l swap entry for (MAC_src, DT_src) is not found, the
=C2=A0 =C2=A0router builds an RFRAG-ACK to i= ndicate the error.=C2=A0 The acknowledgment
=C2=A0 =C2=A0message has the following information:

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 MAC info set to fro= m self to MAC_prv as found in the fragment
TW> "to from"?

=C2=A0 =C2=A0 =C2=A0 Swaps the datagram_tag set to DT_prv<= /div>

=C2=A0 =C2=A0 =C2=A0 Bitmap of all zeroes to i= ndicate the error

=
=C2=A0 =C2=A0At this = point the router is all set and can send the RFRAG-ACK back
=C2=A0 =C2=A0to the previous router.<= /font>

= 8.3.=C2=A0 Upon the fragment acknowledg= ments

=C2=A0 =C2=A0Upon fragment acknow= ledgments next fragments
TW> reads strange
=C2=A0 =C2=A0fragment), the router expects to have already Lab= el swap structure
=C2= =A0 =C2=A0indexed by (MAC_nxt, DT_nxt).=C2=A0 The router:
=
=C2=A0 =C2=A0 =C2=A0 looks up the Label swap entry for (= MAC_nxt, DT_nxt), which

=C2=A0 =C2=A0 =C2=A0 swaps the MAC info to from self to MAC_p= rv;

<= div>=C2=A0 =C2=A0 =C2=A0 swaps the data= gram_tag to DT_prv
=C2=A0 =C2=A0At this= point the router is all set and can forward the RFRAG-ACK to
<= div>=C2=A0 =C2=A0prv.
=
=C2=A0 =C2=A0If the Label swap entry for (MAC_nxt, DT_nx= t) is not found, it simply
=C2=A0 =C2=A0drops the packet.



Thubert & Hui =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Expires July 14, 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0[Page 13]
=0C
Internet-Draft =C2=A0 =C2=A0LLN Fragment Forwarding and Recover= y =C2=A0 =C2=A0 =C2=A0January 2017


=
=C2=A0 =C2=A0If the R= FRAG-ACK indicates either an error or that the fragment was
=C2=A0 =C2=A0fully receive, the route= r schedules the Label swap entries for
=C2=A0 =C2=A0recycling.=C2=A0 If the RFRAG-ACK is lost on = the way back, the source may
=C2=A0 =C2=A0retry the last fragments, which will result as an error= RFRAG-ACK
=C2=A0 =C2= =A0from the first router on the way that has already cleaned up.

9.=C2=A0 Security Considerations

=C2=A0 =C2=A0The process of recovering fragments does n= ot appear to create any
=C2=A0 = =C2=A0IEEE 802.15.4 Networks" [RFC4944].

10.=C2=A0 IANA Considerations

= =C2=A0 =C2=A0Need extensions for formats defined in "Transmission of I= Pv6 Packets
=C2=A0 =C2= =A0over IEEE 802.15.4 Networks" [RFC4944].

11.=C2=A0 Acknowledgments

=C2= =A0 =C2=A0The author wishes to thank Jay Werb, Christos Polyzois, Soumitri<= /font>
=C2=A0 =C2=A0Kolavennu= , Pat Kinney, Margaret Wasserman, Richard Kelsey, Carsten
= =C2=A0 =C2=A0Bormann and Harry Courtice= for their contributions and review.

12= .=C2=A0 References
12.1.=C2=A0 Normativ= e References

=C2=A0 =C2=A0[RFC2119] =C2= =A0Bradner, S., "Key words for use in RFCs to Indicate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Requirement Levels", BCP 14, RFC 2119,
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 DOI 10.17487/RFC2119, March 1997,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= ;http://www.rfc-editor.o= rg/info/rfc2119>.

=C2=A0 =C2=A0[= RFC4944] =C2=A0Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 "Transmission of IPv6 Packets over IEEE 802.1= 5.4
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Networks", RFC 4944, DOI 10.17487/RFC4= 944, September 2007,
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.rfc-editor.org/info/rfc4944>= .

=C2=A0 =C2=A0[RFC6282] =C2=A0Hui, J.,= Ed. and P. Thubert, "Compression Format for IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 DOI 10.17487/RFC6282, September 2011,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <http://ww= w.rfc-editor.org/info/rfc6282>.

= =C2=A0 =C2=A0[RFC6298] =C2=A0Paxson, V., Allman, M., Chu, J., and M. Sargen= t,
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Computing TCP's Retransmission Ti= mer", RFC 6298,
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI 10.17487/RFC6298, June= 2011,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.rfc-editor.org/info/rfc6298>.
=





Thubert & Hui =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Expires July 14, 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[Page 14]
=0C
Internet-Draft =C2=A0 =C2=A0LLN Fragment Forwarding a= nd Recovery =C2=A0 =C2=A0 =C2=A0January 2017


12.2.=C2=A0= Informative References
=C2=A0 =C2=A0[I= -D.ietf-6tisch-architecture]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thubert, P., "= An Architecture for IPv6 over the TSCH mode
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of I= EEE 802.15.4", draft-ietf-6tisch-architecture-10 (work
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 in progress), June 2016.

= =C2=A0 =C2=A0[I-D.ietf-6tisch-tsch]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Watteyne, T.= , Palattella, M., and L. Grieco, "Using
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IEE= E802.15.4e TSCH in an IoT context: Overview, Problem
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Statement and Goals", draft-ietf-6tisch-tsch-06 (work in=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 progress), March 2015.

=C2=A0 =C2=A0[RFC1191] =C2=A0Mogul, J. and S. Deering, "Path MTU = discovery", RFC 1191,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI 10.17487/RFC1191,= November 1990,
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.rfc-editor.org/info/rfc1191>.

=C2=A0 =C2=A0[RFC2309] =C2=A0Braden, B., Cl= ark, D., Crowcroft, J., Davie, B., Deering,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 S., = Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 S., Wroclawski, J., and L. Zhang, "Recommendations on
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Queue Management and Congestion Avoidance in the
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Internet", RFC 2309, DOI 10.17487/RFC2309,= April 1998,
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.rfc-editor.org/info/rfc2309>.

=C2=A0 =C2=A0[RFC2914] =C2=A0Floyd, S., &quo= t;Congestion Control Principles", BCP 41,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = RFC 2914, DOI 10.17487/RFC2914, September 2000,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = <http://www.rfc-edito= r.org/info/rfc2914>.

=C2=A0 =C2= =A0[RFC3168] =C2=A0Ramakrishnan, K., Floyd, S., and D. Black, "The Add= ition
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of Explicit Congestion Notification (ECN= ) to IP",
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 3168, DOI 10.17487/RFC3168, S= eptember 2001,
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.rfc-editor.org/info/rfc3168>.

=C2=A0 =C2=A0[RFC4919] =C2=A0Kushalnagar, N.= , Montenegro, G., and C. Schumacher, "IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = over Low-Power Wireless Personal Area Networks (6LoWPANs):
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Overview, Assumptions, Problem Statement, and Goals",
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 RFC 4919, DOI 10.17487/RFC4919, August 2007,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 <http://www.rfc-editor.org/info/rfc4919>.

=C2=A0 =C2=A0[RFC4963] =C2=A0Heffner, J., Mathis, M., and B. Chan= dler, "IPv4 Reassembly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Errors at High Data = Rates", RFC 4963,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI 10.17487/RFC4963, Jul= y 2007,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.rfc-editor.org/info/rfc4963>.
=







T= hubert & Hui =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires July 14,= 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 15]
=0C
Internet-Dra= ft =C2=A0 =C2=A0LLN Fragment Forwarding and Recovery =C2=A0 =C2=A0 =C2=A0Ja= nuary 2017

=

=C2=A0 =C2=A0[RFC5405] =C2=A0Eggert, L. and G= . Fairhurst, "Unicast UDP Usage Guidelines
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = for Application Designers", BCP 145, RFC 5405,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 DOI 10.17487/RFC5405, November 2008,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.rfc-editor.org/i= nfo/rfc5405>.
<= br>
=C2=A0 =C2=A0[RFC5= 681] =C2=A0Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Control", RFC 5681, DOI 10.17487/RFC5681, Sep= tember 2009,
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.rfc-editor.org/info/rfc5681>.

Authors' Addresses

=C2=A0 =C2=A0Pascal Thubert (editor)
=C2=A0 =C2=A0Cisco Systems, Inc
<= div>=C2=A0 =C2=A0Building D
=C2=A0 =C2=A045 Allee des Ormes -= BP1200
=C2=A0 =C2=A0M= OUGINS - Sophia Antipolis =C2=A006254
=C2=A0 =C2=A0FRANCE

=C2= =A0 =C2=A0Phone: +33 497 23 26 34
=C2=A0 =C2=A0Email: pthub= ert@cisco.com

=

=C2=A0 =C2=A0Jonathan W. Hui
=C2=A0 =C2=A0Nest Labs
=C2=A0 =C2=A03400 Hillview Ave=
=C2=A0 =C2=A0Palo Alt= o, California =C2=A094304
=C2=A0 =C2=A0USA
<= br>
=C2=A0 =C2=A0Email= : jonhui@nestlabs.com







<= br>

<= div>



=




=





Thubert & Hui =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires July 14, 2017 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 16]

-= -
_______= ________________________________

Thomas Watteyne, PhD
Rese= arch Scientist & Innovator, Inria
Sr Networking Design Eng, Linear = Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6Ti= SCH

_______________________________________
--f403043621d61ef647054bbca593-- From nobody Tue Mar 28 03:16:06 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7F2129875 for <6tisch@ietfa.amsl.com>; Tue, 28 Mar 2017 03:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_2BaneNssst for <6tisch@ietfa.amsl.com>; Tue, 28 Mar 2017 03:16:03 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F9A51296CC for <6tisch@ietf.org>; Tue, 28 Mar 2017 03:16:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,236,1486422000"; d="scan'208,217";a="218321273" Received: from mail-vk0-f52.google.com ([209.85.213.52]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 28 Mar 2017 12:15:58 +0200 Received: by mail-vk0-f52.google.com with SMTP id s68so82329971vke.3 for <6tisch@ietf.org>; Tue, 28 Mar 2017 03:15:58 -0700 (PDT) X-Gm-Message-State: AFeK/H0m53Qm40JhmNv7i8Z/0VTNF5k0e4WmjcZi1QS4yybJ0ekTiRbc+mypWV0KsB3kOXpBRQ5GIJyg1Gq38g== X-Received: by 10.176.91.137 with SMTP id y9mr11761955uae.29.1490696157127; Tue, 28 Mar 2017 03:15:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.194.149 with HTTP; Tue, 28 Mar 2017 03:15:36 -0700 (PDT) From: Thomas Watteyne Date: Tue, 28 Mar 2017 12:15:36 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=f403045f859ee9e906054bc7bea0 Archived-At: Subject: [6tisch] 6TiSCH WG meeting @IETF98 in 3h46m X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 10:16:05 -0000 --f403045f859ee9e906054bc7bea0 Content-Type: text/plain; charset=UTF-8 All, A reminder for those remote that the 6TiSCH session starts in a little less than 4 hours. You can join the live audio+video stream at https://ietf98.conf.meetecho.com/, and participate (almost) as if you were in Chicago. Thomas -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --f403045f859ee9e906054bc7bea0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

A reminder for those remote that t= he 6TiSCH session starts in a little less than 4 hours. You can join the li= ve audio+video stream at=C2=A0https://ietf98.conf.meetecho.com/, and participate (almost) as if you = were in Chicago.

Thomas

=
--
_______________________________________

Thomas Watteyne, PhD<= /font>
Research Scientist & Innovator, Inria
Sr Networking Design Eng,= Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, I= ETF 6TiSCH

________________________________= _______
--f403045f859ee9e906054bc7bea0-- From nobody Tue Mar 28 05:32:47 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38375129525 for <6tisch@ietfa.amsl.com>; Tue, 28 Mar 2017 05:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1U2RMylISuG for <6tisch@ietfa.amsl.com>; Tue, 28 Mar 2017 05:32:40 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE4E12951D for <6tisch@ietf.org>; Tue, 28 Mar 2017 05:32:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,236,1486422000"; d="scan'208,217";a="266554201" Received: from mail-vk0-f52.google.com ([209.85.213.52]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 28 Mar 2017 14:32:14 +0200 Received: by mail-vk0-f52.google.com with SMTP id d188so85632997vka.0 for <6tisch@ietf.org>; Tue, 28 Mar 2017 05:32:14 -0700 (PDT) X-Gm-Message-State: AFeK/H1Oq8b2Qk4h8NAzl1F/65Wqgfy8dAaWuI6IEMJQxkAm9Oh2NAwvIrniVfhZXmLo8u5WIH2UKwRyuZZ+zw== X-Received: by 10.31.73.6 with SMTP id w6mr6050493vka.137.1490704333395; Tue, 28 Mar 2017 05:32:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.194.149 with HTTP; Tue, 28 Mar 2017 05:31:52 -0700 (PDT) In-Reply-To: <2dae41eb-119e-ca61-617a-74b273b9ff2d@toshiba.co.jp> References: <5AC19D61-FD48-457E-AACF-7F05CD180A2F@amalfisystems.com> <2dae41eb-119e-ca61-617a-74b273b9ff2d@toshiba.co.jp> From: Thomas Watteyne Date: Tue, 28 Mar 2017 14:31:52 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Yasuyuki Tanaka Cc: "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=001a114db10a41e2df054bc9a645 Archived-At: Subject: Re: [6tisch] nits on draft-ietf-6tisch-6top-sf0-02 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 12:32:43 -0000 --001a114db10a41e2df054bc9a645 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable @Diego, @Authors, Any comments? Thomas On Sun, Mar 5, 2017 at 2:13 PM, Yasuyuki Tanaka < yasuyuki9.tanaka@toshiba.co.jp> wrote: > Nice comments! > > I also want to see the definition of "effectively used cell" and > how to calculate PDR. > > In addition, I don't think that we would count the number of > cells used for 6P in terms of SF0. Is it correct? In any case, > some text on how SF0 should handle traffic or cell usage by 6P > would be helpful. > > Best, > Yatch > > > On 2017/03/05 11:20, Randy Turner wrote: > >> Hi All, >> >> After reading the current SF0 document, I had a few nits that I thought = I >> would pass along - hope they=E2=80=99re helpful. >> >> >> Section 2: Introduction >> >> (The Scheduling Algorithm) >> >> =E2=80=9C=E2=80=A6under effective use=E2=80=A6=E2=80=9D the choice of = wording seems unorthodox. >> >> Suggest the following =E2=80=9CA portion of these allocated cells will = be >> effectively utilized by neighbors, while the remaining cells can be >> over-provisioned to handle unanticipated increases in cell requirements= =E2=80=9D >> >> (The Relocation Algorithm) >> >> =E2=80=9CAllocated cells may experiment packet loss=E2=80=9D should be = =E2=80=9CAllocated cells >> may experience packet loss=E2=80=A6=E2=80=9D >> >> >> >> Section 4: SF0 Triggering Events >> >> 1. =E2=80=9C=E2=80=A6change in the current number of used cells=E2=80=9D= - could this be >> paraphrased to say =E2=80=9C=E2=80=A6a change in the number of required = cells=E2=80=9D ? >> >> >> >> Section 5: SF0 Estimation Algorithm >> >> The Cell Estimation Algorithm steps, # 2 - What is an =E2=80=9Ceffective= ly=E2=80=9D used >> cell? Could this just say =E2=80=9CCollect the current number of used c= ells=E2=80=9D ? >> >> There is actually quite a bit of emphasis in this document on the idea o= f >> an =E2=80=9Ceffectively used cell=E2=80=9D - perhaps we should explain t= he concept of an >> effectively used cell (or a reference if it=E2=80=99s already defined) -= I was >> curious why the term =E2=80=9Ceffective=E2=80=9D is used so often? In t= he =E2=80=9CCell Estimation >> Algorithm=E2=80=9D Step #2, the text reads: >> =E2=80=9CCollect the current number of effectively used cells=E2=80=9D = =E2=80=94 which would seem >> to imply that ineffectively used cells wouldn=E2=80=99t be included in t= his step. >> This may seem a too literal interpretation, I=E2=80=99m just looking for= clarity as >> to whether or not the term =E2=80=9Ceffective=E2=80=9D or =E2=80=9Ceffec= tively=E2=80=9D is really needed in >> the doc. >> >> >> Section 11: Relocating Cells >> >> Just for completeness, I would emphasize how PDR is calculated, or >> include a reference to some other document if defined elsewhere >> >> >> >> >> Thanks for this work! >> Randy >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > --=20 _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a114db10a41e2df054bc9a645 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
@Diego, @Authors,
Any comments?
Thomas
=

On Sun, Mar= 5, 2017 at 2:13 PM, Yasuyuki Tanaka <yasuyuki9.tanaka@toshib= a.co.jp> wrote:
Nice commen= ts!

I also want to see the definition of "effectively used cell" and<= br> how to calculate PDR.

In addition, I don't think that we would count the number of
cells used for 6P in terms of SF0. Is it correct? In any case,
some text on how SF0 should handle traffic or cell usage by 6P
would be helpful.

Best,
Yatch


On 2017/03/05 11:20, Randy Turner wrote:
Hi All,

After reading the current SF0 document, I had a few nits that I thought I w= ould pass along - hope they=E2=80=99re helpful.


Section 2: Introduction

(The Scheduling Algorithm)

=E2=80=9C=E2=80=A6under effective use=E2=80=A6=E2=80=9D=C2=A0 =C2=A0the cho= ice of wording seems unorthodox.

Suggest the following=C2=A0 =E2=80=9CA portion of these allocated cells wil= l be effectively utilized by neighbors, while the remaining cells can be ov= er-provisioned to handle unanticipated increases in cell requirements=E2=80= =9D

(The Relocation Algorithm)

=E2=80=9CAllocated cells may experiment packet loss=E2=80=9D should be =E2= =80=9CAllocated cells may experience packet loss=E2=80=A6=E2=80=9D



Section 4: SF0 Triggering Events

1. =E2=80=9C=E2=80=A6change in the current number of used cells=E2=80=9D=C2= =A0 - could this be paraphrased to say =E2=80=9C=E2=80=A6a change in the nu= mber of required cells=E2=80=9D=C2=A0 ?



Section 5: SF0 Estimation Algorithm

The Cell Estimation Algorithm steps, # 2 - What is an =E2=80=9Ceffectively= =E2=80=9D used cell?=C2=A0 Could this just say =E2=80=9CCollect the current= number of used cells=E2=80=9D ?

There is actually quite a bit of emphasis in this document on the idea of a= n =E2=80=9Ceffectively used cell=E2=80=9D - perhaps we should explain the c= oncept of an effectively used cell (or a reference if it=E2=80=99s already = defined) - I was curious why the term =E2=80=9Ceffective=E2=80=9D is used s= o often?=C2=A0 In the =E2=80=9CCell Estimation Algorithm=E2=80=9D Step #2, = the text reads:
=E2=80=9CCollect the current number of effectively used cells=E2=80=9D =E2= =80=94 which would seem to imply that ineffectively used cells wouldn=E2=80= =99t be included in this step.=C2=A0 This may seem a too literal interpreta= tion, I=E2=80=99m just looking for clarity as to whether or not the term = =E2=80=9Ceffective=E2=80=9D or =E2=80=9Ceffectively=E2=80=9D is really need= ed in the doc.


Section 11: Relocating Cells

Just for completeness, I would emphasize how PDR is calculated, or include = a reference to some other document if defined elsewhere




Thanks for this work!
Randy
_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch



--
=
_______________________________________
=

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria<= /div>
Sr = Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley O= penWSN
Co-chair, IETF 6TiSCH

_____________= __________________________
--001a114db10a41e2df054bc9a645-- From nobody Tue Mar 28 05:55:36 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879E4129539 for <6tisch@ietfa.amsl.com>; Tue, 28 Mar 2017 05:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-9s-249_FGN for <6tisch@ietfa.amsl.com>; Tue, 28 Mar 2017 05:55:31 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F9F12953D for <6tisch@ietf.org>; Tue, 28 Mar 2017 05:55:09 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id u1so103963769wra.2 for <6tisch@ietf.org>; Tue, 28 Mar 2017 05:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G8E7s/Oouk5Fd3aTd3JRq+4KjNtJbkw4+ooCsFKIO/U=; b=TC/ZuWZDJbmLRchLPD5u4O1+6SPiHn86wRur5q1W6KjtSMwe4/XJu2UUbTowLdF6C0 24qVuqkwIKmCXsC4PB7kzF5Y6D5aNtLqcMyPCM8F78S2M3e45BbIToBAnZX7lUSVG/xB +dDw9m2w2Ti5y9RW/vioFxH/6E7J5im3p+K9b7sk/AnH+BE1XAAzZPZByMwWtcXW2a6j 3BuUcfmi64QhdhA69qMIepW7tDPjZHwV1MMH+xp7xVTPKgSDYfuVdw8quu9/j5n6RtBj 2jnTSt2t5bWd9BdbKxp2ydxuXE12u30WJm6/JAyFsAD5vqXLYRBAhPZds1C6oyOmi2WW 3PhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G8E7s/Oouk5Fd3aTd3JRq+4KjNtJbkw4+ooCsFKIO/U=; b=Yn58rjO+SlI0sJ1fpxKGsWf3nasuUiiUqjGtkagL+xIIG8aJzv1kCIlfbltZNo8qAO UCB9TFU0Qr3hpxLuk+kFp2LJ34fjh699vlLB/hOMge4DOEm9YD7sgj9sdIDMuWigy3Eb iTT4vJH1bT/yNVV/0lxpsKU3QG69eGo6YYXt7TrukWbUhU6ua/IJ+m0dTlKYrgRs/KRB PDSIbRpUXAE8rMj42sGeL0qs5QYqHISiWHf3VAQ0DM8fHQIR3iV/bVk6y6e+TfsAbKEp IeMS/S7tn+85H3pGwKivzQvMnEkfXigiLuRHWUPyHlKrz8NmsrbPvc6RacE4bpRbtnFs uQZg== X-Gm-Message-State: AFeK/H3Ea36aFABi6O2VbJjauImkJP+EEElejFJZKf/nboFsWo4jTQr3doil+FoK9NLG+Y2+LrLO10keTEwO9Q== X-Received: by 10.28.103.84 with SMTP id b81mr3880516wmc.124.1490705707841; Tue, 28 Mar 2017 05:55:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.163.3 with HTTP; Tue, 28 Mar 2017 05:54:47 -0700 (PDT) In-Reply-To: References: <5AC19D61-FD48-457E-AACF-7F05CD180A2F@amalfisystems.com> <2dae41eb-119e-ca61-617a-74b273b9ff2d@toshiba.co.jp> From: "Prof. Diego Dujovne" Date: Tue, 28 Mar 2017 09:54:47 -0300 Message-ID: To: Thomas Watteyne Cc: Yasuyuki Tanaka , "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=001a114b679c2e4832054bc9f8ff Archived-At: Subject: Re: [6tisch] nits on draft-ietf-6tisch-6top-sf0-02 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 12:55:35 -0000 --001a114b679c2e4832054bc9f8ff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thomas, During the last Webex I commented that I used these comments to modify and correct the draft. I eliminated (almost) every instance of "effectively used cell" and fixed the problems raised by Randy. Regards, Diego 2017-03-28 9:31 GMT-03:00 Thomas Watteyne : > @Diego, @Authors, > Any comments? > Thomas > > On Sun, Mar 5, 2017 at 2:13 PM, Yasuyuki Tanaka < > yasuyuki9.tanaka@toshiba.co.jp> wrote: > >> Nice comments! >> >> I also want to see the definition of "effectively used cell" and >> how to calculate PDR. >> >> In addition, I don't think that we would count the number of >> cells used for 6P in terms of SF0. Is it correct? In any case, >> some text on how SF0 should handle traffic or cell usage by 6P >> would be helpful. >> >> Best, >> Yatch >> >> >> On 2017/03/05 11:20, Randy Turner wrote: >> >>> Hi All, >>> >>> After reading the current SF0 document, I had a few nits that I thought >>> I would pass along - hope they=E2=80=99re helpful. >>> >>> >>> Section 2: Introduction >>> >>> (The Scheduling Algorithm) >>> >>> =E2=80=9C=E2=80=A6under effective use=E2=80=A6=E2=80=9D the choice of= wording seems unorthodox. >>> >>> Suggest the following =E2=80=9CA portion of these allocated cells will= be >>> effectively utilized by neighbors, while the remaining cells can be >>> over-provisioned to handle unanticipated increases in cell requirements= =E2=80=9D >>> >>> (The Relocation Algorithm) >>> >>> =E2=80=9CAllocated cells may experiment packet loss=E2=80=9D should be = =E2=80=9CAllocated cells >>> may experience packet loss=E2=80=A6=E2=80=9D >>> >>> >>> >>> Section 4: SF0 Triggering Events >>> >>> 1. =E2=80=9C=E2=80=A6change in the current number of used cells=E2=80= =9D - could this be >>> paraphrased to say =E2=80=9C=E2=80=A6a change in the number of required= cells=E2=80=9D ? >>> >>> >>> >>> Section 5: SF0 Estimation Algorithm >>> >>> The Cell Estimation Algorithm steps, # 2 - What is an =E2=80=9Ceffectiv= ely=E2=80=9D used >>> cell? Could this just say =E2=80=9CCollect the current number of used = cells=E2=80=9D ? >>> >>> There is actually quite a bit of emphasis in this document on the idea >>> of an =E2=80=9Ceffectively used cell=E2=80=9D - perhaps we should expla= in the concept of an >>> effectively used cell (or a reference if it=E2=80=99s already defined) = - I was >>> curious why the term =E2=80=9Ceffective=E2=80=9D is used so often? In = the =E2=80=9CCell Estimation >>> Algorithm=E2=80=9D Step #2, the text reads: >>> =E2=80=9CCollect the current number of effectively used cells=E2=80=9D = =E2=80=94 which would >>> seem to imply that ineffectively used cells wouldn=E2=80=99t be include= d in this >>> step. This may seem a too literal interpretation, I=E2=80=99m just loo= king for >>> clarity as to whether or not the term =E2=80=9Ceffective=E2=80=9D or = =E2=80=9Ceffectively=E2=80=9D is >>> really needed in the doc. >>> >>> >>> Section 11: Relocating Cells >>> >>> Just for completeness, I would emphasize how PDR is calculated, or >>> include a reference to some other document if defined elsewhere >>> >>> >>> >>> >>> Thanks for this work! >>> Randy >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> > > > > -- > _______________________________________ > > Thomas Watteyne, PhD > Research Scientist & Innovator, Inria > Sr Networking Design Eng, Linear Tech > Founder & co-lead, UC Berkeley OpenWSN > Co-chair, IETF 6TiSCH > > www.thomaswatteyne.com > _______________________________________ > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --001a114b679c2e4832054bc9f8ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thomas,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0During the last Webex I commented that
I used these comments t= o modify and correct=C2=A0
the draft. I eliminated (almost) every= instance of
"effectively used cell" and fixed the prob= lems=C2=A0
raised by Randy.
Regards,

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Diego

2017-03-28 9:31 GMT-03:00 Thomas Watteyne <thomas= .watteyne@inria.fr>:
@Diego, @Authors,
Any comments?
Thomas
=

On Sun, Mar 5, 2017 at 2:13 PM, Yasuyuki Tanaka <= ;yasuyu= ki9.tanaka@toshiba.co.jp> wrote:
Nice comments!

I also want to see the definition of "effectively used cell" and<= br> how to calculate PDR.

In addition, I don't think that we would count the number of
cells used for 6P in terms of SF0. Is it correct? In any case,
some text on how SF0 should handle traffic or cell usage by 6P
would be helpful.

Best,
Yatch


On 2017/03/05 11:20, Randy Turner wrote:
Hi All,

After reading the current SF0 document, I had a few nits that I thought I w= ould pass along - hope they=E2=80=99re helpful.


Section 2: Introduction

(The Scheduling Algorithm)

=E2=80=9C=E2=80=A6under effective use=E2=80=A6=E2=80=9D=C2=A0 =C2=A0the cho= ice of wording seems unorthodox.

Suggest the following=C2=A0 =E2=80=9CA portion of these allocated cells wil= l be effectively utilized by neighbors, while the remaining cells can be ov= er-provisioned to handle unanticipated increases in cell requirements=E2=80= =9D

(The Relocation Algorithm)

=E2=80=9CAllocated cells may experiment packet loss=E2=80=9D should be =E2= =80=9CAllocated cells may experience packet loss=E2=80=A6=E2=80=9D



Section 4: SF0 Triggering Events

1. =E2=80=9C=E2=80=A6change in the current number of used cells=E2=80=9D=C2= =A0 - could this be paraphrased to say =E2=80=9C=E2=80=A6a change in the nu= mber of required cells=E2=80=9D=C2=A0 ?



Section 5: SF0 Estimation Algorithm

The Cell Estimation Algorithm steps, # 2 - What is an =E2=80=9Ceffectively= =E2=80=9D used cell?=C2=A0 Could this just say =E2=80=9CCollect the current= number of used cells=E2=80=9D ?

There is actually quite a bit of emphasis in this document on the idea of a= n =E2=80=9Ceffectively used cell=E2=80=9D - perhaps we should explain the c= oncept of an effectively used cell (or a reference if it=E2=80=99s already = defined) - I was curious why the term =E2=80=9Ceffective=E2=80=9D is used s= o often?=C2=A0 In the =E2=80=9CCell Estimation Algorithm=E2=80=9D Step #2, = the text reads:
=E2=80=9CCollect the current number of effectively used cells=E2=80=9D =E2= =80=94 which would seem to imply that ineffectively used cells wouldn=E2=80= =99t be included in this step.=C2=A0 This may seem a too literal interpreta= tion, I=E2=80=99m just looking for clarity as to whether or not the term = =E2=80=9Ceffective=E2=80=9D or =E2=80=9Ceffectively=E2=80=9D is really need= ed in the doc.


Section 11: Relocating Cells

Just for completeness, I would emphasize how PDR is calculated, or include = a reference to some other document if defined elsewhere




Thanks for this work!
Randy
_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch



<= /div>--
_______________________________________

Thomas Watteyne, PhD
<= font face=3D"monospace, monospace">Research Scientist & Innovator, Inri= a
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC B= erkeley OpenWSN
Co-chair, IETF 6TiSCH

__= _____________________________________

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch



--
=
DIEGO DUJOVNE
Profesor Asociado
Escuela de= Inform=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Uni= versidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
--001a114b679c2e4832054bc9f8ff-- From nobody Tue Mar 28 06:42:15 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD2F129528 for <6tisch@ietfa.amsl.com>; Tue, 28 Mar 2017 06:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcFzi5CwEZK9 for <6tisch@ietfa.amsl.com>; Tue, 28 Mar 2017 06:42:10 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3FE12954A for <6tisch@ietf.org>; Tue, 28 Mar 2017 06:42:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,236,1486422000"; d="scan'208,217";a="218351276" Received: from mail-vk0-f52.google.com ([209.85.213.52]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 28 Mar 2017 15:42:07 +0200 Received: by mail-vk0-f52.google.com with SMTP id d188so88005903vka.0 for <6tisch@ietf.org>; Tue, 28 Mar 2017 06:42:07 -0700 (PDT) X-Gm-Message-State: AFeK/H3EpbOowQLmMidzSm0ydIVbwD30sVLgR7kPHVoJSFBs3/8fJgnABayUqsthniFubDRI2O2vumTEjL6Wcg== X-Received: by 10.159.48.146 with SMTP id j18mr5644149uab.156.1490708526540; Tue, 28 Mar 2017 06:42:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.194.149 with HTTP; Tue, 28 Mar 2017 06:41:45 -0700 (PDT) In-Reply-To: References: <5AC19D61-FD48-457E-AACF-7F05CD180A2F@amalfisystems.com> <2dae41eb-119e-ca61-617a-74b273b9ff2d@toshiba.co.jp> From: Thomas Watteyne Date: Tue, 28 Mar 2017 15:41:45 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "Prof. Diego Dujovne" Cc: Yasuyuki Tanaka , "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=f403045dc5ea302f5d054bcaa094 Archived-At: Subject: Re: [6tisch] nits on draft-ietf-6tisch-6top-sf0-02 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 13:42:14 -0000 --f403045dc5ea302f5d054bcaa094 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Great. So we can close this e-mail thread then. Thanks On Tue, Mar 28, 2017 at 2:54 PM, Prof. Diego Dujovne < diego.dujovne@mail.udp.cl> wrote: > Thomas, > During the last Webex I commented that > I used these comments to modify and correct > the draft. I eliminated (almost) every instance of > "effectively used cell" and fixed the problems > raised by Randy. > Regards, > > Diego > > 2017-03-28 9:31 GMT-03:00 Thomas Watteyne : > >> @Diego, @Authors, >> Any comments? >> Thomas >> >> On Sun, Mar 5, 2017 at 2:13 PM, Yasuyuki Tanaka < >> yasuyuki9.tanaka@toshiba.co.jp> wrote: >> >>> Nice comments! >>> >>> I also want to see the definition of "effectively used cell" and >>> how to calculate PDR. >>> >>> In addition, I don't think that we would count the number of >>> cells used for 6P in terms of SF0. Is it correct? In any case, >>> some text on how SF0 should handle traffic or cell usage by 6P >>> would be helpful. >>> >>> Best, >>> Yatch >>> >>> >>> On 2017/03/05 11:20, Randy Turner wrote: >>> >>>> Hi All, >>>> >>>> After reading the current SF0 document, I had a few nits that I though= t >>>> I would pass along - hope they=E2=80=99re helpful. >>>> >>>> >>>> Section 2: Introduction >>>> >>>> (The Scheduling Algorithm) >>>> >>>> =E2=80=9C=E2=80=A6under effective use=E2=80=A6=E2=80=9D the choice o= f wording seems unorthodox. >>>> >>>> Suggest the following =E2=80=9CA portion of these allocated cells wil= l be >>>> effectively utilized by neighbors, while the remaining cells can be >>>> over-provisioned to handle unanticipated increases in cell requirement= s=E2=80=9D >>>> >>>> (The Relocation Algorithm) >>>> >>>> =E2=80=9CAllocated cells may experiment packet loss=E2=80=9D should be= =E2=80=9CAllocated cells >>>> may experience packet loss=E2=80=A6=E2=80=9D >>>> >>>> >>>> >>>> Section 4: SF0 Triggering Events >>>> >>>> 1. =E2=80=9C=E2=80=A6change in the current number of used cells=E2=80= =9D - could this be >>>> paraphrased to say =E2=80=9C=E2=80=A6a change in the number of require= d cells=E2=80=9D ? >>>> >>>> >>>> >>>> Section 5: SF0 Estimation Algorithm >>>> >>>> The Cell Estimation Algorithm steps, # 2 - What is an =E2=80=9Ceffecti= vely=E2=80=9D >>>> used cell? Could this just say =E2=80=9CCollect the current number of= used cells=E2=80=9D ? >>>> >>>> There is actually quite a bit of emphasis in this document on the idea >>>> of an =E2=80=9Ceffectively used cell=E2=80=9D - perhaps we should expl= ain the concept of an >>>> effectively used cell (or a reference if it=E2=80=99s already defined)= - I was >>>> curious why the term =E2=80=9Ceffective=E2=80=9D is used so often? In= the =E2=80=9CCell Estimation >>>> Algorithm=E2=80=9D Step #2, the text reads: >>>> =E2=80=9CCollect the current number of effectively used cells=E2=80=9D= =E2=80=94 which would >>>> seem to imply that ineffectively used cells wouldn=E2=80=99t be includ= ed in this >>>> step. This may seem a too literal interpretation, I=E2=80=99m just lo= oking for >>>> clarity as to whether or not the term =E2=80=9Ceffective=E2=80=9D or = =E2=80=9Ceffectively=E2=80=9D is >>>> really needed in the doc. >>>> >>>> >>>> Section 11: Relocating Cells >>>> >>>> Just for completeness, I would emphasize how PDR is calculated, or >>>> include a reference to some other document if defined elsewhere >>>> >>>> >>>> >>>> >>>> Thanks for this work! >>>> Randy >>>> _______________________________________________ >>>> 6tisch mailing list >>>> 6tisch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >> >> >> >> -- >> _______________________________________ >> >> Thomas Watteyne, PhD >> Research Scientist & Innovator, Inria >> Sr Networking Design Eng, Linear Tech >> Founder & co-lead, UC Berkeley OpenWSN >> Co-chair, IETF 6TiSCH >> >> www.thomaswatteyne.com >> _______________________________________ >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> > > > -- > DIEGO DUJOVNE > Profesor Asociado > Escuela de Inform=C3=A1tica y Telecomunicaciones > Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile > www.ingenieria.udp.cl > (56 2) 676 8125 > --=20 _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --f403045dc5ea302f5d054bcaa094 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great. So we can close this e-mail thread then.
Thanks=

On Tu= e, Mar 28, 2017 at 2:54 PM, Prof. Diego Dujovne <diego.dujovne@mai= l.udp.cl> wrote:
Thomas,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0During= the last Webex I commented that
I used these comments to modify = and correct=C2=A0
the draft. I eliminated (almost) every instance= of
"effectively used cell" and fixed the problems=C2= =A0
raised by Randy.
Regards,

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Diego

2017-03-28 9:31 GMT-03:00 Thomas Watteyne= <thomas.watteyne@inria.fr>:
@Diego, @Authors,
Any comments?
Thomas

On Sun, Mar 5, 2017 at 2:13= PM, Yasuyuki Tanaka <yasuyuki9.tanaka@toshiba.co.jp= > wrote:
Nice comments!

I also want to see the definition of "effectively used cell" and<= br> how to calculate PDR.

In addition, I don't think that we would count the number of
cells used for 6P in terms of SF0. Is it correct? In any case,
some text on how SF0 should handle traffic or cell usage by 6P
would be helpful.

Best,
Yatch


On 2017/03/05 11:20, Randy Turner wrote:
Hi All,

After reading the current SF0 document, I had a few nits that I thought I w= ould pass along - hope they=E2=80=99re helpful.


Section 2: Introduction

(The Scheduling Algorithm)

=E2=80=9C=E2=80=A6under effective use=E2=80=A6=E2=80=9D=C2=A0 =C2=A0the cho= ice of wording seems unorthodox.

Suggest the following=C2=A0 =E2=80=9CA portion of these allocated cells wil= l be effectively utilized by neighbors, while the remaining cells can be ov= er-provisioned to handle unanticipated increases in cell requirements=E2=80= =9D

(The Relocation Algorithm)

=E2=80=9CAllocated cells may experiment packet loss=E2=80=9D should be =E2= =80=9CAllocated cells may experience packet loss=E2=80=A6=E2=80=9D



Section 4: SF0 Triggering Events

1. =E2=80=9C=E2=80=A6change in the current number of used cells=E2=80=9D=C2= =A0 - could this be paraphrased to say =E2=80=9C=E2=80=A6a change in the nu= mber of required cells=E2=80=9D=C2=A0 ?



Section 5: SF0 Estimation Algorithm

The Cell Estimation Algorithm steps, # 2 - What is an =E2=80=9Ceffectively= =E2=80=9D used cell?=C2=A0 Could this just say =E2=80=9CCollect the current= number of used cells=E2=80=9D ?

There is actually quite a bit of emphasis in this document on the idea of a= n =E2=80=9Ceffectively used cell=E2=80=9D - perhaps we should explain the c= oncept of an effectively used cell (or a reference if it=E2=80=99s already = defined) - I was curious why the term =E2=80=9Ceffective=E2=80=9D is used s= o often?=C2=A0 In the =E2=80=9CCell Estimation Algorithm=E2=80=9D Step #2, = the text reads:
=E2=80=9CCollect the current number of effectively used cells=E2=80=9D =E2= =80=94 which would seem to imply that ineffectively used cells wouldn=E2=80= =99t be included in this step.=C2=A0 This may seem a too literal interpreta= tion, I=E2=80=99m just looking for clarity as to whether or not the term = =E2=80=9Ceffective=E2=80=9D or =E2=80=9Ceffectively=E2=80=9D is really need= ed in the doc.


Section 11: Relocating Cells

Just for completeness, I would emphasize how PDR is calculated, or include = a reference to some other document if defined elsewhere




Thanks for this work!
Randy
_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch



<= /div>-= -
____= ___________________________________

Thomas Watteyne, PhD<= /font>
Research Scientist & Innovator, Inria
Sr Networking Design Eng,= Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, I= ETF 6TiSCH

_______________________________________

_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch



--
DIEGO DUJOVNE<= br>Profesor Asociado
Escuela de Inform=C3=A1tica y TelecomunicacionesFacultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile
www.ingenieria.udp.cl<= /a>
(56 2) 676 8125



--
--f403045dc5ea302f5d054bcaa094-- From nobody Tue Mar 28 08:16:39 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F93128B88; Tue, 28 Mar 2017 08:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbchvcsHQueb; Tue, 28 Mar 2017 08:16:31 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8071D1289C3; Tue, 28 Mar 2017 08:16:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,236,1486422000"; d="scan'208,217";a="266587654" Received: from mail-vk0-f45.google.com ([209.85.213.45]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 28 Mar 2017 17:16:28 +0200 Received: by mail-vk0-f45.google.com with SMTP id r69so91824403vke.2; Tue, 28 Mar 2017 08:16:28 -0700 (PDT) X-Gm-Message-State: AFeK/H2UEZLQMhVbQsoJc+AMUYUj7XGzC2hv5oo3v6hVn9mh7FVly7koBNv8MuPAwZV6n02F+EdccoBabodAOw== X-Received: by 10.31.73.6 with SMTP id w6mr6369016vka.137.1490714187087; Tue, 28 Mar 2017 08:16:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.194.149 with HTTP; Tue, 28 Mar 2017 08:16:06 -0700 (PDT) From: Thomas Watteyne Date: Tue, 28 Mar 2017 17:16:06 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Content-Type: multipart/alternative; boundary=001a114db10a954ac8054bcbf154 Archived-At: Subject: [6tisch] IP-IP-IP example? X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 15:16:33 -0000 --001a114db10a954ac8054bcbf154 Content-Type: text/plain; charset=UTF-8 Michael, We just discussed IP-IP-IP versus CoAP at the 6TiSCH WG meeting. I stated that: - with IP-IP-IP, all nodes in the network would need to know at least the global and link-local IPv6 addresses of the JRC, as well as the IPv6 address of the LBR. - With the CoAP proxy option, we could use (well-known?) 6LoWPAN contexts and hostnames to avoid that. You stated that my statement 1 was not correct. Could we draw up an example with all the addresses in the IP-IP-IP case, and what exactly the Pledge and Join Proxy need to know before being able to join? Thanks, Thomas --001a114db10a954ac8054bcbf154 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael,

We just discussed IP-IP-IP ver= sus CoAP at the 6TiSCH WG meeting.

I stated that:<= /div>
- with IP-IP-IP, all nodes in the network would need to know at l= east the global and link-local IPv6 addresses of the JRC, as well as the IP= v6 address of the LBR.
- With the CoAP proxy option, we could use= (well-known?) 6LoWPAN contexts and hostnames to avoid that.

=
You stated that my statement 1 was not correct. Could we draw up= an example with all the addresses in the IP-IP-IP case, and what exactly t= he Pledge and Join Proxy need to know before being able to join?
=
Thanks,
Thomas
--001a114db10a954ac8054bcbf154-- From nobody Tue Mar 28 09:15:58 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5935712953A; Tue, 28 Mar 2017 09:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXbcaOw8BvDx; Tue, 28 Mar 2017 09:15:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D010712965B; Tue, 28 Mar 2017 09:15:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E7860200A3; Tue, 28 Mar 2017 12:39:33 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 611D2636E0; Tue, 28 Mar 2017 12:15:42 -0400 (EDT) From: Michael Richardson reply-To: "6tisch\@ietf.org" <6tisch@ietf.org> To: "6tisch\@ietf.org" <6tisch@ietf.org>, "6tisch-security\@ietf.org" <6tisch-security@ietf.org> In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [6tisch] [6tisch-security] IP-IP-IP example? X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:15:51 -0000 --=-=-= Content-Type: text/plain Thomas Watteyne wrote: > - with IP-IP-IP, all nodes in the network would need to know at least > the global and link-local IPv6 addresses of the JRC, as well as the > IPv6 address of the LBR. You write "all-nodes", but can we agree that it's only the Join Proxy? The Join Proxy needs to know an address to which to forward the join traffic, regardless of whether or not it is IPIP(IP) or CoAP. I don't see how it matters what which. The JP has to know that address. That address could be an IPv6 anycast address; it could be provisioned via some other mechanism. In the IPIP case, the pledge should ideally send to an address which the JRC recognizes are local. Any IPv6 LL-anycast address would work well for this. That can also be done in the CoAP proxy method as well. > - With the CoAP proxy option, we could use (well-known?) 6LoWPAN > contexts and hostnames to avoid that. I agree that using a 6lo context would be a good idea here. It seems that it can also be used with either method. I will write some examples today and post. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljajC4ACgkQgItw+93Q 3WVw3Af/WsM4ocOPktjV2PaAV2KePotBmzIizKSJkqF+4L5xxzGx31cwt3IqTEmx wTsaiI6KuaFeFIRTXmJeZJSbXViCGL6ehz3GUOUx1eBfDPen0spS86F8l6YuNE7H 5Mzr2DvE2wN+TaowzDL4LFDxXawI5S9p081QAmxxlbBcSORHWXu74Dzp2TNd2nad RqrUGI/uh3cpBLApLZqx0zybtprkvpYxJ9RikCyYUdM8KRY8Gf6B1YnI5XWvLoUq xxxUluoVftm4yEOT0hRHs/nAoOGqZZiEyVlK+jsZ1aYIZpMOdO3lxYvJB32BSXcr shN3jDa+/JiEK+4q0/8jr6rym5UTqQ== =EioJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 29 02:09:28 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF00129545; Wed, 29 Mar 2017 02:09:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: 6tisch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149077856186.1259.11616583413445539309@ietfa.amsl.com> Date: Wed, 29 Mar 2017 02:09:21 -0700 Archived-At: Subject: [6tisch] I-D Action: draft-ietf-6tisch-6top-protocol-04.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 09:09:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e of the IETF. Title : 6top Protocol (6P) Authors : Qin Wang Xavier Vilajosana Thomas Watteyne Filename : draft-ietf-6tisch-6top-protocol-04.txt Pages : 37 Date : 2017-03-29 Abstract: This document defines the 6top Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete TSCH cells to one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer to the IEEE Std 802.15.4 TSCH medium access control layer. The 6top Scheduling Function (SF) decides when to add/delete cells, and triggers 6P Transactions. Several SFs can be defined, each identified by a different 6top Scheduling Function Identifier (SFID). This document lists the requirements for an SF, but leaves the definition of the SF out of scope. Different SFs are expected to be defined in future companion specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-04 https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-6top-protocol-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-6top-protocol-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 30 13:17:43 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EC6129469; Thu, 30 Mar 2017 13:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96cxaFcejAz7; Thu, 30 Mar 2017 13:17:39 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B430C126B72; Thu, 30 Mar 2017 13:17:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A0E54200A3; Thu, 30 Mar 2017 16:41:36 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 929A8636BB; Thu, 30 Mar 2017 16:17:37 -0400 (EDT) From: Michael Richardson To: Thomas Watteyne cc: "6tisch\@ietf.org" <6tisch@ietf.org>, "6tisch-security\@ietf.org" <6tisch-security@ietf.org> In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [6tisch] [6tisch-security] IP-IP-IP example? X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 20:17:42 -0000 --=-=-= Content-Type: text/plain Thomas, here is an example of a join message header, as seen on the join side between pledge and Join Proxy. Please let me know how I can make this more complete for your code. If you want hex dump, I'll do that, but I'll have to create a full topology with some addresses. Let me do a second email for CoAP proxy example, once you are happy with this presentation. I don't have a good idea for size of OSCOAP pieces, I will pull those out. L2: srcmac=ab-cd-12-34-56-78-ab-cd dstmac=88-88-aa-bb-cc-dd-ee-ff IPv6: ver=6 tc=0 flowid=0 src=fe80::abcd:1234:5678:abcd dst=fe80::0 nh=17 UDP: srcport=1234 <- could be a constant? dstport=TBD <- we could ask for a port, or use 5683 ULP: OSCOAP stuff. Travelling from Join Proxy to root/JRC using IPIP(IP): L2: srcmac=ee-ff (2-byte, assigned short-address) dstmac=next-hop-l2 IPv6: ver=6 tc=0 flowid=0 src=2001:db8::eeff dst=2001:db8::0001 (assume JRC got assigned short-address 0001) nh=41 RPI header: rank=X, instanceID=Y IPv6: ver=6 tc=0 flowid=0 src=fe80::abcd:1234:5678:abcd dst=fe80::0 UDP: srcport=1234 dstport=TBD ULP: OSCOAP stuff. Travelling from root/JRC to Join Proxy using IPIP(IP), if JRC is co-located in the DODAG root: L2: srcmac=next-hop-l2 dstmac=ee-ff IPv6: ver=6 tc=0 flowid=0 src=2001:db8::0001 dst=2001:db8::eeff nh=41 RPI header: rank=X, instanceID=Y RH3 header: X hops (do you want me to fill this in?) IPv6: ver=6 tc=0 flowid=0 src=fe80::abcd:1234:5678:abcd dst=fe80::0 UDP: srcport=1234 dstport=TBD ULP: OSCOAP stuff. Travelling from root/JRC to Join Proxy using IPIP(IP), if JRC is NOT co-located. in the DODAG root. JRC is now 2001:db8:1::abcd. L2: srcmac=next-hop-l2 dstmac=ee-ff IPv6: ver=6 tc=0 flowid=0 src=2001:db8::0001 dst=2001:db8::eeff nh=41 RPI header: rank=X, instanceID=Y RH3 header: X hops (do you want me to fill this in?) IPv6: ver=6 tc=0 flowid=0 src=2001:db8:1::abcd dst=2001:db8::eeff nh=41 IPv6: ver=6 tc=0 flowid=0 src=fe80::abcd:1234:5678:abcd dst=fe80::0 UDP: srcport=1234 dstport=TBD ULP: OSCOAP stuff. Link-Local anycast: https://tools.ietf.org/html/rfc4291#section-2.6 as far as I can tell, we can make up our own LL-anycast, but we could reasonably also use fe80::0 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljdZ+EACgkQgItw+93Q 3WVhPQf/Z8vO8JpsH/ja9IGcqSK2WVkQbpkPU53GasybgYdNc4jJZoObGRTepCUA m5mCTpo0c0+nMB8iTQevO+LEjnO8Swhwfz1sCRhoLfSVCt7pbzFLqy22VRL+Z5Aq LAUmQ5N9hoX34e9gWaLBCVfdPH+luqAVzx/k/30y7ceiKgoVVguLQXusv4z+yx42 DhRRNX0iSMtSMV9+vZF+Tnj6KoKa8/7YV6LSy45YmmoWUjH+QFkk6/4HftxJcoWq 5RlSbyNROExraxAjwQI9CrZl879S78K7dzGXYvZkqDoHahxaD0vwoFz3c+4k1M4J /e2zF95xqn9w1TPPDRWQ4trLWgLfGA== =yU4t -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 30 21:45:22 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E35127F0E; Thu, 30 Mar 2017 21:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYLuK5FolUdk; Thu, 30 Mar 2017 21:45:13 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B10127286; Thu, 30 Mar 2017 21:45:13 -0700 (PDT) X-AuditID: c1b4fb30-3dbff7000000628e-19-58ddded6e3dc Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 99.A9.25230.6DEDDD85; Fri, 31 Mar 2017 06:45:11 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.125]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0339.000; Fri, 31 Mar 2017 06:45:36 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Michael Richardson CC: Thomas Watteyne , "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: [6tisch] [6tisch-security] IP-IP-IP example? Thread-Index: AQHSp9ZZlc6sGqDRW0ie53KaWu2hSKGttCWAgACNzAA= Date: Fri, 31 Mar 2017 04:45:09 +0000 Message-ID: References: <11574.1490905057@obiwan.sandelman.ca> In-Reply-To: <11574.1490905057@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-593801AB-F1A3-4E94-845C-B78154849023"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUyM2K7q+71e3cjDJ4uV7BoXrmI3WLZ3T5m i55D/ewWR1+/Z3Jg8Viy5CeTx6QXh1g8WubsYQ5gjuKySUnNySxLLdK3S+DKWDh3PXPBi8iK 5ndGDYwTwrsYOTkkBEwkFl99wdzFyMUhJLCeUeJLXycjhLOEUeLls2XMIFVsAi4SDxoeMYHY IgJ6EsuPPAMrYhboYZRY8mAtWJGwgKXEqesboYqsJDZuP8kCY296f5AVxGYRUJV43P8OrJ5X wF6iZ+02NhBbSKBSomnnF6BeDg5OAWOJPS+tQMKMAmIS30+tARvJLCAucevJfCaIq0UkHl48 zQZhi0q8fPyPFeKeyYxA8xdDzReUODnzCcsERuFZSPpnIaubhaQOoihe4tebF6wQtrzE9rdz mCFsTYn93cuhahQlpnQ/ZIewNSQ6v01kxRS3lpjx6yAbhG0q8froR0ZkNQsYeVYxihanFifl phsZ6aUWZSYXF+fn6eWllmxiBEb2wS2/DXYwvnzueIhRgINRiYd3gfvdCCHWxLLiytxDjCpA cx5tWH2BUYolLz8vVUmEV24fUJo3JbGyKrUoP76oNCe1+BCjNAeLkjiv474LEUIC6Yklqdmp qQWpRTBZJg5OqQbGwOR3cXcXdR+6n5W+qvbGTyntCZeUWXvWLq2LVT524DGT8ccys0m7pjsx 6p36/XGNRHN6zr+SJKlT0svkdPrDmeLu8zho7Li2IDEy2d3iQubPFUvmhulOzt1aeOTJXy7b Z6/8v81qqOey5N+x0uDdlZ87Z00w3qj4pfmca2DklPcpb11cgxbGKLEUZyQaajEXFScCAJmn NVX0AgAA Archived-At: Subject: Re: [6tisch] [6tisch-security] IP-IP-IP example? X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 04:45:16 -0000 --Apple-Mail-593801AB-F1A3-4E94-845C-B78154849023 Content-Type: multipart/alternative; boundary=Apple-Mail-63B59689-3FDB-475F-93BA-FE2F26022756 Content-Transfer-Encoding: 7bit --Apple-Mail-63B59689-3FDB-475F-93BA-FE2F26022756 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgTWljaGFlbCwNCg0KDQo+IE9uIDMwIE1hciAyMDE3LCBhdCAyMjoxNywgTWljaGFlbCBSaWNo YXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiANCj4gDQo+IFRob21hcywg aGVyZSBpcyBhbiBleGFtcGxlIG9mIGEgam9pbiBtZXNzYWdlIGhlYWRlciwgYXMgc2VlbiBvbiB0 aGUgam9pbg0KPiBzaWRlIGJldHdlZW4gcGxlZGdlIGFuZCBKb2luIFByb3h5LiAgUGxlYXNlIGxl dCBtZSBrbm93IGhvdyBJIGNhbiBtYWtlIHRoaXMNCj4gbW9yZSBjb21wbGV0ZSBmb3IgeW91ciBj b2RlLiBJZiB5b3Ugd2FudCBoZXggZHVtcCwgSSdsbCBkbyB0aGF0LCBidXQgSSdsbA0KPiBoYXZl IHRvIGNyZWF0ZSBhIGZ1bGwgdG9wb2xvZ3kgd2l0aCBzb21lIGFkZHJlc3Nlcy4NCj4gDQo+IExl dCBtZSBkbyBhIHNlY29uZCBlbWFpbCBmb3IgQ29BUCBwcm94eSBleGFtcGxlLCBvbmNlIHlvdSBh cmUgaGFwcHkNCj4gd2l0aCB0aGlzIHByZXNlbnRhdGlvbi4gSSBkb24ndCBoYXZlIGEgZ29vZCBp ZGVhIGZvciBzaXplIG9mIE9TQ09BUCBwaWVjZXMsIEkNCj4gd2lsbCBwdWxsIHRob3NlIG91dC4N Cg0KVGhlcmUgaXMgYSBuZXcgZHJhZnQgd2l0aCBtZXNzYWdlIG92ZXJoZWFkIGNhbGN1bGF0aW9u cyBmb3IgQ29BUCBzZWN1cml0eSBwcm90b2NvbHMgKERUTFMvVExTL09TQ09BUCkuIA0KDQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWF0dHNzb24tY29yZS1zZWN1cml0eS1vdmVy aGVhZC0wMA0KDQpTZWUgRmlndXJlIDEgYXQgdGhlIGVuZCBvZiB0aGUgZG9jdW1lbnQgZm9yIGEg Y29tcGlsYXRpb24gb2YgdGhlIHJlc3VsdHMuIA0KDQpJdCB3YXNuJ3QgcHJlc2VudGVkIGluIHRo ZSBDb1JFIFdHIG9uIFR1ZXNkYXkgb3V0IG9mIGxhY2sgb2YgdGltZSwgc28gSSB0aGluayBpdCBp cyBmaXJzdCBvbiB0aGUgYWdlbmRhIGZvciB0aGUgRnJpZGF5IG1lZXRpbmcuIA0KDQpHw7ZyYW4= --Apple-Mail-63B59689-3FDB-475F-93BA-FE2F26022756 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PC9kaXY+ PGRpdj5IaSBNaWNoYWVsLDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPk9uIDMwIE1hciAy MDE3LCBhdCAyMjoxNywgTWljaGFlbCBSaWNoYXJkc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNy K2lldGZAc2FuZGVsbWFuLmNhIj5tY3IraWV0ZkBzYW5kZWxtYW4uY2E8L2E+Jmd0OyB3cm90ZTo8 YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+PC9zcGFuPjxi cj48c3Bhbj5UaG9tYXMsIGhlcmUgaXMgYW4gZXhhbXBsZSBvZiBhIGpvaW4gbWVzc2FnZSBoZWFk ZXIsIGFzIHNlZW4gb24gdGhlIGpvaW48L3NwYW4+PGJyPjxzcGFuPnNpZGUgYmV0d2VlbiBwbGVk Z2UgYW5kIEpvaW4gUHJveHkuICZuYnNwO1BsZWFzZSBsZXQgbWUga25vdyBob3cgSSBjYW4gbWFr ZSB0aGlzPC9zcGFuPjxicj48c3Bhbj5tb3JlIGNvbXBsZXRlIGZvciB5b3VyIGNvZGUuIElmIHlv dSB3YW50IGhleCBkdW1wLCBJJ2xsIGRvIHRoYXQsIGJ1dCBJJ2xsPC9zcGFuPjxicj48c3Bhbj5o YXZlIHRvIGNyZWF0ZSBhIGZ1bGwgdG9wb2xvZ3kgd2l0aCBzb21lIGFkZHJlc3Nlcy48L3NwYW4+ PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+TGV0IG1lIGRvIGEgc2Vjb25kIGVtYWlsIGZvciBD b0FQIHByb3h5IGV4YW1wbGUsIG9uY2UgeW91IGFyZSBoYXBweTwvc3Bhbj48YnI+PHNwYW4+d2l0 aCB0aGlzIHByZXNlbnRhdGlvbi4gSSBkb24ndCBoYXZlIGEgZ29vZCBpZGVhIGZvciBzaXplIG9m IE9TQ09BUCBwaWVjZXMsIEk8L3NwYW4+PGJyPjxzcGFuPndpbGwgcHVsbCB0aG9zZSBvdXQuPC9z cGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGVyZSBpcyBh IG5ldyBkcmFmdCB3aXRoIG1lc3NhZ2Ugb3ZlcmhlYWQgY2FsY3VsYXRpb25zIGZvciBDb0FQIHNl Y3VyaXR5IHByb3RvY29scyAoRFRMUy9UTFMvT1NDT0FQKS4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0 c3Nvbi1jb3JlLXNlY3VyaXR5LW92ZXJoZWFkLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbWF0dHNzb24tY29yZS1zZWN1cml0eS1vdmVyaGVhZC0wMDwvYT48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PlNlZSBGaWd1cmUgMSBhdCB0aGUgZW5kIG9mIHRoZSBkb2N1bWVudCBm b3IgYSBjb21waWxhdGlvbiBvZiB0aGUgcmVzdWx0cy4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2Pkl0IHdhc24ndCBwcmVzZW50ZWQgaW4gdGhlIENvUkUgV0cgb24gVHVlc2RheSBvdXQg b2YgbGFjayBvZiB0aW1lLCBzbyBJIHRoaW5rIGl0IGlzIGZpcnN0IG9uIHRoZSBhZ2VuZGEgZm9y IHRoZSBGcmlkYXkgbWVldGluZy4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkfDtnJh bjwvZGl2PjwvYm9keT48L2h0bWw+ --Apple-Mail-63B59689-3FDB-475F-93BA-FE2F26022756-- --Apple-Mail-593801AB-F1A3-4E94-845C-B78154849023 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR7DCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF8jCCA9qgAwIBAgIQPmPdJI0I/Fh4Z0IWiX4FyTAN BgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MjAeFw0xNDEyMjIwOTI2MTRaFw0xNzEyMjIwOTI2MTNaMGsxETAPBgNV BAoMCEVyaWNzc29uMRgwFgYDVQQDDA9Hw7ZyYW4gU2VsYW5kZXIxKjAoBgkqhkiG9w0BCQEWG2dv cmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbTEQMA4GA1UEBRMHZXJhZ29zZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAJJTmaZN/AJeYDz6jrMPRAFTMd1Ijw2eHX8gmp1QI0yxcaHKHXdU HR9v92W8bE24UrsQrMoCZXngRVqMv4VG5yDF6f2VwLtunh/Wp3dq72SA5dgrMe7D1u1HXG6pYb5+ /OtkZpIC3Zt7Bl6dpmfJlbGhf2juJrZm+JaS2vR+sGVdyKinIiUyciBngPh6J/jvCVxf9k8BNi+b 4CR0gfr8+qRj/wKrcUwgti+tG87lfWmvPK4sf52y64RNR4ZtsdCtT4LYMomcTrFWbgr2dcG+lx+R 0pVC6qqDs7vVJ3VBEPK3oEJeOtJnimtHL+fboNToUxwifYOR5d1aebxKnHGgT/MCAwEAAaOCAcEw ggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29u bmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDov L29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlh c29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY2VyMCYGA1UdEQQfMB2BG2dvcmFu LnNlbGFuZGVyQGVyaWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsG AQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFIHidNufe3WwHbOEvGidlbceG/3/ MB8GA1UdIwQYMBaAFLENytRGt6+GAsMvbwbKDnZxf0s3MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG 9w0BAQUFAAOCAgEA1JVNvEJtJx5cKn+1f5QKWgHmrlQjvjdDm8pX6H5MHzpxoaccG4G0dq1UlMP+ T6bK3z4H4i7rQzZStfeAGbBJNbpjwxmG1diKM4w4+8pXKoeR/2KRUxYMEob5vo71QH4Sia1x9ntw SVcK78CNdbhDsJlZXA+sk5Et5zqZ8RH26xgRrQ7H6Z5ZbmxEMpUdMWBWCy5vf7ii7OA5CmyoatDJ 1iGi8im009qVYZJJMxilb6vqu6RJD+xSOXnikIBJmPnOz2ZC71+FG2bgj70dwE1J7X7KroQJbRm9 zzbKdhMXHfDQCu3WGaad3t64zXsnOk5GuHfLTsN7LTBzdGg/jPghI19+wL7P6NUyXngfU9hiIO4e I9/5wyiuUxcU+zutMWBlL+ZjUHa/6pk/072TiL+Dgc9CWwmCdbELlNaW4yw4fNBLfkVH6h6L/flo PA1i90+LF5Y2FSaRHi+1/J2Oktb7d4rLFx/Qd/9JUm7MxiueywEV76Ng0Ylga904WMkV9+ooJxGh wnSXbkAtNUO2/eSllqnphldoEB5hOdwZZXK/215uG0gtV2qU7uwu0/fMAZnjps9Nb/ngXtM7Bn6R 8jS+m0WAk3mIADwbA6+EFq2s3D2gD10zaKgCUFuIPeBDwXPszGr/kCSlJ23cbPF3sc3CGLkYiS7I +2rVTsH+jX0pYLswgga2MIIEnqADAgECAhEAoAzLzJuZmOziOnD0fMHAWTANBgkqhkiG9w0BAQUF ADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2 MTAeFw0xNDA1MjcwNzQ2MjFaFw0yNDA1MjcwNzQ2MjFaMDoxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMIICIjANBgkqhkiG9w0BAQEFAAOC Ag8AMIICCgKCAgEA2rpT619IllOfiTjqo3XceBp5dewyYZJZKFzoDkgTIVuhcxlbeUUeyj7/q47d mKW8HaKlkmGuFT5Ev+9r7kKFrL89mr1ll4T03Tc6wd87OXCTu7CiMnfi0cuJf/JCiuIj5vkNfF8h hdMU7nOVkt1ojEnCUsRCnSDj/MXoQa2h2Wm6xofTsUBwuIgR5Mw9GBdyf7wagU6+25Uc2H9Yd4+W u6lSBwj38/nghNe+ZkXrFw0ESOy7zImbVWqorQZdKACYicngZrxLowTbCBIFEOiXEBRuZ8tBGsy8 sL+3JcG+4s7y4KF3Okha3dA+0xibZHZXVSbTMA2F6chTBgIo0+rn/IdpLjyMKw4EBTRMiEGeKudm aURsLoAurDMYBxAxowPwsV/WguVYtRDESYjhheoFd0/lechwx0gQXkG1QF5vMEkwwX10MHa6PwF6 hE9JhukaXuKthRgWmrhPKhxDuqkd1gBIL41XxVNpOsWcdapr8IZF2ncYemSDF84G+lqY4ry50dBh Cja4Ddg13b6PungLeOQYb5npGtk6yQ8TC1ogcvEGIDXjV2ELLkRJw7I1qOsBdC6mwOe+vaJvZ5/7 ic5s8W9509Yh7nuXKPSfd7WtOpMYgEh73CM2cADoyp5pNL0dyE+0G86tqH9xNbNfMaPAzPQ/dQmp NDavkQC7Xb9bmSkCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0 dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G A1UdDgQWBBSxDcrURrevhgLDL28Gyg52cX9LNzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq F+gTEjANBgkqhkiG9w0BAQUFAAOCAgEAbgcgbK+sdz2QQrJhm3Emf1y/tLZ1TG5SJ6CYC9QYdz4k YnIHaPJfunL1qfwKwcDGDcEjcq72PSHsMmlfJ+uXOaDfpdiQ1Ls63QDVSp2MYWu2cghIj5mPfLAd m52YMXyS10GKEcCO6TjsH8qD9nwmFQnfsYbH8rGIiJeDkcxN06XqaUNslpMgQZqB1FyYfe7nuvmy dn6p1VKDlTFZ2GBLb7M+u7+8Ns9373XMtOP0Z6MpcUnp8QA4tbWPYiMnRzIMjrt3X87MVPAIrzBh uGikrbAn1BMoNC5ZG4ajK3Z3rLN3tagBLnkkTQEi36RcMkZs5orjYfaJ87oREdsmISv+iHgrOB0B 6z4ZGPCVJobZnS9rhKzmVjrN/BUIRlh1lyNIOkoHQzm1NBhB47tDJA84joZvgVcD2Sjewe8A+zj4 +r5S1aOnfLyxivW8sIRH148SyAt0IbbuZST04CKOQbqfmgQY4if7vQX6q8qmabnZ1nxvsMQt9u66 TQKtjinRbEfdsG3oUmQ95kkgHpg1cBgdmLtFx0GMsmH6VrBshhMkUhyhYUcCXSDT81iyPPcMuFnP j4KsnpJBJianuoOF0kBY+JqrcL6oT+HYNkAnCjP24etkcHzOxnkkvyxRnvOCpiY0w370/HNqyvJx Mmf3pjrcAhl0OrWQgcjDS8Xg8FNUxm0xggKWMIICkgIBATBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhA+Y90kjQj8WHhnQhaJfgXJ MAkGBSsOAwIaBQCgggEdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE3MDMzMTA0NDUwOFowIwYJKoZIhvcNAQkEMRYEFFEJCQNOhHuwtlvQhYrIEVJHO8R7MF0GCSsG AQQBgjcQBDFQME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjICED5j3SSNCPxYeGdCFol+BckwXwYLKoZIhvcNAQkQAgsxUKBOMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhA+ Y90kjQj8WHhnQhaJfgXJMA0GCSqGSIb3DQEBAQUABIIBAFwQ9cdMqmLK6xA1kSsnYwA9YYp3z78+ 9TTg/+ly54m950vjimW9jDUK6doUsChGRyyoY05EsOuYiNSqmBN7sxne3hi6z9glZGytbYN9TZgk HRSgyeZ/koTga5nICvPGcEgyKPGlkWVqAgg6c1CO3y/6a0WCsoe2eiiOGzoKFSX7Jark8xiyoFiS KFgUDnXASMgsKx3x9EkyhDkedYjMxu+4fdEDMUMg75DJtKir7t6Va/NbQKtyeNK6Z1yFG7QpjZwV jK3J+m4jZXQMO9vcexalH0IicPvny7fYaWi+IrHsj2NkDZvggcZj2+PJMcG+wHI93nBNq2aJzlzB gh8+w5oAAAAAAAA= --Apple-Mail-593801AB-F1A3-4E94-845C-B78154849023-- From nobody Fri Mar 31 09:39:08 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4691A129533 for <6tisch@ietfa.amsl.com>; Fri, 31 Mar 2017 09:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yri6JYY6pibl for <6tisch@ietfa.amsl.com>; Fri, 31 Mar 2017 09:38:55 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176781287A5 for <6tisch@ietf.org>; Fri, 31 Mar 2017 09:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=84028; q=dns/txt; s=iport; t=1490978331; x=1492187931; h=from:to:subject:date:message-id:mime-version; bh=cvQsa5gpYmPsH+th51mSBEDkJMVnFwEiVvzLcbE7xQQ=; b=Ka/ehN6MxcznBPfX+G76w3WrvggWwjoQQuEFBDhGdElvs+bhnxDjh4zs pHApRp4VrZboCxX/ZELSEXao8TU/qBp2f7Voez/zIBr0h9k9HRHRN2bNP WDK0j7NxQu3wBN3zFr0ZXnf9FmxHgdJhV+ZUrEdI7icOc+4AdgSlPjbfJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQBKhd5Y/5tdJa1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuZmGBCweNbZRykjOCCwMfAQyFLIQSPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?aAwEYAQIQPgMEGQEaJgE0CxcPAQQTCBKJcw6dS5Isil0BAQEBAQUBAQEBAQEBI?= =?us-ascii?q?YZOgm15hTUECgSCYoMZBYkbDAWIB4Q2hwEBhnyLSoIGVIJggXiDWYY4iFyGb4Q?= =?us-ascii?q?lAR84gQVbFUGEWAEdgWIBdQGHHYEwgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,252,1486425600"; d="scan'208,217";a="404704156" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2017 16:38:48 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2VGcmec023900 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Fri, 31 Mar 2017 16:38:48 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 31 Mar 2017 11:38:47 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 31 Mar 2017 11:38:47 -0500 From: "Pascal Thubert (pthubert)" To: "'6tisch@ietf.org'" <6tisch@ietf.org> Thread-Topic: Minutes, IETF 98 6TiSCH WG Meeting Thread-Index: AdKqPLZtBg3mmtf1SPOmmg4iOMPqmQ== Date: Fri, 31 Mar 2017 16:37:19 +0000 Deferred-Delivery: Fri, 31 Mar 2017 16:35:50 +0000 Message-ID: <1fe7e4dfed5c49e88534a8a555953d43@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.99.85] Content-Type: multipart/alternative; boundary="_000_1fe7e4dfed5c49e88534a8a555953d43XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [6tisch] Minutes, IETF 98 6TiSCH WG Meeting X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 16:39:07 -0000 --_000_1fe7e4dfed5c49e88534a8a555953d43XCHRCD001ciscocom_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Dear all: Please find the minutes of the 6TiSCH meeting. Deepest thanks to our faithful note takes and jabber scribes who made this = possible. Agenda and Meeting information Meeting : IETF 98; Tuesday, March 28, 2017 (CST) Time : 9:00-11:30, Tuesday Morning session I Location : Room Zurich C, Chicago Swisshotel Concourse Level Chairs : Pascal Thubert Thomas Watteyne (remote) Michael Richardson (acting) Responsible AD : Suresh Krishnan 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 (10mn) (Chairs) * Note-Well, Blue Sheets, Scribes, Agenda Bashing [ 5min] * draft-ietf-6tisch-minimal-21, draft-ietf-6tisch-terminology-08, progress vs. charter [ 5min] * Security (75min, lead by Michael) * Presenting the drafts and the flow between them (Michael) [20min] * draft-ietf-6tisch-dtsecurity-secure-join-01 (Michael) [15min] * draft-ietf-6tisch-minimal-security-02 (Mali=B9a) [15mi= n] * draft-richardson-6tisch-join-enhanced-beacon-01 [10min] * draft-richardson-6tisch-minimal-rekey-01 [10min] * 6top protocol draft-ietf-6tisch-6top-protocol-03 (Xavi) [15min] * Service Function 0 draft-ietf-6tisch-6top-sf0-03 (Diego) [15min] * Architecture draft-ietf-6tisch-architecture-11 (Pascal) [10min] * News from IEEE 802.15.4 (Pat) [15min] * Detnet backhaul draft-wang-detnet-backhaul-architecture-00 (Lun) [10min] * Any Other Business (Chairs) [ 5min] Resources * agenda: https://datatracker.ietf.org/meeting/98/agenda/6tisch/ * presented slides: https://www.ietf.org/proceedings/98/slides/slides-9= 8-6tisch-aggregated-slides-06.pdf Summary _This summary is also posted in the INT area wiki, https://trac.ietf.org/tr= ac/int/wiki/IETF98 The Working Group meeting went smoothly and according to agenda, started an= d completed in time. All the expected slots took place except for the last one on detnet-backhau= l-architecture which was informative to the group. The group is ready to call for adoption for the 6P and SF0 documents, with = restrictions. The first restriction is the lack of feedback information from SF on whethe= r the panel of capabilities from 6P is sufficient to achieve all the needs = to an abstract SF. This will be alleviated by experience from the interop t= est in Prague so we expect to be ready then. Also remarks on the lack of definition of the service interface between SF = and 6P, e.g. pointing on the responsibility of the timeouts and the values = incurred. The largest piece of the meeting dealt with security. The framework was pre= sented in which the minimal security based on PSK can be seen as an optiona= l portion of the larger flow that starts with private keys / certificates a= nd fits within the ANIMA framework. A status was given on related work in other WG and at the IEEE. Volunteers * notetaker 1: Dominique Barthel * notetaker 2: Geraldine Texier * notetaker 3: Francesca Palombini * notetaker 4: Alexander Pelov * notetaker 5: Tero Kivinen * notetaker 6: Xavi Vilajosana * notetaker 7: Pascal Thubert * Jabber scribe 1: Diego Dujovne * Jabber scribe 2: Ines Robles * Jabber scribe 3: Michael Richardson Minutes * [09.01] (expected: 09.00) meeting starts * Thomas calling in from Paris * [09.03] (expected: 09.00) Intro and Status (10mn) (Chairs) * [09.03] (expected: 09.00) Note-Well, Blue Sheets, Scribes, Agenda = Bashing [ 5min] * Pascal goes through agenda: * 70 min dedicated to security, will be able to do some work inst= ead just present slides. * -minimal: Xavi now integrated all comments/reviews. -21 should = go to IESG * [??.??] (expected: 09.05) draft-ietf-6tisch-minimal-21, draft-ietf= -6tisch-terminology-08, progress vs. charter [ 5min] * mcr: plans for future plugtest ? * Thomas: yes, at Prague, probably 14 and 15 July, or after meeting.= Physical meeting but tools for online testing. At the next interim meeting= we'll discuss the scope of the interop. Likely -minimal, 6top, minimal sec= . * we'll have an expert team to write the test description * Kerry: 6lo plugtest as well? Pascal: will see. * Suresh: -minimal underwent major review, many reviewers provided c= omments. Going to RFC editors. was approved a week ago. * [09.12] (expected: 09.10) Security (75min, lead by Michael) * presented at Detnet and ANIMA yesterday. Will repeat intro anyway. * [09.13] (expected: 09.10) Presenting the drafts and the flow betwe= en them (Michael) [20min] * goal: explain how the drafts fit together. * every 2 weeks phone meetings * new Doodle poll. If you couldnt make it to the past times, cast= your vote for better times. * security considerations in ROLL actually applies to all LLNs * zero-touch: designed for networks that need to scale to huge nu= mber of nodes * the two security drafts were adopted after last IETF meeting * -enhanced-beacon: could not wait for -minimal, wrote ED usage d= escription in separate draft * new terminology used: pledge - join registrar/coordinator - joi= n proxy * took some terms form ANIMA. E.g. MASA Manufacturer Auhtorised S= igning Autority * sets PSK if manufacturers knows which customer the device is sh= ipped to. * Michael goes through decision tree for Pledge node to join. Hea= ring first EB can be very long, consumes energy. Subir: reason for going ba= ck in decision tree? mcr: if heared EB from wrong network * table of constraints: Michael interestsed in knowing other cont= raints that migh have been missed * * high level explanation of PSK and RPK cases. For FPK, needs to = do EDHOC first (see ACE presentation) * Thomas: re. time to join. you can optimize many things, we are = talking about seconds not minutes though. one of the constraints is that yo= u get all the nodes to join roughly at the same time ("flood of join"). One= use-case: when installing a network in a plant, booting the router last, e= very nodes will join at the same time * Benjamin Damm: ? mcr: bring question to the list, it's a diffic= ult one. One example is two "identical" parts were swapped during shipment = to two customers. "Just" need to redo pre-provisioning, not swap the part. = How? * * [09.34] (expected: 09.30) draft-ietf-6tisch-dtsecurity-secure-join= -01 (Michael) [15min] * status of the document: reduced this to the scope of the zero-t= ouch, pushed some content to -minimal or other * Thomas: will we have an opportunity to talk about IP-IP vs. CoA= P? mcr: good question, let's take that at the end. * will use CBOR Web Token as a voucher, will reuse a lot of code = (COSE, CBOR already in place) * ANIMA so far not using CBOR, negociation going-in to unify. * presentation of anima document. Revocation not needed. * Max: you can find this in the notes from Anima meeting * Suresh: regardin one and zero-touch: what is going to be the up= date of one vs the other? mcr: goal to make the on-the-wire mechanism as cl= ose as possible. Expect to see devices that are both-capable. You can see t= hat the differences are not big right now (Ack for bandwith control). * one difference is rate of requests: if Pledge drives the timing= and many pledges, not much control. Il JCR drives its own rate, can contro= l. * Suresh: at some point you still have to choose between those tw= o. mcr: if you have a manifacturer that can put a PSK in it for you, you ca= n do that. If you have a large number of devices or many manifacturers, you= may want to go to one touch instead. * Thomas: or you can have a configuration step * Suresh: question still remains. What if you have one mechanism?= Is it possible to reduce these two processes into one? * mcr: trying to build a protocol that allows you to deal with di= fferent cases: if we have the PSK, we can do the simplest thing, otherwise = we can do this other thing. For example, might have a PSK for network A, an= d if deployed in network B, still ok since has a DevID. * Suresh: . * mcr: proposal by Goran, but doesn't have a home yet. * mcr goes through questions listed at ANIMA. * Please help articulate the benefit of using of CWT instead of a= dding PKCS7. * Open Issues * pictures ideal outcome, with convergence between 6Tisch, ANIMA = , * [09.56] (expected: 09.45) draft-ietf-6tisch-minimal-security-02 (M= ali=B9a) [15min] * status: -02 includes major editorial restructuring, stabilizes = the Join Process * this is one touch scenario draft * presentation of the join process * security handshake: this is the current version, and is not set= in stone * Mohit: security hanshake, said could use EDHOC. Why rely on EDH= OC if using P SK? * Malisa: in case of PSK it's optional to run EDHOC, if you requi= re perfect forward secrecy you can run EDHOC with PSK, in case of RPK it's = mandatory. * mcr: 3a (refer to message in the slides) (AAA) is optional when= you don't use PSK. * Join Proxy operated as CoAP proxy in previous version of draft.= Now new CoAP option to carry state between Proxy and Server, * could do IP-in-IP but proble is 3 IP headers, how about compres= sion. * Pascal: provide example on the list for discussion. If all pref= ixes same as LBR, might be able to compress. * Carsten: could you present the status of this doc (incl. Join P= roxy) at CoRE meeting end of the week? mcr: Friday morning. Malisa can make= it. * Thomas: re. IP-in-IP vs. CoAP: CoAP can use well-known resource= s, saves a lot of exchanges that we have to do with IP-in-IP. * mcr: I dont think we have to do all that: specifically, the add= ress of JRC could be LL-anycast, and I don't think that there any other add= resses that the pledge needs to know. * describes how nonce and key are generated in OSCOAP at the pled= ge and at the JRC * Mohit: which values provide enthropy? Malisa: we are using the = OSCOAP mechanism, we only use it in our case. Mohit: ok, will check with au= thors and carry forward on the mailing list. * Pascal: Interested in the discussion about the nonce transport = because LoRaWAN seems to use similar mechanism so if real pb would like to = know! * [10.16] (expected: 10.00) draft-richardson-6tisch-join-enhanced-be= acon-01 [10min] * Diego presents. * Draft meant to add join information into EB to make joining mor= e efficient. * beware that EB is not encrypted, should not put here stuff that= should not be seen by attacker, e.g. PIO. * Erik: it is not clear what this Network ID is. mcr: hash of DOD= AG id. Issue is that it's constant across time. As long as connected to sam= e root. * Malisa: why is PAN ID not enough? mcr: we might decide that we = always use a constant PAN ID, maybe it is enough. Diego: a combination of b= oth * Thomas: Ask same question about PAN ID. PAN ID might be the sim= plest way. * Subir: slide 3. How do you identify JCE? mcr: This is from the = Join Proxy. L2 address and ... * Benjamin: Frequency bands/channels to use. How does it get to k= now about it? mcr: not an IETF problem. * Diego: asking for comments about adoption. * Pascal: interest in the document. Should this document be adopt= ed at some point by this WG? (about two in favour), (nobody against), (two = have read document) * Samita: ? Diego: * mcr: next presentation will respond to Samita's question. * [10.28] (expected: 10.10) draft-richardson-6tisch-minimal-rekey-01= [10min] * Michael presents new draft. Presentation about the concept behi= nd it. Uses CoMI. * when node receives draft with a given key in table, will start = sending traffic with this same key. * Mohit: do keys have key id? mcr: yes, on the wire * allows to eliminate malicious node off the network, but may tak= e a long time because need to rekey all the other nodes, that may be sleepy= and will keepy accepting previous keys for some time. * Kerry Lynn: are there requirements that nodes wake up every n d= ays? mcr: if you dont wake up every time and then you would lose desyncroni= sation AND you would loose the keys as well, so it's not a big addition to = the requirements. * Interested in adopting this, using CoMI (possibly CoMI co-autho= r) * [10.34] (expected: 10.25) 6top protocol draft-ietf-6tisch-6top-protoc= ol-03 (Thomas replacing Xavi) [15min] * stable document. About distributed 6TiSCH cell allocation. * few cahnges from previous version. Most notable is relocate comman= d to improve on delete+create cell. * authors believe the draft is ready, but few unknows: relation with= SF, missing functionalities? * will know from 6TiSCH plugtest event in July. * Pascal: ask for in depth reviews, in particular from an allocation= expert. Diego, Charlie will review this document. * Pascal: after review, will ask for last call. * Thomas (as chair): would feel more confortable moving it to last c= all if all the pieces fit together, in particular feedback from implementor= s about 6P+SF0 * [10.40] (expected: 10.35) Scheduling Function 0 draft-ietf-6tisch-6to= p-sf0-03 (Diego) [15min] * this draft is about a simple scheduling function. * following discussion at IETF97, adopted one mechanism for bandwith= estimation. * Packet Delivery Ratio estimation computed on last 10 packet transm= ission. Is 10 a good value? * Timeout: Yasuyuki proposed algorithm. See discussion on mailing li= st (Dec 2016 onward). * Thomas: algorithm already implemented in 6P. The 6top draft says t= imeout value is left to the SF, because it's the only entity in the node th= at has the full view. diego: we are thinking about the whole transaction, i= nstead of a timeout for each of the exchanges. Now you have to calculate th= e worst timeout between all the exchanges, which is very long. Pascal: let'= s take that to the mailing list. * discussion on cell relocation: oprions are * when PDR gets significantly worse that average for all cells * constant relocation to number of random cells () * leave it to implementation * Tengfei: For the PDR_THRESHOLD, each cell is provisioned by differ= ent SFs, so as long as the cell is related by the corresponding SF, which i= s running on one side, there is no issue for interoperability. (Copied over= from jabber) Thomas Requested to start a Thread on the ML on that Malisa o= n mic: there is a 6tsich simulator available on the bitbucket page that is = convenient for simulating this sorts of algorithms. please take a look. * Muhammad Majhal (yyy univ UK): ? Thoams: TSCH link layer provides = duty cycling. * PAscal: this draft should ship together wth 6top. But pobably as i= nformational, and make second version as standards track when we have more = experience * Malisa (from jabber): there is a 6tsich simulator available on the= bitbucket page that is convenient for simulating this sorts of algorithms.= please take a look. * [11.00] (expected: 10.50) Architecture draft-ietf-6tisch-architecture= -11 (Pascal) [10min] * considerationa about "tracks". Also provided in Detnet draft. A 6T= iSCH is not just a serial sequence of cells along a path. Can include repli= cation/elimination. * published draft at BIER to describe how this path replication (usi= ng Arc routing) works. * Tests have been performed to combine BierTE mechanism with tracks.= A bitmap tells the path to take. * The bitmap indicate the paths that failed or not, enabeling an OAM= mechanism and a control loop * Kerry Lynn: how does this compare to FEC? Pascal: we are mostly ai= ming at protecting against node failure; TSCH is pretty good at reducing li= nk failure probability. * Pascal: take advantage of inherent broadcasting of radio to do "bi= -casting", by having two receivers and one transmitter per cell. This incre= ases reliability. * Also expose node multiple parents to RPL root (in non-storing mode= ), shows the full structure. Root can find shorter pathes. Effectively redu= ces latency. * Recap: tracks are much more than sequence of cell. * Tengfei: we are conducting large-scale experiments of 6P SF0 on th= e IoT-lab, with 100-nodes runnign openWSN. will contribute results to the g= roup verifying the current of 6p and SF0 work. * Malisa: working on 6TiSCH simulator, on BitBucket. Will contribute= the results to the group. Explore the code and contribute. * Pascal: please write that in the mailing list * [11.15] (expected: 11.00) News from IEEE 802.15.4 (Pat) [15min] * 15.4q: new low power PHY, has Amplitude Shift Keying. Not backward= comptabible. * 15.4t: 2Mbps, backward compatible with current radios. * next 15.4 revision will integrate 6 amendments and include corrige= nda. * 15.9: Information Elements for Key Management Protocols. o 15.10: layer 2 routing. Meant to support "large scale" networks (node c= ount in the thousands). Randy Turner asked what is large scale, Charlie answered thousand o 15.12: upper layer over 15.4. Defines concept of profiles (e.g. for WiS= un or Thread). * Muhammad: 15.6 ? Pat: 15.6 is medical Body Area Network. MAC simil= ar to 15.4. But nobody at 15.6 asked 15.12 to consider their techno * Carsten: Is this all done? Pat: no it's underway right now. We do = need help. * Bob: 15.6 has a limited stack architecture, star topology, very is= olated approach to many things, very closed, trying to put 15.6 in discussi= on is challenging at best, talking about 15.7 would be much better. * Need participation from this group. * [xx.xx] Detnet backhaul draft-wang-detnet-backhaul-architecture-00= (Lun) [10min] * skipped for lack of time * [11.29] (expected: 11.25) Any Other Business (Chairs) [ 5min] * Samita: please come to 6lo * [11.30] (expected: 11.30) meeting ends --_000_1fe7e4dfed5c49e88534a8a555953d43XCHRCD001ciscocom_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Dear all:

Please find the minutes of the 6TiSCH meeting.=

Deepest thanks to our faithful note takes and jabbe= r scribes who made this possible.

Agenda and Meeting information

Meeting      &n=
bsp; :   IETF <=
span class=3D"mi">98; Tue=
sday, March 28, 2017 (CST) 
Time       =
;    :   9:00-11:30, Tuesday=
 Morning session <=
span class=3D"n">I
Location       =
:   Room Zurich C, Chicago Swisshotel Concourse Level<=
/pre>
Chairs      &nb=
sp;  :   Pascal Thubert <pthubert@cis=
co.com>
           &nbs=
p;       Thomas Watteyne <thomas.watteyne=
@inria.fr> (remote)=
           &nbs=
p;       Michael Richardson <mcr+ietf@sandelman.ca> (acting)<=
/span>
Responsible AD :   Suresh Krishnan
URLs       =
;    :   http://tools.ietf.org/wg/6tisch/<=
/o:p>
           &nbs=
p;       https://datatracker.ietf.org/wg/6tisch/
           &nbs=
p;       https://www.ietf.org/mailman/listinfo/6=
tisch
           &nbs=
p;       https://bitbucket.=
org/6tisch
 
* Intro and Status (10mn)=
 (Chairs)
    * Note-Well, Blue Sheets, Scribes=
, Agenda Bashing&n=
bsp;            =
;  [ 5min]
    * draft<=
/span>-ietf-6tisch-minimal-21, 
      draft-ietf-6tisch-terminology-08, 
      progress =
vs. cha=
rter          &nbs=
p;            &=
nbsp;           &nbs=
p;      [ 5min]
* Security (75min, lead by=
 Michael)
    * Presen=
ting the drafts and the f=
low between them <=
span class=3D"o">(Michael=
)     [20min]
    * draft<=
/span>-ietf-6tisch-dtsecurity-<=
/span>secure-join-01 (Michael)=
         [=
15min]
    * draft<=
/span>-ietf-6tisch-minimal-security-02 (Mali=B9a)           &nbs=
p;    [15=
min]
    * draft<=
/span>-richardson-6tisch=
-join-<=
/span>enhanced-beacon-01=
            &nb=
sp;  [10min]
    * draft<=
/span>-richardson-6tisch=
-minimal-rekey-01         &nb=
sp;            [10min]
* 6top protocol  draf=
t-ietf-6tisch-6top-protocol-03  (Xavi)   &=
nbsp;     [=
15min]<=
/pre>
* Service Function 0 draft=
-ietf-6tisch-6top-sf0=
-03  (Diego)     =
    [15min]
* Architecture draft-ietf-6tisch-architecture-11 (=
Pascal)  =
;         [10min=
]
* News from IEEE 802.15<=
/span>.4 (Pat) &nbs=
p;            &=
nbsp;           &nbs=
p;          =
[15min]
* Detnet backhaul draft-wang-detnet-backhaul<=
span class=3D"o">-architecture-00 (Lun)  [=
10min]
* Any Other Business (Chairs)  &nbs=
p;            &=
nbsp;           &nbs=
p;           [ 5min]

Resources

Summary

_This summary is also posted in the INT area wiki, https://trac.ietf.org/trac/int/wiki/IETF98

The Working Group meeting went smoothly and according to agenda, start=
ed and completed in time.
All the expected slots took place except for the last one on detnet-ba=
ckhaul-architecture which was informative to the group.
The group is ready to call for adoption for the 6P and SF0 documents, =
with restrictions.
The first restriction is the lack of feedback information from SF on w=
hether the panel of capabilities from 6P is sufficient to achieve all the n=
eeds to an abstract SF. This will be alleviated by experience from the inte=
rop test in Prague so we expect to be ready then.
Also remarks on the lack of definition of the service interface betwee=
n SF and 6P, e.g. pointing on the responsibility of the timeouts and the va=
lues incurred.
The largest piece of the meeting dealt with security. The framework wa=
s presented in which the minimal security based on PSK can be seen as an op=
tional portion of the larger flow that starts with private keys / certifica=
tes and fits within the ANIMA framework.
A status was given on related work in other WG and at the IEEE. <=
/o:p>

Volunteers

  • notetaker 1: Dominique Barthel
  • notetaker 2: Geraldine Texier
  • notetaker 3: Francesca Palombini
  • notetaker 4: Alexander Pelov
  • notetaker 5: Tero Kivinen
  • notetaker 6: Xavi Vilajosana
  • notetaker 7: Pascal Thubert
  • Jabber scribe 1: Diego Dujovne
  • Jabber scribe 2: Ines Robles
  • Jabber scribe 3: Michael Richardson

Minutes

  • [09.01] (expected: 09.00) meeting starts
    • Thomas calling in from Paris
  • [09.03] (expected: 09.00) Intro and Status (10mn) (Chairs)
    • [09.03] (expected: 09.00) Note-Well, Blue Sheets, Scribes, Agenda Bashing [= 5min]
      • Pascal goes through agenda:
      • 70 min dedicated to security, will be able to do some work instead just pre= sent slides.
      • -minimal: Xavi now integrated all comments/reviews. -21 should go to IESG
    • [??.??] (expected: 09.05) draft-ietf-6tisch-minimal-21, draft-ietf-6tisch-t= erminology-08, progress vs. charter [ 5min]
    • mcr: plans for future plugtest ?
    • Thomas: yes, at Prague, probably 14 and 15 July, or after meeting. Physical= meeting but tools for online testing. At the next interim meeting we'll di= scuss the scope of the interop. Likely -minimal, 6top, minimal sec.
    • we'll have an expert team to write the test description
    • Kerry: 6lo plugtest as well? Pascal: will see.=
    • Suresh: -minimal underwent major review, many reviewers provided comments. = Going to RFC editors. was approved a week ago.
  • [09.12] (expected: 09.10) Security (75min, lead by Michael)
    • presented at Detnet and ANIMA yesterday. Will repeat intr= o anyway.
    • [09.13] (expected: 09.10) Presenting the drafts and the flow between them (= Michael) [20min]
      • goal: explain how the drafts fit together.
      • every 2 weeks phone meetings
      • new Doodle poll. If you couldnt make it to the past times, cast your vote f= or better times.
      • security considerations in ROLL actually applies to all LLNs
      • zero-touch: designed for networks that need to scale to huge number of node= s
      • the two security drafts were adopted after last IETF meeting
      • -enhanced-beacon: could not wait for -minimal, wrote ED usage description i= n separate draft
      • new terminology used: pledge - join registrar/coordinator - join proxy=
      • took some terms form ANIMA. E.g. MASA Manufacturer Auhtorised Signing Autor= ity
      • sets PSK if manufacturers knows which customer the device is shipped to.
      • Michael goes through decision tree for Pledge node to join. Hearing first E= B can be very long, consumes energy. Subir: reason for going back in decisi= on tree? mcr: if heared EB from wrong network
      • table of constraints: Michael interestsed in knowing other contraints that = migh have been missed
      •  
      • high level explanation of PSK and RPK cases. For FPK, needs to do EDHOC fir= st (see ACE presentation)
      • Thomas: re. time to join. you can optimize many things, we are talking abou= t seconds not minutes though. one of the constraints is that you get all th= e nodes to join roughly at the same time ("flood of join"). One u= se-case: when installing a network in a plant, booting the router last, every nodes will join at the same time=
      • Benjamin Damm: ? mcr: bring question to the list, it's a difficult one. One= example is two "identical" parts were swapped during shipment to= two customers. "Just" need to redo pre-provisioning, not swap th= e part. How?
      •  
    • [09.34] (expected: 09.30) draft-ietf-6tisch-dtsecurity-secure-join-01 (Mich= ael) [15min]
      • status of the document: reduced this to the scope of the zero-touch, pushed= some content to -minimal or other
      • Thomas: will we have an opportunity to talk about IP-IP vs. CoAP? mcr: good= question, let's take that at the end.
      • will use CBOR Web Token as a voucher, will reuse a lot of code (COSE, CBOR = already in place)
      • ANIMA so far not using CBOR, negociation going-in to unify.
      • =
      • presentation of anima document. Revocation not needed.
      • Max: you can find this in the notes from Anima meeting
      • Suresh: regardin one and zero-touch: what is going to be the update of one = vs the other? mcr: goal to make the on-the-wire mechanism as close as possi= ble. Expect to see devices that are both-capable. You can see that the diff= erences are not big right now (Ack for bandwith control).
      • one difference is rate of requests: if Pledge drives the timing and many pl= edges, not much control. Il JCR drives its own rate, can control.
      • Suresh: at some point you still have to choose between those two. mcr: if y= ou have a manifacturer that can put a PSK in it for you, you can do that. I= f you have a large number of devices or many manifacturers, you may want to= go to one touch instead.
      • Thomas: or you can have a configuration step
      • Suresh: question still remains. What if you have one mechanism? Is it possi= ble to reduce these two processes into one?
      • mcr: trying to build a protocol that allows you to deal with different case= s: if we have the PSK, we can do the simplest thing, otherwise we can do th= is other thing. For example, might have a PSK for network A, and if deploye= d in network B, still ok since has a DevID.
      • Suresh: .
      • mcr: proposal by Goran, but doesn't have a home yet.
      • mcr goes through questions listed at ANIMA.
      • Please help articulate the benefit of using of CWT instead of adding PKCS7.=
      • Open Issues
      • pictures ideal outcome, with convergence between 6Tisch, ANIMA ,=
    • [09.56] (expected: 09.45) draft-ietf-6tisch-minimal-security-02 (Mali=B9a) = [15min]
      • status: -02 includes major editorial restructuring, stabilizes the Join Pro= cess
      • this is one touch scenario draft
      • presentation of the join process
      • security handshake: this is the current version, and is not set in stone
      • Mohit: security hanshake, said could use EDHOC. Why rely on EDHOC if using = P SK?
      • Malisa: in case of PSK it's optional to run EDHOC, if you require perfect f= orward secrecy you can run EDHOC with PSK, in case of RPK it's mandatory.
      • mcr: 3a (refer to message in the slides) (AAA) is optional when you don't u= se PSK.
      • Join Proxy operated as CoAP proxy in previous version of draft. Now new CoA= P option to carry state between Proxy and Server,
      • could do IP-in-IP but proble is 3 IP headers, how about compression.
      • Pascal: provide example on the list for discussion. If all prefixes same as= LBR, might be able to compress.
      • Carsten: could you present the status of this doc (incl. Join Proxy) at CoR= E meeting end of the week? mcr: Friday morning. Malisa can make it.
      • Thomas: re. IP-in-IP vs. CoAP: CoAP can use well-known resources, saves a l= ot of exchanges that we have to do with IP-in-IP.
      • mcr: I dont think we have to do all that: specifically, the address of JRC = could be LL-anycast, and I don't think that there any other addresses that = the pledge needs to know.
      • describes how nonce and key are generated in OSCOAP at the pledge and at th= e JRC
      • Mohit: which values provide enthropy? Malisa: we are using the OSCOAP mecha= nism, we only use it in our case. Mohit: ok, will check with authors and ca= rry forward on the mailing list.
      • Pascal: Interested in the discussion about the nonce transport because LoRa= WAN seems to use similar mechanism so if real pb would like to know!
    • [10.16] (expected: 10.00) draft-richardson-6tisch-join-enhanced-beacon-01 [= 10min]
      • Diego presents.
      • Draft meant to add join information into EB to make joining more efficient.=
      • beware that EB is not encrypted, should not put here stuff that should not = be seen by attacker, e.g. PIO.
      • Erik: it is not clear what this Network ID is. mcr: hash of DODAG id. Issue= is that it's constant across time. As long as connected to same root.=
      • Malisa: why is PAN ID not enough? mcr: we might decide that we always use a= constant PAN ID, maybe it is enough. Diego: a combination of both
      • Thomas: Ask same question about PAN ID. PAN ID might be the simplest way.
      • Subir: slide 3. How do you identify JCE? mcr: This is from the Join Proxy. = L2 address and ...
      • Benjamin: Frequency bands/channels to use. How does it get to know about it= ? mcr: not an IETF problem.
      • Pascal: interest in the document. Should this document be adopted at some point<= /em> by this WG? (about two in favour), (nobody against), (two have read do= cument)
      • Samita: ? Diego:
      • mcr: next presentation will respond to Samita's question.
      • [10.28] (expected: 10.10) draft-richardson-6tisch-minimal-rekey-01 [10min]<= o:p>
        • Michael presents new draft. Presentation about the concept behind it. Uses CoMI.
        • when node receives draft with a given key in table, will start sending traf= fic with this same key.
        • Mohit: do keys have key id? mcr: yes, on the wire
        • allows to eliminate malicious node off the network, but may take a long tim= e because need to rekey all the other nodes, that may be sleepy and will ke= epy accepting previous keys for some time.
        • Kerry Lynn: are there requirements that nodes wake up every n days? mcr: if= you dont wake up every time and then you would lose desyncronisation AND y= ou would loose the keys as well, so it's not a big addition to the requirem= ents.
        • Interested in adopting this, using CoMI (possibly CoMI co-author)
    • [10.34] (expected: 10.25) 6top protocol draft-ietf-6tisch-6top-protocol-03 = (Thomas replacing Xavi) [15min]
      • stable document. About distributed 6TiSCH cell allocation= .
      • few cahnges from previous version. Most notable is relocate command to impr= ove on delete+create cell.
      • authors believe the draft is ready, but few unknows: relation with SF, miss= ing functionalities?
      • will know from 6TiSCH plugtest event in July.
      • Pascal: ask for in depth reviews, in particular from an allocation expert. = Diego, Charlie will review this document.
      • Pascal: after review, will ask for last call.
      • Thomas (as chair): would feel more confortable moving it to last call if al= l the pieces fit together, in particular feedback from implementors about 6= P+SF0
    • [10.40] (expected: 10.35) Scheduling Function 0 draft-ietf-6tisch-6top-sf0-= 03 (Diego) [15min]
      • this draft is about a simple scheduling function.
      • following discussion at IETF97, adopted one mechanism for bandwith estimati= on.
      • Packet Delivery Ratio estimation computed on last 10 packet transmission. <= span lang=3D"FR"> Is 10 a good value?
      • Timeout: Yasuyuki proposed algorithm. See discussion on mailing list (Dec 2= 016 onward).
      • Thomas: algo= rithm already implemented in 6P. The 6top draft says timeout value= is left to the SF, because it's the only entity in the node that has = the full view. diego: we are thinking about the whole transaction, instead = of a timeout for each of the exchanges. Now you have to calculate the worst timeout between all the exchanges, which i= s very long. Pascal: let's take that to the mailing list.
      • discussion on cell relocation: oprions are
        • when PDR gets significantly worse that average for all cells
        • constant relocation to number of random cells (<did I get this right?>= ;)
        • leave it to implementation
      • Tengfei: For the PDR_THRESHOLD, each cell is provisioned by different SFs, = so as long as the cell is related by the corresponding SF, which is running= on one side, there is no issue for interoperability. (Copied over from jab= ber) Thomas Requested to start a Thread on the ML on that Malisa on mic: there is a 6tsich simulator availa= ble on the bitbucket page that is convenient for simulating this sorts of a= lgorithms. please take a look.
      • Muhammad Majhal (yyy univ UK): ? Thoams: TSCH link layer provides duty cycl= ing.
      • PAscal: this draft should ship together wth 6top. But pobably as informatio= nal, and make second version as standards track when we have more experienc= e
      • Malisa (from jabber): there is a 6tsich simulator available on the bitbucke= t page that is convenient for simulating this sorts of algorithms. please t= ake a look.
    • [11.00] (expected: 10.50) Architecture draft-ietf-6tisch-architecture-11 (P= ascal) [10min]
      • considerationa about "tracks". Also provided in Detnet draft. A 6= TiSCH is not just a serial sequence of cells along a path. Can include replication/elimination.
      • published draft at BIER to describe how this path replication (using Arc ro= uting) works.
      • Tests have been performed to combine BierTE mechanism with tracks. A bitmap tells the path to take.
      • The bitmap indicate the paths that failed or not, enabeling an OAM mechanis= m and a control loop
      • Kerry Lynn: how does this compare to FEC? Pascal: we are mostly aiming at p= rotecting against node failure; TSCH is pretty good at reducing link failur= e probability.
      • Pascal: take advantage of inherent broadcasting of radio to do "bi-cas= ting", by having two receivers and one transmitter per cell. This increases reliability.
      • Also expose node multiple parents to RPL root (in non-storing mode), shows = the full structure. Root can find shorter pathes. Effectively reduces latency= .
      • Recap: track= s are much more than sequence of cell.
      • Tengfei: we are conducting large-scale experiments of 6P SF0 on the IoT-lab= , with 100-nodes runnign openWSN. will contribute results to the group veri= fying the current of 6p and SF0 work.
      • Malisa: working on 6TiSCH simulator, on BitBucket. Will contribute the resu= lts to the group. Explore the code and contribute.
      • <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;mso-list:l0 level2 lfo3"> Pascal: please write that in the mailing list

    <= span style=3D"mso-list:Ignore">·        [11.15] (expected: 11.00) News from IEEE 802= .15.4 (Pat) [15min]

      • 15.4q: new low power PHY, has Amplitude Shift Keying. Not= backward comptabible.
      • 15.4t: 2Mbps, backward compatible with current radios.
      • next 15.4 revision will integrate 6 amendments and include corrigenda.
      • 15.9: Information Elements for Key Management Protocols.

      o   15.10: layer 2 routing. Meant to support &qu= ot;large scale" networks (node count in the thousands).

      Randy Turner asked what is large scale, Cha= rlie answered thousand

      o   15.12: upper layer over 15.4. Defines concep= t of profiles (e.g. for WiSun or Thread).

        • Muhammad: 15.6 ? Pat: 15.6 is medical Body Area Network. MAC similar to 15.= 4. But nobody at 15.6 asked 15.12 to consider their techno
        • <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;mso-list:l0 level2 lfo3"> Carsten: Is this all done? Pat: no it's underway right now. We do need help.
        • Bob: 15.6 has a limited stack architecture, star topology, very isolated ap= proach to many things, very closed, trying to put 15.6 in discussion is cha= llenging at best, talking about 15.7 would be much better.
        • <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;mso-list:l0 level2 lfo3"> Need participation from this group.
        • [xx.xx] Detnet backhaul draft-wang-detnet-backhaul-architecture-00 (Lun) [1= 0min]
        • skipped for lack of time
        • [11.29] (expected: 11.25) Any Other Business (Chairs) [ 5min]
        • Samita: please come to 6lo
        • [11.30] (expected: 11.30) meeting ends<= /li>

       

--_000_1fe7e4dfed5c49e88534a8a555953d43XCHRCD001ciscocom_--