From nobody Fri Dec 1 07:47:02 2017 Return-Path: X-Original-To: lp-wan@ietf.org Delivered-To: lp-wan@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD914129407; Fri, 1 Dec 2017 07:46:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bob Halley To: Cc: lp-wan@ietf.org, draft-ietf-lpwan-overview.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151214321071.1282.9088534214260050074@ietfa.amsl.com> Date: Fri, 01 Dec 2017 07:46:50 -0800 Archived-At: Subject: [lp-wan] Intdir early review of draft-ietf-lpwan-overview-07 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 15:46:51 -0000 Reviewer: Bob Halley Review result: Ready I am an assigned INT directorate reviewer for draft-ietf-lpwan-overview-07. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html. The document is a good introduction to this area! I did not find anything that needed correction or clarification. /Bob From nobody Fri Dec 1 07:59:20 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFFB127011; Fri, 1 Dec 2017 07:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, 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 sWbWr51X7w_S; Fri, 1 Dec 2017 07:59:11 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F54124B09; Fri, 1 Dec 2017 07:59:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3313; q=dns/txt; s=iport; t=1512143951; x=1513353551; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TnAtv+kHJbx8Q6KAi2S09YdIVPCAfaWlDVYuxoQfpKs=; b=fNmML9cWR03+WEp0+3MyzhUy13xz6nfhLcNWauUaWX/MB2azt6QLONGn KJbSFv1VdSX+RmMatNDsyXmn3UAOt+DjonisyxTFTckZn+9bfrDOjOm7d 9Ytp6qYKpyrC264ZLRSxAL40VQKexYHkXnjqsI1M9ooSodjdOTrrwjxKg 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAgBYeyFa/4MNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm4ng3+ZE5MvhUuCFQojhRgCGoURQBcBAQEBAQEBAQFrKIU?= =?us-ascii?q?jBiNWEAIBCAQBOgMCAgIwFBECBA4FCYk1ZBCmeIInimQBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdg0GCCoFWghKDAoMkDoUEMYIyBZk1iS0ClQ+TVZYcAhEZAYE5ASE?= =?us-ascii?q?BNoFNbxVkAYF+CYJJHIFneAGKAgEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,344,1508803200"; d="scan'208,217";a="316930522" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2017 15:59:10 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vB1FxAnu013039 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Dec 2017 15:59:10 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.1320.4; Fri, 1 Dec 2017 09:59:09 -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.1320.000; Fri, 1 Dec 2017 09:59:09 -0600 From: "Pascal Thubert (pthubert)" To: Bob Halley CC: "int-dir@ietf.org" , "lp-wan@ietf.org" , "draft-ietf-lpwan-overview.all@ietf.org" Thread-Topic: Intdir early review of draft-ietf-lpwan-overview-07 Thread-Index: AQHTaruckwnGnwZKvEWpBCqFYaI3OaMupS6I Date: Fri, 1 Dec 2017 15:59:09 +0000 Message-ID: <8BA98F28-F6D3-4A7A-AB3C-CEE7B5FFEDF2@cisco.com> References: <151214321071.1282.9088534214260050074@ietfa.amsl.com> In-Reply-To: <151214321071.1282.9088534214260050074@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: multipart/alternative; boundary="_000_8BA98F28F6D34A7AAB3CCEE7B5FFEDF2ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] Intdir early review of draft-ietf-lpwan-overview-07 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 15:59:13 -0000 --_000_8BA98F28F6D34A7AAB3CCEE7B5FFEDF2ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGEgYnVuY2ggQm9iIQ0KDQpQYXNjYWwNCg0KTGUgMSBkw6ljLiAyMDE3IMOgIDE2OjQ2 LCBCb2IgSGFsbGV5IDxCb2IuSGFsbGV5QG5vbWludW0uY29tPG1haWx0bzpCb2IuSGFsbGV5QG5v bWludW0uY29tPj4gYSDDqWNyaXQgOg0KDQpSZXZpZXdlcjogQm9iIEhhbGxleQ0KUmV2aWV3IHJl c3VsdDogUmVhZHkNCg0KSSBhbSBhbiBhc3NpZ25lZCBJTlQgZGlyZWN0b3JhdGUgcmV2aWV3ZXIg Zm9yIGRyYWZ0LWlldGYtbHB3YW4tb3ZlcnZpZXctMDcuDQpUaGVzZSBjb21tZW50cyB3ZXJlIHdy aXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgSW50ZXJuZXQgQXJlYQ0KRGly ZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBzaGVwaGVyZChzKSBzaG91bGQgdHJlYXQgdGhl c2UgY29tbWVudHMganVzdA0KbGlrZSB0aGV5IHdvdWxkIHRyZWF0IGNvbW1lbnRzIGZyb20gYW55 IG90aGVyIElFVEYgY29udHJpYnV0b3JzIGFuZCByZXNvbHZlDQp0aGVtIGFsb25nIHdpdGggYW55 IG90aGVyIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiByZWNlaXZlZC4gRm9yIG1v cmUNCmRldGFpbHMgb24gdGhlIElOVCBEaXJlY3RvcmF0ZSwgc2VlIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaWVzZy9kaXJlY3RvcmF0ZS5odG1sLg0KDQpUaGUgZG9jdW1lbnQgaXMgYSBnb29kIGludHJv ZHVjdGlvbiB0byB0aGlzIGFyZWEhICBJIGRpZCBub3QgZmluZCBhbnl0aGluZyB0aGF0DQpuZWVk ZWQgY29ycmVjdGlvbiBvciBjbGFyaWZpY2F0aW9uLg0KDQovQm9iDQoNCg0K --_000_8BA98F28F6D34A7AAB3CCEE7B5FFEDF2ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpU aGFua3MgYSBidW5jaCBCb2IhPGJyPg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBh c2NhbDwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCkxlIDEgZMOpYy4gMjAxNyDDoCAxNjo0Niwg Qm9iIEhhbGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOkJvYi5IYWxsZXlAbm9taW51bS5jb20iPkJv Yi5IYWxsZXlAbm9taW51bS5jb208L2E+Jmd0OyBhIMOpY3JpdCZuYnNwOzo8YnI+DQo8YnI+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5SZXZpZXdlcjogQm9i IEhhbGxleTwvc3Bhbj48YnI+DQo8c3Bhbj5SZXZpZXcgcmVzdWx0OiBSZWFkeTwvc3Bhbj48YnI+ DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+SSBhbSBhbiBhc3NpZ25lZCBJTlQgZGlyZWN0b3Jh dGUgcmV2aWV3ZXIgZm9yIGRyYWZ0LWlldGYtbHB3YW4tb3ZlcnZpZXctMDcuDQo8L3NwYW4+PGJy Pg0KPHNwYW4+VGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJl bmVmaXQgb2YgdGhlIEludGVybmV0IEFyZWE8L3NwYW4+PGJyPg0KPHNwYW4+RGlyZWN0b3JzLiBE b2N1bWVudCBlZGl0b3JzIGFuZCBzaGVwaGVyZChzKSBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVu dHMganVzdDwvc3Bhbj48YnI+DQo8c3Bhbj5saWtlIHRoZXkgd291bGQgdHJlYXQgY29tbWVudHMg ZnJvbSBhbnkgb3RoZXIgSUVURiBjb250cmlidXRvcnMgYW5kIHJlc29sdmU8L3NwYW4+PGJyPg0K PHNwYW4+dGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgdGhhdCBo YXZlIGJlZW4gcmVjZWl2ZWQuIEZvciBtb3JlPC9zcGFuPjxicj4NCjxzcGFuPmRldGFpbHMgb24g dGhlIElOVCBEaXJlY3RvcmF0ZSwgc2VlIDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVz Zy9kaXJlY3RvcmF0ZS5odG1sIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0 ZS5odG1sPC9hPi48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPlRoZSBkb2N1 bWVudCBpcyBhIGdvb2QgaW50cm9kdWN0aW9uIHRvIHRoaXMgYXJlYSEgJm5ic3A7SSBkaWQgbm90 IGZpbmQgYW55dGhpbmcgdGhhdDwvc3Bhbj48YnI+DQo8c3Bhbj5uZWVkZWQgY29ycmVjdGlvbiBv ciBjbGFyaWZpY2F0aW9uLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+L0Jv Yjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8BA98F28F6D34A7AAB3CCEE7B5FFEDF2ciscocom_-- From nobody Tue Dec 5 03:30:35 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A510129435 for ; Tue, 5 Dec 2017 03:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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, 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 N3D8umtKyaNo for ; Tue, 5 Dec 2017 03:30:31 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA442129413 for ; Tue, 5 Dec 2017 03:30:04 -0800 (PST) Received: from [IPv6:2001:660:7301:3728:edf4:1e51:b6f6:99b6] (unknown [IPv6:2001:660:7301:3728:edf4:1e51:b6f6:99b6]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 1C1A5A80CE for ; Tue, 5 Dec 2017 12:30:02 +0100 (CET) From: Alexander Pelov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <5D1B8E20-4EC3-4007-BC72-38FE407AC1D9@ackl.io> Date: Tue, 5 Dec 2017 12:30:02 +0100 To: lp-wan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lp-wan] Updated agenda for today's call X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 11:30:34 -0000 Dear all, The agenda for today=E2=80=99s meeting has been uploaded to the = Datatracker: = https://datatracker.ietf.org/doc/agenda-interim-2017-lpwan-12-lpwan-01/ It covers mostly the updates to the IP/UDP SCHC draft, which were = discussed during the last IETF. It also has a discussion on some topics = on fragmentation. Best, The Chairs Nota: the call connection details are in the Agenda= From nobody Tue Dec 5 08:06:03 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A6A1275FD for ; Tue, 5 Dec 2017 08:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, 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 8ueY_sOuQ7Vt for ; Tue, 5 Dec 2017 08:05:59 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE82F127342 for ; Tue, 5 Dec 2017 08:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1189; q=dns/txt; s=iport; t=1512489958; x=1513699558; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=PFR8dQ5J5I3N8wDe1T/qN6JaEVAw9szPgeYA+1Dst3Y=; b=ec0hmLq2WnfsYT13ILurUuPQrDuYxBYbX+f76IydfffK8M0S1/nbj7dg Kn0z0DVwXTFHS7PXONLOrrN4wJKSO/zmqMyjc5evJVe/0q6pHe0HxLcFJ Qr8BNRC85Rj+fcjHrMvaX2oXOP8rnuNGo6pNBKEtcXlFgU4KGSG0aq5Uk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAACMwyZa/4MNJK1CGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPWZuJweOGY57gX2XAhSCAQoYDYUSAgIChUg/GAEBAQEBAQE?= =?us-ascii?q?BAWsohSIBAQYBGx00FwYBGQQBARkGBgMuCxQJCQEEEwiKGxA0qzaDVYcHAQEBA?= =?us-ascii?q?QEBBAEBAQEBAQEcBYNIggqBVoFphnaBHhgBAWyCIIJvGwWZPIk6Aod0jRSCH4N?= =?us-ascii?q?sgiWLMY0BiSMCERkBgTkBHzmBTW8VOoIpglIcgWd4AYdwFoEOgRQBAQE?= X-IronPort-AV: E=Sophos;i="5.45,364,1508803200"; d="scan'208";a="40059053" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Dec 2017 16:05:58 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vB5G5wMY003643 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 Dec 2017 16:05:58 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.1320.4; Tue, 5 Dec 2017 10:05:57 -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.1320.000; Tue, 5 Dec 2017 10:05:57 -0600 From: "Pascal Thubert (pthubert)" To: lp-wan Thread-Topic: It is now: Dec 5th interim Thread-Index: AdNt4qIIpUyOOEU9QDaJ9tvi/UVYPw== Date: Tue, 5 Dec 2017 16:05:42 +0000 Deferred-Delivery: Tue, 5 Dec 2017 16:04:51 +0000 Message-ID: <9bf6d64416284a8b83216364c1670efa@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.55.22.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lp-wan] It is now: Dec 5th interim X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 16:06:02 -0000 It is now! LPWAN interim=20 Tuesday 5 December 2017=20 17:00 | Europe Time (Paris, GMT+01:00) | 1 hr=20 Meeting number (access code): 204 648 433=20 https://cisco.webex.com/cisco/j.php?MTID=3Dm016ded95875427897fd1089cb921b30= b Meeting password: 62YbPWpj (62927975 from phones) Cheers, Pascal -----Original Message----- From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Alexander Pelov Sent: mardi 28 novembre 2017 16:20 To: lp-wan Subject: [lp-wan] Reminder next interim + call for agenda items Dear all, Next week we are restarting our interim meetings. The time slot is the same= as before IETF100 - Tuesdays, 17h-18h CET. We have scheduled meetings ever= y two weeks (as already announced on the ML). On the agenda we will have items related to Fragmentation + potentially oth= er items, which were present on the agenda. If you would like to include an item for the agenda, please send a mail wit= h topic + requested duration by Nov 29th, 17h (5PM) UTC. Best, The Chairs _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan From nobody Tue Dec 5 09:10:27 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E86129484 for ; Tue, 5 Dec 2017 09:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 j2d_w25rOMwT for ; Tue, 5 Dec 2017 09:10:23 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67EC5127871 for ; Tue, 5 Dec 2017 09:10:23 -0800 (PST) Received: from [IPv6:2001:660:7301:3728:7d44:afbc:ea46:e7dd] (unknown [IPv6:2001:660:7301:3728:7d44:afbc:ea46:e7dd]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id D5411172098 for ; Tue, 5 Dec 2017 18:10:20 +0100 (CET) From: Alexander Pelov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 5 Dec 2017 18:10:20 +0100 To: lp-wan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lp-wan] Minutes from today's meeting X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 17:10:26 -0000 Dear all, You can find the minutes from today=E2=80=99s meeting on the = Datatracker: = https://datatracker.ietf.org/doc/minutes-interim-2017-lpwan-12-20171205170= 0/ We have our 2 main TODOs:=20 - propose default MIC algorithm - publish SCHC draft and ready for WGLC Best, Pascal and Alexander From nobody Tue Dec 5 11:13:53 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8683F1243FE for ; Tue, 5 Dec 2017 11:13:51 -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 J4z5cw1Ct-Au for ; Tue, 5 Dec 2017 11:13:50 -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 A60B7127B73 for ; Tue, 5 Dec 2017 11:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vB5JDj5L021740; Tue, 5 Dec 2017 20:13:45 +0100 (CET) Received: from [192.168.217.119] (p5DC7E827.dip0.t-ipconnect.de [93.199.232.39]) (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 3yrry124SJzDX1B; Tue, 5 Dec 2017 20:13:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 5 Dec 2017 20:13:44 +0100 Cc: lp-wan X-Mao-Original-Outgoing-Id: 534194024.390564-28fc36955aad1d718a3e5458e85bb8a0 Content-Transfer-Encoding: quoted-printable Message-Id: <03873E7D-C36A-4E58-B9C0-8DDC07960DDE@tzi.org> References: To: Alexander Pelov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lp-wan] Minutes from today's meeting X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 19:13:51 -0000 On Dec 5, 2017, at 18:10, Alexander Pelov wrote: >=20 > - propose default MIC algorithm Did we discuss requirements/objectives for those? =E2=80=94 implementation footprint (quantify how?) =E2=80=94 CPU consumption =E2=80=94 scalability to different MIC sizes =E2=80=94 hamming distance and other quality criteria (for different MIC = sizes) (Hamming distance is probably not very useful because one of the = objectives is to deal with the erasure of an entire pair of windows.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Dec 5 12:17:27 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE04B127978 for ; Tue, 5 Dec 2017 12:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 wTSIP9iySg_k for ; Tue, 5 Dec 2017 12:17:23 -0800 (PST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6341270AC for ; Tue, 5 Dec 2017 12:17:23 -0800 (PST) X-Originating-IP: 109.8.208.86 Received: from [192.168.0.11] (86.208.8.109.rev.sfr.net [109.8.208.86]) (Authenticated sender: alex@ackl.io) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 2FF1E41C090; Tue, 5 Dec 2017 21:17:20 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Alexander Pelov In-Reply-To: <03873E7D-C36A-4E58-B9C0-8DDC07960DDE@tzi.org> Date: Tue, 5 Dec 2017 21:17:20 +0100 Cc: lp-wan Content-Transfer-Encoding: quoted-printable Message-Id: <8B7C6D5B-E224-408D-BF68-77E7407BF199@ackl.io> References: <03873E7D-C36A-4E58-B9C0-8DDC07960DDE@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lp-wan] Minutes from today's meeting X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 20:17:26 -0000 Hi Carsten, > Le 5 d=C3=A9c. 2017 =C3=A0 20:13, Carsten Bormann a = =C3=A9crit : >=20 > On Dec 5, 2017, at 18:10, Alexander Pelov wrote: >>=20 >> - propose default MIC algorithm >=20 > Did we discuss requirements/objectives for those? >=20 > =E2=80=94 implementation footprint (quantify how?) > =E2=80=94 CPU consumption > =E2=80=94 scalability to different MIC sizes > =E2=80=94 hamming distance and other quality criteria (for different = MIC sizes) >=20 =46rom what we discussed, it should be lightweight, and mostly for = interoperability purposes. Also, should be fully software solution = (which *could* have nice HW acceleration on some platforms, but we = can=E2=80=99t count on that). Other than this, ideally it should provide protection equivalent or = greater to UDP Checksum. Not sure about the MIC sizes, but I=E2=80=99d say if we manage to fix = one size, that would be best. Further MIC definition can be specified in the SCHC-over-FOO drafts if = necessary. I=E2=80=99d say that it would be nice if we can provide = something that is sufficiently good and that works for most use-cases, = but that=E2=80=99s a personal view on this. So, in order of importance on the design goals, from what I got from the = discussion is: - lightweight (code + complexity) - simple=20 - min UDP Checksum-level protection We will explicitly not consider MICs that require more than 2 weeks to = get included in the text (so, nothing that requires a PhD in = cryptography) Any thoughts ? Alexander > (Hamming distance is probably not very useful because one of the = objectives is to deal with the erasure of an entire pair of windows.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan From nobody Wed Dec 6 00:48:27 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1461241FC for ; Wed, 6 Dec 2017 00:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr 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 eOc1YLcK7oLN for ; Wed, 6 Dec 2017 00:48:21 -0800 (PST) Received: from zproxy120.enst.fr (zproxy120.enst.fr [IPv6:2001:660:330f:2::c1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4210C120454 for ; Wed, 6 Dec 2017 00:48:21 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id D0A5481AF7 for ; Wed, 6 Dec 2017 09:48:19 +0100 (CET) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id h_iWLefLOZHk for ; Wed, 6 Dec 2017 09:48:18 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 435AF818A8 for ; Wed, 6 Dec 2017 09:48:18 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy120.enst.fr 435AF818A8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1512550098; bh=EgiHtJJndoTPyGj/7mCbY3+kCat0bpepnJEHZgXm+rM=; h=MIME-Version:From:Date:Message-ID:To; b=iphm3e2ftOLTTvnQBrIkXZEaXZ3toYeqIp2C8GsumW8OrXlfAg3BfpCdMVobN0Zx3 pA0LMTLZsFb2KWj+m0H1OzyyjJ3BpdYZwLMu8dCwokkVjBMqvbUV2nY79WCkbwIgiF XlyB/3WAqa42akTrGcng06Ro1eOJqCvw/XcUTkN4= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id TZ1PBUxW0eCB for ; Wed, 6 Dec 2017 09:48:18 +0100 (CET) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by zproxy120.enst.fr (Postfix) with ESMTPSA id DF44380266 for ; Wed, 6 Dec 2017 09:48:17 +0100 (CET) Received: by mail-io0-f172.google.com with SMTP id u42so1829891ioi.9 for ; Wed, 06 Dec 2017 00:48:17 -0800 (PST) X-Gm-Message-State: AJaThX5lbxTJxb8f4xVue3H9RxDHj29/9CYHTUxrgOUem2fci+zNKCdU QjDMauHYaOU4AOLAE2kuJqsoCiFigAAwcM6r1Zc= X-Google-Smtp-Source: AGs4zMYdXQAtCKR3Q2pub5HLqUW9LGFDHCqA8X1FgGabtjCtCxd/yM+b+vlPFy6qTQ2au3rp1NyCoZPheLLS16Hrb9E= X-Received: by 10.107.136.229 with SMTP id s98mr33223142ioi.294.1512550096431; Wed, 06 Dec 2017 00:48:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.167.130 with HTTP; Wed, 6 Dec 2017 00:47:35 -0800 (PST) In-Reply-To: <8B7C6D5B-E224-408D-BF68-77E7407BF199@ackl.io> References: <03873E7D-C36A-4E58-B9C0-8DDC07960DDE@tzi.org> <8B7C6D5B-E224-408D-BF68-77E7407BF199@ackl.io> From: Laurent Toutain Date: Wed, 6 Dec 2017 09:47:35 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Alexander Pelov Cc: Carsten Bormann , lp-wan Content-Type: multipart/alternative; boundary="001a113ed55c33f3e8055fa803d5" Archived-At: Subject: Re: [lp-wan] Minutes from today's meeting X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 08:48:25 -0000 --001a113ed55c33f3e8055fa803d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carsten, The goal is to detect frag losses, this is important in no Ack mode or in the last window. For instance, if the MIC is a sum (like IETF checksum in UDP) the a fragment loss with only 0 will not be detected. A CRC16 seems reacting better and is easy to implement. Laurent On Tue, Dec 5, 2017 at 9:17 PM, Alexander Pelov wrote: > Hi Carsten, > > > Le 5 d=C3=A9c. 2017 =C3=A0 20:13, Carsten Bormann a =C3= =A9crit : > > > > On Dec 5, 2017, at 18:10, Alexander Pelov wrote: > >> > >> - propose default MIC algorithm > > > > Did we discuss requirements/objectives for those? > > > > =E2=80=94 implementation footprint (quantify how?) > > =E2=80=94 CPU consumption > > =E2=80=94 scalability to different MIC sizes > > =E2=80=94 hamming distance and other quality criteria (for different MI= C sizes) > > > > From what we discussed, it should be lightweight, and mostly for > interoperability purposes. Also, should be fully software solution (which > *could* have nice HW acceleration on some platforms, but we can=E2=80=99t= count on > that). > > Other than this, ideally it should provide protection equivalent or > greater to UDP Checksum. > > Not sure about the MIC sizes, but I=E2=80=99d say if we manage to fix one= size, > that would be best. > > Further MIC definition can be specified in the SCHC-over-FOO drafts if > necessary. I=E2=80=99d say that it would be nice if we can provide someth= ing that > is sufficiently good and that works for most use-cases, but that=E2=80=99= s a > personal view on this. > > So, in order of importance on the design goals, from what I got from the > discussion is: > - lightweight (code + complexity) > - simple > - min UDP Checksum-level protection > > We will explicitly not consider MICs that require more than 2 weeks to ge= t > included in the text (so, nothing that requires a PhD in cryptography) > > Any thoughts ? > Alexander > > > > (Hamming distance is probably not very useful because one of the > objectives is to deal with the erasure of an entire pair of windows.) > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > _______________________________________________ > > lp-wan mailing list > > lp-wan@ietf.org > > https://www.ietf.org/mailman/listinfo/lp-wan > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > --001a113ed55c33f3e8055fa803d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carsten,

The goal is to detect f= rag losses, this is important in no Ack mode or in the last window. For ins= tance, if the MIC is a sum (like IETF checksum in UDP) the a fragment loss = with only 0 will not be detected. A CRC16 seems reacting better and is easy= to implement.

Laurent
On Tue, Dec 5, 2017 at 9:17 PM, Alexander Pelo= v <a@ac= kl.io> wrote:
Hi Carsten,
> Le 5 d=C3=A9c. 2017 =C3=A0 20:13, Carsten Bormann <cabo@tzi.org> a =C3=A9crit :
>
> On Dec 5, 2017, at 18:10, Alexander Pelov <a@ackl.io> wrote:
>>
>> - propose default MIC algorithm
>
> Did we discuss requirements/objectives for those?
>
> =E2=80=94 implementation footprint (quantify how?)
> =E2=80=94 CPU consumption
> =E2=80=94 scalability to different MIC sizes
> =E2=80=94 hamming distance and other quality criteria (for different M= IC sizes)
>

From what we discussed, it should be lightweight, and mostly for int= eroperability purposes. Also, should be fully software solution (which *cou= ld* have nice HW acceleration on some platforms, but we can=E2=80=99t count= on that).

Other than this, ideally it should provide protection equivalent or greater= to UDP Checksum.

Not sure about the MIC sizes, but I=E2=80=99d say if we manage to fix one s= ize, that would be best.

Further MIC definition can be specified in the SCHC-over-FOO drafts if nece= ssary. I=E2=80=99d say that it would be nice if we can provide something th= at is sufficiently good and that works for most use-cases, but that=E2=80= =99s a personal view on this.

So, in order of importance on the design goals, from what I got from the di= scussion is:
- lightweight (code + complexity)
- simple
- min UDP Checksum-level protection

We will explicitly not consider MICs that require more than 2 weeks to get = included in the text (so, nothing that requires a PhD in cryptography)

Any thoughts ?
Alexander


> (Hamming distance is probably not very useful because one of the objec= tives is to deal with the erasure of an entire pair of windows.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

--001a113ed55c33f3e8055fa803d5-- From nobody Fri Dec 8 05:04:27 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A596126C22 for ; Fri, 8 Dec 2017 05:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr 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 snvJnwR4j7T2 for ; Fri, 8 Dec 2017 05:04:22 -0800 (PST) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.2.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93980124D68 for ; Fri, 8 Dec 2017 05:04:22 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id C41B982547 for ; Fri, 8 Dec 2017 14:04:19 +0100 (CET) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id fvk6HwohqnOU for ; Fri, 8 Dec 2017 14:04:19 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id E00A981AAB for ; Fri, 8 Dec 2017 14:04:18 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr E00A981AAB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1512738258; bh=7cSwrEyLu3kPGFknfGv/WxtTwHut/Wyizx2G6xRiKn4=; h=MIME-Version:From:Date:Message-ID:To; b=CKqDhOIIDo0HiOLt8LzuRLKSX0hPqQ+z1M+nBWQAqGf+0QWd/VnUJ5uldcUa3np2a gDykVceY07o5OxiqxEErP4Cad4bztjZMbS9FNr3L0HnR09p5nP/ZliW2Cy+H468hsm bxviJRxexSVVcnknHxC4+pl50xHGLZQfHaYSWLjA= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id zwKX_OM5J6AW for ; Fri, 8 Dec 2017 14:04:18 +0100 (CET) Received: from mail-it0-f43.google.com (mail-it0-f43.google.com [209.85.214.43]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 6DDCB8257D for ; Fri, 8 Dec 2017 14:04:18 +0100 (CET) Received: by mail-it0-f43.google.com with SMTP id d16so4612468itj.1 for ; Fri, 08 Dec 2017 05:04:18 -0800 (PST) X-Gm-Message-State: AJaThX6Mx93EgnXtk9QKqRL14kVq6oLbfsEZ69eorr4g08UzkcI+eWTt AsWMMkbQ+hKYR+3BLZMyIlXflZeLxBERyV/VGh4= X-Google-Smtp-Source: AGs4zMaynVJG5KRKfcBPDtN4/ZUDdfKEsYeIB4JsomrMIC23JyaR/LW7slu6gZOi+6GRtXE8iK6pTOY+yzoEL29Jiyo= X-Received: by 10.107.3.170 with SMTP id e42mr44501116ioi.88.1512738256518; Fri, 08 Dec 2017 05:04:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.167.130 with HTTP; Fri, 8 Dec 2017 05:03:35 -0800 (PST) From: Laurent Toutain Date: Fri, 8 Dec 2017 14:03:35 +0100 X-Gmail-Original-Message-ID: Message-ID: To: lp-wan Content-Type: multipart/alternative; boundary="001a113ed4426b07b5055fd3d242" Archived-At: Subject: [lp-wan] CRC as MIC X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 13:04:26 -0000 --001a113ed4426b07b5055fd3d242 Content-Type: text/plain; charset="UTF-8" Hi, I'm made some test to use CRC to detect fragment losses. The protocol is the following: - generate different packet length, packet payload (uniform, repeated, random) and fragment length. - compute the packet CRC - try all the frag loss combination and compute the resulting CRC - compare the resulting CRC and the packet CRC - if the result is the same when one or several frag are lost then the CRC fails to detect an error. Since I'm testing all the possible combinations, the test can be very long when there is more that 20 fragments (2^20 tests). But the results are encouraging. The first test are with a CRC16 (0xA001), it works well with less that 16 fragments (which mean 16 frag in no Ack and a window of 16 with Ack always/on error). After the result are not that bad, for instance for 20 frag there is 2^20 possible loss pattern and only 12 lead to a erroneous detection but one of the pattern has only 6 frag losses. The other are causing trouble with more than half of the frag lost. With CRC32 the test leads to no error, only the complete frag sequence is validated by the CRC. My feeling for the document is to recommend a CRC32 as 0xEDB88320 (the one used by Ethernet). ----- The following table contains: - first column the number of loss sequence matching with the CRC - second column fragment size in byte - third column packet size in byte - fourth column the pattern leading to a CRC matching (0 lost, 1 received) - fifth column the number of lost fragment (ie the number of 0 in the previous field) - sixth column repeat the number of fragments to send the packet. For CRC16 Max frag = 1 0 200 100 0b1 losses = 0 frag = 1 Max frag = 1 0 200 200 0b1 losses = 0 frag = 1 Max frag = 3 0 200 500 0b111 losses = 0 frag = 3 Max frag = 5 0 200 1000 0b11111 losses = 0 frag = 5 Max frag = 1 0 170 100 0b1 losses = 0 frag = 1 Max frag = 2 0 170 200 0b11 losses = 0 frag = 2 Max frag = 3 0 170 500 0b111 losses = 0 frag = 3 Max frag = 6 0 170 1000 0b111111 losses = 0 frag = 6 Max frag = 1 0 140 100 0b1 losses = 0 frag = 1 Max frag = 2 0 140 200 0b11 losses = 0 frag = 2 Max frag = 4 0 140 500 0b1111 losses = 0 frag = 4 Max frag = 8 0 140 1000 0b11111111 losses = 0 frag = 8 Max frag = 1 0 110 100 0b1 losses = 0 frag = 1 Max frag = 2 0 110 200 0b11 losses = 0 frag = 2 Max frag = 5 0 110 500 0b11111 losses = 0 frag = 5 Max frag = 10 0 110 1000 0b1111111111 losses = 0 frag = 10 Max frag = 2 0 80 100 0b11 losses = 0 frag = 2 Max frag = 3 0 80 200 0b111 losses = 0 frag = 3 Max frag = 7 0 80 500 0b1111111 losses = 0 frag = 7 Max frag = 13 0 80 1000 0b1111111111111 losses = 0 frag = 13 Max frag = 2 0 50 100 0b11 losses = 0 frag = 2 Max frag = 4 0 50 200 0b1111 losses = 0 frag = 4 Max frag = 10 0 50 500 0b1111111111 losses = 0 frag = 10 Max frag = 20 0 50 1000 0b101110110011 losses = 12 frag = 20 1 50 1000 0b110101011110011 losses = 10 frag = 20 2 50 1000 0b100100111111011011 losses = 8 frag = 20 3 50 1000 0b111110001010100010 losses = 11 frag = 20 4 50 1000 0b1000001100011001000 losses = 14 frag = 20 5 50 1000 0b1010011001111101001 losses = 9 frag = 20 6 50 1000 0b1010111001111011100 losses = 8 frag = 20 7 50 1000 0b1100100000000110100 losses = 14 frag = 20 8 50 1000 0b10101111001011111010 losses = 7 frag = 20 9 50 1000 0b10110000101110001101 losses = 10 frag = 20 10 50 1000 0b10110011001101010001 losses = 10 frag = 20 *11 50 1000 0b11011111101100011101 losses = 6 frag = 20* 12 50 1000 0b11111110110100010110 losses = 7 frag = 20 13 50 1000 0b11111111111111111111 losses = 0 frag = 20 For CRC32 Max frag = 1 0 200 100 0b1 losses = 0 frag = 1 Max frag = 1 0 200 200 0b1 losses = 0 frag = 1 Max frag = 3 0 200 500 0b111 losses = 0 frag = 3 Max frag = 5 0 200 1000 0b11111 losses = 0 frag = 5 Max frag = 1 0 170 100 0b1 losses = 0 frag = 1 Max frag = 2 0 170 200 0b11 losses = 0 frag = 2 Max frag = 3 0 170 500 0b111 losses = 0 frag = 3 Max frag = 6 0 170 1000 0b111111 losses = 0 frag = 6 Max frag = 1 0 140 100 0b1 losses = 0 frag = 1 Max frag = 2 0 140 200 0b11 losses = 0 frag = 2 Max frag = 4 0 140 500 0b1111 losses = 0 frag = 4 Max frag = 8 0 140 1000 0b11111111 losses = 0 frag = 8 Max frag = 1 0 110 100 0b1 losses = 0 frag = 1 Max frag = 2 0 110 200 0b11 losses = 0 frag = 2 Max frag = 5 0 110 500 0b11111 losses = 0 frag = 5 Max frag = 10 0 110 1000 0b1111111111 losses = 0 frag = 10 Max frag = 2 0 80 100 0b11 losses = 0 frag = 2 Max frag = 3 0 80 200 0b111 losses = 0 frag = 3 Max frag = 7 0 80 500 0b1111111 losses = 0 frag = 7 Max frag = 13 0 80 1000 0b1111111111111 losses = 0 frag = 13 Max frag = 2 0 50 100 0b11 losses = 0 frag = 2 Max frag = 4 0 50 200 0b1111 losses = 0 frag = 4 Max frag = 10 0 50 500 0b1111111111 losses = 0 frag = 10 Max frag = 20 0 50 1000 0b11111111111111111111 losses = 0 frag = 20 Max frag = 5 0 20 100 0b11111 losses = 0 frag = 5 Max frag = 10 0 20 200 0b1111111111 losses = 0 frag = 10 Max frag = 25 0 20 500 0b1111111111111111111111111 losses = 0 frag = 25 --001a113ed4426b07b5055fd3d242 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'm made some test to use CRC to= detect fragment losses. The protocol is the following:
- generate diffe= rent packet length, packet payload (uniform, repeated, random) and fragment= length.
- compute the packet CRC
- try all the frag loss comb= ination and compute the resulting CRC
- compare the resulting CRC and t= he packet CRC
- if the result is the same when one or several frag are l= ost then the CRC fails to detect an
error.

Since I'm testing= all the possible combinations, the test can be very long when there is mor= e that 20 fragments (2^20 tests).

But the results are encouraging.
The first test are with a CRC16 (0xA001), it works well with less that 16=20 fragments (which mean 16 frag in no Ack and a window of 16 with Ack=20 always/on error). After the result are not that bad, for instance for 20 frag there is 2^20 possible loss pattern and only 12 lead to a=20 erroneous detection but one of the pattern has only 6 frag losses. The=20 other are causing trouble with more than half of the frag lost.

With= CRC32 the test leads to no error, only the complete frag sequence is valid= ated by the CRC.

My=C2=A0 feeling for the document is to recommend = a CRC32 as 0xEDB88320 (the one used by Ethernet).

-----
The foll= owing table contains:
- first column the number of loss sequence matchin= g with the CRC
- second column fragment size in byte
- third column p= acket size in byte
- fourth column the pattern leading to a CRC matching= (0 lost, 1 received)
- fifth column the number of lost fragment (ie the= number of 0 in the previous field)
- sixth column repeat the number of = fragments to send the packet.

For CRC16

Max frag =3D=C2=A0 1
0=C2=A0=C2=A0 200=C2=A0= =C2=A0 100=C2=A0=C2=A0 0b1=C2=A0 losses =3D 0 frag =3D 1
Max frag =3D=C2= =A0 1
0=C2=A0=C2=A0 200=C2=A0=C2=A0 200=C2=A0=C2=A0 0b1=C2=A0 losses =3D= 0 frag =3D 1
Max frag =3D=C2=A0 3
0=C2=A0=C2=A0 200=C2=A0=C2=A0 500= =C2=A0=C2=A0 0b111=C2=A0 losses =3D 0 frag =3D 3
Max frag =3D=C2=A0 50=C2=A0=C2=A0 200=C2=A0=C2=A0 1000=C2=A0=C2=A0 0b11111=C2=A0 losses =3D 0 = frag =3D 5
Max frag =3D=C2=A0 1
0=C2=A0=C2=A0 170=C2=A0=C2=A0 100=C2= =A0=C2=A0 0b1=C2=A0 losses =3D 0 frag =3D 1
Max frag =3D=C2=A0 2
0=C2= =A0=C2=A0 170=C2=A0=C2=A0 200=C2=A0=C2=A0 0b11=C2=A0 losses =3D 0 frag =3D = 2
Max frag =3D=C2=A0 3
0=C2=A0=C2=A0 170=C2=A0=C2=A0 500=C2=A0=C2=A0 = 0b111=C2=A0 losses =3D 0 frag =3D 3
Max frag =3D=C2=A0 6
0=C2=A0=C2= =A0 170=C2=A0=C2=A0 1000=C2=A0=C2=A0 0b111111=C2=A0 losses =3D 0 frag =3D 6=
Max frag =3D=C2=A0 1
0=C2=A0=C2=A0 140=C2=A0=C2=A0 100=C2=A0=C2=A0 0= b1=C2=A0 losses =3D 0 frag =3D 1
Max frag =3D=C2=A0 2
0=C2=A0=C2=A0 1= 40=C2=A0=C2=A0 200=C2=A0=C2=A0 0b11=C2=A0 losses =3D 0 frag =3D 2
Max fr= ag =3D=C2=A0 4
0=C2=A0=C2=A0 140=C2=A0=C2=A0 500=C2=A0=C2=A0 0b1111=C2= =A0 losses =3D 0 frag =3D 4
Max frag =3D=C2=A0 8
0=C2=A0=C2=A0 140=C2= =A0=C2=A0 1000=C2=A0=C2=A0 0b11111111=C2=A0 losses =3D 0 frag =3D 8
Max = frag =3D=C2=A0 1
0=C2=A0=C2=A0 110=C2=A0=C2=A0 100=C2=A0=C2=A0 0b1=C2=A0= losses =3D 0 frag =3D 1
Max frag =3D=C2=A0 2
0=C2=A0=C2=A0 110=C2=A0= =C2=A0 200=C2=A0=C2=A0 0b11=C2=A0 losses =3D 0 frag =3D 2
Max frag =3D= =C2=A0 5
0=C2=A0=C2=A0 110=C2=A0=C2=A0 500=C2=A0=C2=A0 0b11111=C2=A0 los= ses =3D 0 frag =3D 5
Max frag =3D=C2=A0 10
0=C2=A0=C2=A0 110=C2=A0=C2= =A0 1000=C2=A0=C2=A0 0b1111111111=C2=A0 losses =3D 0 frag =3D 10
Max fra= g =3D=C2=A0 2
0=C2=A0=C2=A0 80=C2=A0=C2=A0 100=C2=A0=C2=A0 0b11=C2=A0 lo= sses =3D 0 frag =3D 2
Max frag =3D=C2=A0 3
0=C2=A0=C2=A0 80=C2=A0=C2= =A0 200=C2=A0=C2=A0 0b111=C2=A0 losses =3D 0 frag =3D 3
Max frag =3D=C2= =A0 7
0=C2=A0=C2=A0 80=C2=A0=C2=A0 500=C2=A0=C2=A0 0b1111111=C2=A0 losse= s =3D 0 frag =3D 7
Max frag =3D=C2=A0 13
0=C2=A0=C2=A0 80=C2=A0=C2=A0= 1000=C2=A0=C2=A0 0b1111111111111=C2=A0 losses =3D 0 frag =3D 13
Max fra= g =3D=C2=A0 2
0=C2=A0=C2=A0 50=C2=A0=C2=A0 100=C2=A0=C2=A0 0b11=C2=A0 lo= sses =3D 0 frag =3D 2
Max frag =3D=C2=A0 4
0=C2=A0=C2=A0 50=C2=A0=C2= =A0 200=C2=A0=C2=A0 0b1111=C2=A0 losses =3D 0 frag =3D 4
Max frag =3D=C2= =A0 10
0=C2=A0=C2=A0 50=C2=A0=C2=A0 500=C2=A0=C2=A0 0b1111111111=C2=A0 l= osses =3D 0 frag =3D 10
Max frag =3D=C2=A0 20
0=C2=A0=C2=A0 50=C2=A0= =C2=A0 1000=C2=A0=C2=A0 0b101110110011=C2=A0 losses =3D 12 frag =3D 20
1= =C2=A0=C2=A0 50=C2=A0=C2=A0 1000=C2=A0=C2=A0 0b110101011110011=C2=A0 losses= =3D 10 frag =3D 20
2=C2=A0=C2=A0 50=C2=A0=C2=A0 1000=C2=A0=C2=A0 0b1001= 00111111011011=C2=A0 losses =3D 8 frag =3D 20
3=C2=A0=C2=A0 50=C2=A0=C2= =A0 1000=C2=A0=C2=A0 0b111110001010100010=C2=A0 losses =3D 11 frag =3D 204=C2=A0=C2=A0 50=C2=A0=C2=A0 1000=C2=A0=C2=A0 0b1000001100011001000=C2=A0= losses =3D 14 frag =3D 20
5=C2=A0=C2=A0 50=C2=A0=C2=A0 1000=C2=A0=C2=A0= 0b1010011001111101001=C2=A0 losses =3D 9 frag =3D 20
6=C2=A0=C2=A0 50= =C2=A0=C2=A0 1000=C2=A0=C2=A0 0b1010111001111011100=C2=A0 losses =3D 8 frag= =3D 20
7=C2=A0=C2=A0 50=C2=A0=C2=A0 1000=C2=A0=C2=A0 0b1100100000000110= 100=C2=A0 losses =3D 14 frag =3D 20
8=C2=A0=C2=A0 50=C2=A0=C2=A0 1000=C2= =A0=C2=A0 0b10101111001011111010=C2=A0 losses =3D 7 frag =3D 20
9=C2=A0= =C2=A0 50=C2=A0=C2=A0 1000=C2=A0=C2=A0 0b10110000101110001101=C2=A0 losses = =3D 10 frag =3D 20
10=C2=A0=C2=A0 50=C2=A0=C2=A0 1000=C2=A0=C2=A0 0b1011= 0011001101010001=C2=A0 losses =3D 10 frag =3D 20
11=C2=A0=C2=A0 50=C2= =A0=C2=A0 1000=C2=A0=C2=A0 0b11011111101100011101=C2=A0 losses =3D 6 frag = =3D 20
12=C2=A0=C2=A0 50=C2=A0=C2=A0 1000=C2=A0=C2=A0 0b111111101101= 00010110=C2=A0 losses =3D 7 frag =3D 20
13=C2=A0=C2=A0 50=C2=A0=C2=A0 10= 00=C2=A0=C2=A0 0b11111111111111111111=C2=A0 losses =3D 0 frag =3D 20=

For CRC32

Ma= x frag =3D=C2=A0 1
0=C2=A0=C2=A0 200=C2=A0=C2=A0 100=C2=A0=C2=A0 0b1=C2= =A0 losses =3D 0 frag =3D 1
Max frag =3D=C2=A0 1
0=C2=A0=C2=A0 200=C2= =A0=C2=A0 200=C2=A0=C2=A0 0b1=C2=A0 losses =3D 0 frag =3D 1
Max frag =3D= =C2=A0 3
0=C2=A0=C2=A0 200=C2=A0=C2=A0 500=C2=A0=C2=A0 0b111=C2=A0 losse= s =3D 0 frag =3D 3
Max frag =3D=C2=A0 5
0=C2=A0=C2=A0 200=C2=A0=C2=A0= 1000=C2=A0=C2=A0 0b11111=C2=A0 losses =3D 0 frag =3D 5
Max frag =3D=C2= =A0 1
0=C2=A0=C2=A0 170=C2=A0=C2=A0 100=C2=A0=C2=A0 0b1=C2=A0 losses =3D= 0 frag =3D 1
Max frag =3D=C2=A0 2
0=C2=A0=C2=A0 170=C2=A0=C2=A0 200= =C2=A0=C2=A0 0b11=C2=A0 losses =3D 0 frag =3D 2
Max frag =3D=C2=A0 3
= 0=C2=A0=C2=A0 170=C2=A0=C2=A0 500=C2=A0=C2=A0 0b111=C2=A0 losses =3D 0 frag= =3D 3
Max frag =3D=C2=A0 6
0=C2=A0=C2=A0 170=C2=A0=C2=A0 1000=C2=A0= =C2=A0 0b111111=C2=A0 losses =3D 0 frag =3D 6
Max frag =3D=C2=A0 1
0= =C2=A0=C2=A0 140=C2=A0=C2=A0 100=C2=A0=C2=A0 0b1=C2=A0 losses =3D 0 frag = =3D 1
Max frag =3D=C2=A0 2
0=C2=A0=C2=A0 140=C2=A0=C2=A0 200=C2=A0=C2= =A0 0b11=C2=A0 losses =3D 0 frag =3D 2
Max frag =3D=C2=A0 4
0=C2=A0= =C2=A0 140=C2=A0=C2=A0 500=C2=A0=C2=A0 0b1111=C2=A0 losses =3D 0 frag =3D 4=
Max frag =3D=C2=A0 8
0=C2=A0=C2=A0 140=C2=A0=C2=A0 1000=C2=A0=C2=A0 = 0b11111111=C2=A0 losses =3D 0 frag =3D 8
Max frag =3D=C2=A0 1
0=C2=A0= =C2=A0 110=C2=A0=C2=A0 100=C2=A0=C2=A0 0b1=C2=A0 losses =3D 0 frag =3D 1Max frag =3D=C2=A0 2
0=C2=A0=C2=A0 110=C2=A0=C2=A0 200=C2=A0=C2=A0 0b11= =C2=A0 losses =3D 0 frag =3D 2
Max frag =3D=C2=A0 5
0=C2=A0=C2=A0 110= =C2=A0=C2=A0 500=C2=A0=C2=A0 0b11111=C2=A0 losses =3D 0 frag =3D 5
Max f= rag =3D=C2=A0 10
0=C2=A0=C2=A0 110=C2=A0=C2=A0 1000=C2=A0=C2=A0 0b111111= 1111=C2=A0 losses =3D 0 frag =3D 10
Max frag =3D=C2=A0 2
0=C2=A0=C2= =A0 80=C2=A0=C2=A0 100=C2=A0=C2=A0 0b11=C2=A0 losses =3D 0 frag =3D 2
Ma= x frag =3D=C2=A0 3
0=C2=A0=C2=A0 80=C2=A0=C2=A0 200=C2=A0=C2=A0 0b111=C2= =A0 losses =3D 0 frag =3D 3
Max frag =3D=C2=A0 7
0=C2=A0=C2=A0 80=C2= =A0=C2=A0 500=C2=A0=C2=A0 0b1111111=C2=A0 losses =3D 0 frag =3D 7
Max fr= ag =3D=C2=A0 13
0=C2=A0=C2=A0 80=C2=A0=C2=A0 1000=C2=A0=C2=A0 0b11111111= 11111=C2=A0 losses =3D 0 frag =3D 13
Max frag =3D=C2=A0 2
0=C2=A0=C2= =A0 50=C2=A0=C2=A0 100=C2=A0=C2=A0 0b11=C2=A0 losses =3D 0 frag =3D 2
Ma= x frag =3D=C2=A0 4
0=C2=A0=C2=A0 50=C2=A0=C2=A0 200=C2=A0=C2=A0 0b1111= =C2=A0 losses =3D 0 frag =3D 4
Max frag =3D=C2=A0 10
0=C2=A0=C2=A0 50= =C2=A0=C2=A0 500=C2=A0=C2=A0 0b1111111111=C2=A0 losses =3D 0 frag =3D 10Max frag =3D=C2=A0 20
0=C2=A0=C2=A0 50=C2=A0=C2=A0 1000=C2=A0=C2=A0 0b1= 1111111111111111111=C2=A0 losses =3D 0 frag =3D 20
Max frag =3D=C2=A0 5<= br>0=C2=A0=C2=A0 20=C2=A0=C2=A0 100=C2=A0=C2=A0 0b11111=C2=A0 losses =3D 0 = frag =3D 5
Max frag =3D=C2=A0 10
0=C2=A0=C2=A0 20=C2=A0=C2=A0 200=C2= =A0=C2=A0 0b1111111111=C2=A0 losses =3D 0 frag =3D 10
Max frag =3D=C2=A0= 25
0=C2=A0=C2=A0 20=C2=A0=C2=A0 500=C2=A0=C2=A0 0b111111111111111111111= 1111=C2=A0 losses =3D 0 frag =3D 25
--001a113ed4426b07b5055fd3d242-- From nobody Fri Dec 8 05:11:54 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C886124D37 for ; Fri, 8 Dec 2017 05:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 ugwO8RC4C6a2 for ; Fri, 8 Dec 2017 05:11:51 -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 7AC12124B17 for ; Fri, 8 Dec 2017 05:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vB8DBmDi026262; Fri, 8 Dec 2017 14:11:48 +0100 (CET) Received: from [192.168.217.119] (p5DC7E827.dip0.t-ipconnect.de [93.199.232.39]) (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 3ytXn03SF3zDXkB; Fri, 8 Dec 2017 14:11:48 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Fri, 8 Dec 2017 14:11:46 +0100 Cc: lp-wan X-Mao-Original-Outgoing-Id: 534431506.797579-54f08e7952647e0d16d1a1e99305b123 Content-Transfer-Encoding: quoted-printable Message-Id: <7BE019F4-0231-4145-9097-A8C124885227@tzi.org> References: To: Laurent Toutain X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lp-wan] CRC as MIC X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 13:11:53 -0000 Hi Laurent, I haven=E2=80=99t tested this, but would expect slightly different = results for CRC-CCITT (a 16-bit CRC), which should be good for packets = that aren=E2=80=99t quite IPv6 MTU, IIRC. Also, the SCTP people switched to CRC-32c (=E2=89=A0 CRC32) in RFC 3309 = (they had started out with Adler32). (We selected some shorter CRCs for ROHC, maybe also worth a look.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Dec 12 22:31:14 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA13128CDC for ; Tue, 12 Dec 2017 22:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 uQkbGnZ_Jq5P for ; Tue, 12 Dec 2017 22:31:10 -0800 (PST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3F11271FD for ; Tue, 12 Dec 2017 22:31:10 -0800 (PST) X-Originating-IP: 77.207.137.204 Received: from [192.168.1.44] (204.137.207.77.rev.sfr.net [77.207.137.204]) (Authenticated sender: alex@ackl.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id D422DC5A53 for ; Wed, 13 Dec 2017 07:31:08 +0100 (CET) From: Alexander Pelov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Wed, 13 Dec 2017 07:31:11 +0100 To: lp-wan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lp-wan] Meeting agenda for next week interm X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 06:31:13 -0000 Dear all, The updated agenda for our next week interim is now on the Datatracker: = https://datatracker.ietf.org/doc/agenda-interim-2017-lpwan-13-lpwan-01/ We have quite a busy schedule for the next call, but in case you want a = slot, please contact the chairs - if we are not able to fit you for this = time, we=E2=80=99ll reserve for the next interim. Best, Pascal and Alexander From nobody Sun Dec 17 10:43:00 2017 Return-Path: X-Original-To: lp-wan@ietf.org Delivered-To: lp-wan@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BFE124319; Sun, 17 Dec 2017 10:42:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lp-wan@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151353617422.25301.1146886306694429086@ietfa.amsl.com> Date: Sun, 17 Dec 2017 10:42:54 -0800 Archived-At: Subject: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-08.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Dec 2017 18:42:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low Power Wide-Area Networks WG of the IETF. Title : LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP Authors : Ana Minaburo Laurent Toutain Carles Gomez Filename : draft-ietf-lpwan-ipv6-static-context-hc-08.txt Pages : 55 Date : 2017-12-17 Abstract: This document describes a header compression scheme and fragmentation functionality for very low bandwidth networks. These techniques are specially tailored for Low Power Wide Area Network (LPWAN). The Static Context Header Compression (SCHC) offers a great level of flexibility when processing the header fields. SCHC compression is based on a common static context stored in a LPWAN device and in the network. Static context means that the stored information does not change during packet transmission. The context describes the field values and keeps information that will not be transmitted through the constrained network. SCHC must be used for LPWAN networks because it avoids complex resynchronization mechanisms, which are incompatible with LPWAN characteristics. And also, because with SCHC, in most cases IPv6/UDP headers can be reduced to a small identifier called Rule ID. Even though, sometimes, a SCHC compressed packet will not fit in one L2 PDU, and the SCHC fragmentation protocol defined in this document may be used. This document describes the SCHC compression/decompression framework and applies it to IPv6/UDP headers. This document also specifies a fragmentation and reassembly mechanism that is used to support the IPv6 MTU requirement over LPWAN technologies. Fragmentation is mandatory for IPv6 datagrams that, after SCHC compression or when it has not been possible to apply such compression, still exceed the L2 maximum payload size. Similar solutions for other protocols such as CoAP will be described in separate documents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-08 https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-context-hc-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6-static-context-hc-08 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 Fri Dec 22 08:00:42 2017 Return-Path: X-Original-To: lp-wan@ietf.org Delivered-To: lp-wan@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B28D212D889; Fri, 22 Dec 2017 08:00:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lp-wan@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151395843469.27985.3838293292098239446@ietfa.amsl.com> Date: Fri, 22 Dec 2017 08:00:34 -0800 Archived-At: Subject: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-09.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 16:00:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low Power Wide-Area Networks WG of the IETF. Title : LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP Authors : Ana Minaburo Laurent Toutain Carles Gomez Filename : draft-ietf-lpwan-ipv6-static-context-hc-09.txt Pages : 56 Date : 2017-12-22 Abstract: This document describes a header compression scheme and fragmentation functionality for very low bandwidth networks. These techniques are specially tailored for Low Power Wide Area Network (LPWAN). The Static Context Header Compression (SCHC) offers a great level of flexibility when processing the header fields. SCHC compression is based on a common static context stored in a LPWAN device and in the network. Static context means that the stored information does not change during packet transmission. The context describes the field values and keeps information that will not be transmitted through the constrained network. SCHC must be used for LPWAN networks because it avoids complex resynchronization mechanisms, which are incompatible with LPWAN characteristics. And also, because with SCHC, in most cases IPv6/UDP headers can be reduced to a small identifier called Rule ID. Even though, sometimes, a SCHC compressed packet will not fit in one L2 PDU, and the SCHC fragmentation protocol defined in this document may be used. This document describes the SCHC compression/decompression framework and applies it to IPv6/UDP headers. This document also specifies a fragmentation and reassembly mechanism that is used to support the IPv6 MTU requirement over LPWAN technologies. Fragmentation is mandatory for IPv6 datagrams that, after SCHC compression or when it has not been possible to apply such compression, still exceed the L2 maximum payload size. Similar solutions for other protocols such as CoAP will be described in separate documents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-09 https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-context-hc-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6-static-context-hc-09 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 Fri Dec 22 08:08:40 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211E412DFE0 for ; Fri, 22 Dec 2017 08:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr 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 HDDeQzuuYSkJ for ; Fri, 22 Dec 2017 08:08:35 -0800 (PST) Received: from zproxy110.enst.fr (zproxy110.enst.fr [IPv6:2001:660:330f:2::c0]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CB812D949 for ; Fri, 22 Dec 2017 08:08:35 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 8753782D6D for ; Fri, 22 Dec 2017 17:08:33 +0100 (CET) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id 2PnvwBw4dH6a for ; Fri, 22 Dec 2017 17:08:32 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 7FD2F82D60 for ; Fri, 22 Dec 2017 17:08:32 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr 7FD2F82D60 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1513958912; bh=xu0HdWoWRFT47cCcel7hnbXvHrMvFyoCMiqgT9p8O3k=; h=MIME-Version:From:Date:Message-ID:To; b=Wf84ge8/8rhcX8YV1RZvZT5rkrY1G5fzGZIQ4cQ6JGWI2PY6VSisC84NyXZsv81qb xK72tI+tbrVHTnhIySEJSuXeHMLMqgyK3rWa3cAX5rmZn0HzLJam+WhClwkDf/AikP Zgq/kDHsUH+tchVkz2XmxFFXbALKH+xrL4CXKmjU= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id EWRp-S8eZ0gf for ; Fri, 22 Dec 2017 17:08:32 +0100 (CET) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com [209.85.214.49]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 24DEE828A6 for ; Fri, 22 Dec 2017 17:08:32 +0100 (CET) Received: by mail-it0-f49.google.com with SMTP id f190so15106698ita.5 for ; Fri, 22 Dec 2017 08:08:32 -0800 (PST) X-Gm-Message-State: AKGB3mI6sjBJi6EGxc0Vac19gXCC1HmdbAn5j7me3iDt2gwOnVrKIfrC YE8cjf4aTHUBiJ5JQVuutJS+TFcDlepU9943lKo= X-Google-Smtp-Source: ACJfBotFybvb7oQymZIRl0dhteMiLfuqaEduKgS7T6i+Edm8/xSPEjzepAeH3RW7I8Wa7wALlPEOjRm7sCdSvwcQPdQ= X-Received: by 10.36.90.11 with SMTP id v11mr17803563ita.127.1513958910707; Fri, 22 Dec 2017 08:08:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.95.80 with HTTP; Fri, 22 Dec 2017 08:07:50 -0800 (PST) In-Reply-To: <151395843489.27985.18312491575583928930.idtracker@ietfa.amsl.com> References: <151395843489.27985.18312491575583928930.idtracker@ietfa.amsl.com> From: Laurent Toutain Date: Fri, 22 Dec 2017 17:07:50 +0100 X-Gmail-Original-Message-ID: Message-ID: To: lp-wan Content-Type: multipart/alternative; boundary="001a113757a013d9a70560f0079d" Archived-At: Subject: [lp-wan] Fwd: New Version Notification for draft-ietf-lpwan-ipv6-static-context-hc-09.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 16:08:39 -0000 --001a113757a013d9a70560f0079d Content-Type: text/plain; charset="UTF-8" Hi, As a Christmas present, here is the latest version of the draft. It includes the changes we discussed Tuesday. The state machine has also been changed to add bitmap retransmission and the examples to include the last modifications on bitmap. Merry Christmas Ana, Carles and Laurent ---------- Forwarded message ---------- From: Date: Fri, Dec 22, 2017 at 5:00 PM Subject: New Version Notification for draft-ietf-lpwan-ipv6-static-context-hc-09.txt To: Laurent Toutain , Ana Minaburo < ana@ackl.io>, lpwan-chairs@ietf.org, Laurent Toutain < laurent.toutain@imt-atlantique.fr>, Carles Gomez A new version of I-D, draft-ietf-lpwan-ipv6-static-context-hc-09.txt has been successfully submitted by Laurent Toutain and posted to the IETF repository. Name: draft-ietf-lpwan-ipv6-static-context-hc Revision: 09 Title: LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP Document date: 2017-12-22 Group: lpwan Pages: 56 URL: https://www.ietf.org/internet-drafts/draft-ietf-lpwan-ipv6- static-context-hc-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6- static-context-hc/ Htmlized: https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static- context-hc-09 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-lpwan- ipv6-static-context-hc-09 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6- static-context-hc-09 Abstract: This document describes a header compression scheme and fragmentation functionality for very low bandwidth networks. These techniques are specially tailored for Low Power Wide Area Network (LPWAN). The Static Context Header Compression (SCHC) offers a great level of flexibility when processing the header fields. SCHC compression is based on a common static context stored in a LPWAN device and in the network. Static context means that the stored information does not change during packet transmission. The context describes the field values and keeps information that will not be transmitted through the constrained network. SCHC must be used for LPWAN networks because it avoids complex resynchronization mechanisms, which are incompatible with LPWAN characteristics. And also, because with SCHC, in most cases IPv6/UDP headers can be reduced to a small identifier called Rule ID. Even though, sometimes, a SCHC compressed packet will not fit in one L2 PDU, and the SCHC fragmentation protocol defined in this document may be used. This document describes the SCHC compression/decompression framework and applies it to IPv6/UDP headers. This document also specifies a fragmentation and reassembly mechanism that is used to support the IPv6 MTU requirement over LPWAN technologies. Fragmentation is mandatory for IPv6 datagrams that, after SCHC compression or when it has not been possible to apply such compression, still exceed the L2 maximum payload size. Similar solutions for other protocols such as CoAP will be described in separate documents. 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. The IETF Secretariat --001a113757a013d9a70560f0079d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

As a Christmas p= resent, here is the latest version of the draft. It includes the changes we= discussed Tuesday.
The state machine has also been changed to ad= d bitmap retransmission and the examples to include the
last modif= ications on bitmap.

Merry Christmas

Ana, Carles a= nd Laurent

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Dec 22, 2017 at = 5:00 PM
Subject: New Version Notification for draft-ietf-lpwan-ipv6-stat= ic-context-hc-09.txt
To: Laurent Toutain <Laurent.Toutain@imt-atlantique.fr>, Ana Mi= naburo <ana@ackl.io>, lpwan-chairs@ietf.org, Laurent Toutain <= ;laurent.toutain@imt-a= tlantique.fr>, Carles Gomez <carlesgo@entel.upc.edu>



A new version of I-D, draft-ietf-lpwan-ipv6-static-context-hc-09.txt has been successfully submitted by Laurent Toutain and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-lpwan-ipv6-static-= context-hc
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A009
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LPWAN Static Context Header Compre= ssion (SCHC) and fragmentation for IPv6 and UDP
Document date:=C2=A0 2017-12-22
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lpwan
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 56
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draf= t-ietf-lpwan-ipv6-static-context-hc-09.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-<= wbr>static-context-hc/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-co= ntext-hc-09
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-lpwan= -ipv6-static-context-hc-09
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf= -lpwan-ipv6-static-context-hc-09

Abstract:
=C2=A0 =C2=A0This document describes a header compression scheme and fragme= ntation
=C2=A0 =C2=A0functionality for very low bandwidth networks.=C2=A0 These tec= hniques are
=C2=A0 =C2=A0specially tailored for Low Power Wide Area Network (LPWAN).
=C2=A0 =C2=A0The Static Context Header Compression (SCHC) offers a great le= vel of
=C2=A0 =C2=A0flexibility when processing the header fields.=C2=A0 SCHC comp= ression is
=C2=A0 =C2=A0based on a common static context stored in a LPWAN device and = in the
=C2=A0 =C2=A0network.=C2=A0 Static context means that the stored informatio= n does not
=C2=A0 =C2=A0change during packet transmission.=C2=A0 The context describes= the field
=C2=A0 =C2=A0values and keeps information that will not be transmitted thro= ugh the
=C2=A0 =C2=A0constrained network.

=C2=A0 =C2=A0SCHC must be used for LPWAN networks because it avoids complex=
=C2=A0 =C2=A0resynchronization mechanisms, which are incompatible with LPWA= N
=C2=A0 =C2=A0characteristics.=C2=A0 And also, because with SCHC, in most ca= ses IPv6/UDP
=C2=A0 =C2=A0headers can be reduced to a small identifier called Rule ID.= =C2=A0 Even
=C2=A0 =C2=A0though, sometimes, a SCHC compressed packet will not fit in on= e L2
=C2=A0 =C2=A0PDU, and the SCHC fragmentation protocol defined in this docum= ent may
=C2=A0 =C2=A0be used.

=C2=A0 =C2=A0This document describes the SCHC compression/decompression fra= mework
=C2=A0 =C2=A0and applies it to IPv6/UDP headers.=C2=A0 This document also s= pecifies a
=C2=A0 =C2=A0fragmentation and reassembly mechanism that is used to support= the
=C2=A0 =C2=A0IPv6 MTU requirement over LPWAN technologies.=C2=A0 Fragmentat= ion is
=C2=A0 =C2=A0mandatory for IPv6 datagrams that, after SCHC compression or w= hen it
=C2=A0 =C2=A0has not been possible to apply such compression, still exceed = the L2
=C2=A0 =C2=A0maximum payload size.=C2=A0 Similar solutions for other protoc= ols such as
=C2=A0 =C2=A0CoAP will be described in separate documents.




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


--001a113757a013d9a70560f0079d-- From nobody Fri Dec 22 08:19:30 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2035127AD4 for ; Fri, 22 Dec 2017 08:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 7gjpLpY0npK3 for ; Fri, 22 Dec 2017 08:19:28 -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 C618312778E for ; Fri, 22 Dec 2017 08:19:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4361; q=dns/txt; s=iport; t=1513959567; x=1515169167; h=from:to:subject:date:message-id:mime-version; bh=hQ0WtHp0bK7Im7MkvjOdk6wRsrI6idBRJdc+5YxfKH8=; b=gvaEwMVZmLPw0GzyCR5SAHqDGdiHllZ0tee7WQFGfVHvhJ6nkL4iGATd ATkT87+S+OU0m/UZt6n4Qy/lVc23whtRSqsmXvoUvvrey+rxEEkj9RRfa NrbB/tk60WiDvLQSK1Epwlrd75ePqvByDOnV36fpKs7khu8gEigIlJgbn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAwDMLz1a/5pdJa1dGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJKdGZ0Lp01k1iFURSCAQoliWZBFgEBAQEBAQEBAWsohVdeAYEAJgE?= =?us-ascii?q?EG4lCZBCnLIpRAQEBAQYBAQEBAQEdBYQMghKBVoFphl0BAYE1hjQFo0kCh3+Dc?= =?us-ascii?q?Yk0giCGFYtOjSGJMQIRGQGBOgEmByuBT28VgmeEVooXgRYBAQE?= X-IronPort-AV: E=Sophos;i="5.45,441,1508803200"; d="scan'208,217";a="333726492" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2017 16:19:26 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vBMGJQmH009576 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Dec 2017 16:19:26 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 22 Dec 2017 10:19:26 -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.1320.000; Fri, 22 Dec 2017 10:19:25 -0600 From: "Pascal Thubert (pthubert)" To: lp-wan Thread-Topic: WGLC on SCHC for IPv6 and UDP Thread-Index: AdN7QGcXhHm9yH+kRsq+sTifSlmg2w== Date: Fri, 22 Dec 2017 16:19:17 +0000 Deferred-Delivery: Fri, 22 Dec 2017 16:18:46 +0000 Message-ID: <4c88208e9e514b5994c3c8731718c46c@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.27] Content-Type: multipart/alternative; boundary="_000_4c88208e9e514b5994c3c8731718c46cXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [lp-wan] WGLC on SCHC for IPv6 and UDP X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 16:19:30 -0000 --_000_4c88208e9e514b5994c3c8731718c46cXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG: As discussed during the last interim, we are starting a WGLC on the "LPWAN = Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP= " document: https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/ This is a fundamental work for the WG, so please, DO review the document an= d DO provide your comments and remarks if you see any issues. In order to cover the season break, this WGLC will end in three+ weeks, on = January 15th, 2018, 23h55 CEST, right before our next interim meeting. Best, Pascal and Alexander --_000_4c88208e9e514b5994c3c8731718c46cXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG:

 

As discussed during the last interim, we are star= ting a WGLC on the “LPWAN Static Context Header Compression (SCHC) an= d fragmentation for IPv6 and UDP” document:

https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/<= /span>

 

This is a fundamental work for the WG, so please,= DO review the document and DO provide your comments and remarks if you see= any issues.

 

In order to cover the season break, this WGLC wil= l end in three+ weeks, on January 15th, 2018, 23h55 CEST, right before = our next interim meeting.

 

Best,

Pascal and Alexander=

 

--_000_4c88208e9e514b5994c3c8731718c46cXCHRCD001ciscocom_--