From 6lowpan-bounces@ietf.org Tue Oct 09 08:51:42 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEX6-0002XK-ML; Tue, 09 Oct 2007 08:49:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEX5-0002Rn-1X for 6lowpan@ietf.org; Tue, 09 Oct 2007 08:49:55 -0400 Received: from maild.telecomitalia.it ([156.54.233.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfEWz-0001I8-6l for 6lowpan@ietf.org; Tue, 09 Oct 2007 08:49:49 -0400 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 14:49:46 +0200 Received: from PTPEVS107BA020.idc.cww.telecomitalia.it ([156.54.241.225]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 14:49:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Oct 2007 14:49:36 +0200 Message-ID: <2905264D217FE34F88AF76D7BBC712190406AA2B@PTPEVS107BA020.idc.cww.telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: five questions Thread-Index: AcgKctlgpTa2ghedREGY+WsN3d6sJQ== From: "Porcu Giorgio" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 09 Oct 2007 12:49:46.0493 (UTC) FILETIME=[DF0F4AD0:01C80A72] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [6lowpan] five questions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hello to everyone, I'm a student from the University of Pisa and I'm carrying out a search = thesis about 6LowPan. I have some questions about how 6LowPan handles IPv6 address.=20 If we use other kind (instead of LinkLocal address) of address we have = to carry inline at least (and always) the 64-bit of prefix ...is this = claim correct?=20 - If the destinator and the originator have in common subnet prefix, but = they don't use Link Local address, do we have to put both in the 6LowPan = frame? at page 17 of the RFC4944, in fact, I read: >>PC: Prefix compressed (link-local prefix assumed). - at page 16 it's written: >>The following IPv6 header values are expected to be common on 6LoWPAN = networks, so the HC1 header has been constructed to efficiently compress = them from the onset: Version is IPv6; both IPv6 source >> and = destination addresses are link local; the IPv6 interface identifiers = (bottom 64 bits) for the source or destination addresses can be inferred = from the layer two source and destination addresses (of course, >> this = is only possible for interface identifiers derived from an underlying = 802.15.4 MAC address); ... It means that (if we don't use the mesh addressing field) the LinkLocal = compression is possible only with EUI-64 bit mac address? If I am wrong: = how can we distinguish if the II_ID contains or not the PANID ? - Another question that I have deals with the HC1_G draft. At the page number 4, it's written: >> LOWPAN_HC1g is identified by dispatch value 0x30, whereas = LOWPAN_HC1 is identified by dispatch value 0x10. but the dispatch HC1 (compressed) isn't identified by the value 0x42 = (0x41 in the case of uncompressed IPv6 header)??? - Again in the HC1_G draft and at the page 5: >> To support compression of global unicast addresses, LOWPAN_HC1g = assumes that a PAN is assigned one compressible 64-bit global IP = prefix. When either the source or destination address matches the >> compressible global IP prefix, the prefix can be elided. I don't understand very well what CGP prefix means....maybe is it the = 64-bit mac address of the coordinator? Who determine this prefix in a PAN?? - Last question: at the page 5: >> Full 128-bit IPv6 address elided: ...The 64-bit interface = identifier is derived either from the LoWPAN Mesh Addressing header = or from the IEEE 802.15.4 link header. The link-layer addresses used to >> derive the 64-bit interface identifier is a short address, the short = address describes the lower 16 bits of the interface identifier. The = upper 48 bits are assumed to be all zeros. Does it mean that we have to use only short address to elide Interface = Identifier ID in HC1_G ??? I'm sorry for this wide and heavy email, I hope that someone will have = the patience to read all and , I wish, to replay. Thanks a lot. Giorgio _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 26 14:18:51 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTl0-0003s5-GI; Fri, 26 Oct 2007 14:18:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTky-0003rc-Uu for 6lowpan@lists.ietf.org; Fri, 26 Oct 2007 14:18:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlTkx-0007GY-OZ for 6lowpan@lists.ietf.org; Fri, 26 Oct 2007 14:18:04 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 26 Oct 2007 11:18:03 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9QII1C2006436; Fri, 26 Oct 2007 11:18:01 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l9QIHwlf000878; Fri, 26 Oct 2007 18:18:01 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 14:17:29 -0400 Received: from [161.44.71.191] ([161.44.71.191]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 14:17:28 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CAF96A5-DBDC-4AC6-845A-7E0CB0D66D90@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Fri, 26 Oct 2007 14:16:24 -0400 To: rsn@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 26 Oct 2007 18:17:28.0960 (UTC) FILETIME=[77D36800:01C817FC] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15506.002 X-TM-AS-Result: No--11.393900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=418; t=1193422681; x=1194286681; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20RL2N=20BOF=20in=20Vancouver |Sender:=20; bh=o8GIK1d0Qr4bB3NtfOi3z7T9SYvgrnHRRJMR8niySpo=; b=EdLQ/PwzAdiuIOXKQT5JgSLNqOfMCfTiX2Kjidjr/qy4ChysYlLFC4wfqW7tYY4m99XlfBji /NlP1POtw5xWtqG1iWwLHHhCwcC4301nBj8gsCnrv1m/H4aPON7up0eT; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 6lowpan <6lowpan@lists.ietf.org> Subject: [6lowpan] RL2N BOF in Vancouver X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Dear list, The RL2N BOF has been approved for Vancouver. I've updated www.employees/~jvasseur with the related information - please provide your comments. We're planning to have a pre-WG meeting in Boston Nov 15 with 15-20 people who expressed some interest in this work. Let us know if you would like to attend. Otherwise, we will post the minutes of that meeting on the list. Thanks. JP. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 26 14:33:20 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTzV-000421-1U; Fri, 26 Oct 2007 14:33:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTzT-0003br-8C for 6lowpan@lists.ietf.org; Fri, 26 Oct 2007 14:33:03 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlTzN-0007mI-3u for 6lowpan@lists.ietf.org; Fri, 26 Oct 2007 14:33:03 -0400 X-IronPort-AV: E=Sophos;i="4.21,335,1188792000"; d="scan'208";a="135678658" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2007 14:32:41 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9QIWfqn004291; Fri, 26 Oct 2007 14:32:41 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9QIWfBE015336; Fri, 26 Oct 2007 18:32:41 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 14:32:40 -0400 Received: from [161.44.71.191] ([161.44.71.191]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 14:32:40 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04F7625E-0178-43CC-9EFB-35BE632DEC1B@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Fri, 26 Oct 2007 14:31:36 -0400 To: rsn@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 26 Oct 2007 18:32:40.0542 (UTC) FILETIME=[972BC7E0:01C817FE] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15506.002 X-TM-AS-Result: No--11.393900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=422; t=1193423561; x=1194287561; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20RL2N=20BOF=20in=20Vancouver |Sender:=20 |To:=20rsn@ietf.org; bh=py/0pHiKAfeAktfnBTNKSDEeaugKDekQFY2rZs6Jqlc=; b=iBbj/KpylU9mPDFqYHFU37wZa7OMNR+BrxAgwlh6qTcEsX1pnvw6gQibjMsl6v7fNh4RSHiz cTV/aWkYiCN/gvsfFn38wwgN3/8wNATLXt4L3XvmHIUA13+FOYvWz8F/; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 6lowpan <6lowpan@lists.ietf.org> Subject: [6lowpan] RL2N BOF in Vancouver X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Dear list, The RL2N BOF has been approved for Vancouver. I've updated www.employees.org/~jvasseur with the related information - please provide your comments. We're planning to have a pre-WG meeting in Boston Nov 15 with 15-20 people who expressed some interest in this work. Let us know if you would like to attend. Otherwise, we will post the minutes of that meeting on the list. Thanks. JP. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 29 13:41:09 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYbB-0000cX-7i; Mon, 29 Oct 2007 13:40:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYb8-0000cH-Eo for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 13:40:23 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImYZk-0003u5-IC for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 13:40:22 -0400 Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.1/8.13.5) with ESMTP id l9THcd8K029119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Oct 2007 10:38:40 -0700 (PDT) Message-ID: <47261A9A.3030906@eecs.berkeley.edu> Date: Mon, 29 Oct 2007 10:38:34 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: JP Vasseur References: <04F7625E-0178-43CC-9EFB-35BE632DEC1B@cisco.com> In-Reply-To: <04F7625E-0178-43CC-9EFB-35BE632DEC1B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [6lowpan] Re: [RSN] RL2N BOF in Vancouver X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org JP - the RL2N charter looks good. My only concern is over the second L in L2 - are these networks intrinsically lossy, or is that just due to the current protocols? I'll be at the meeting in Boston. Question about Vancouver: I've never been to an IETF meeting before. Are there any important rules/regs that a newbie should know before attending? The IEEE has lots... Related question: what day(s)/time(s) should we plan on attending? ksjp JP Vasseur wrote: > Dear list, > > The RL2N BOF has been approved for Vancouver. > > I've updated www.employees.org/~jvasseur with the related information > - please provide > your comments. > > We're planning to have a pre-WG meeting in Boston Nov 15 with 15-20 > people > who expressed some interest in this work. Let us know if you would > like to attend. > Otherwise, we will post the minutes of that meeting on the list. > > Thanks. > > JP. > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 29 13:54:42 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYot-0001ET-RF; Mon, 29 Oct 2007 13:54:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYos-0001Ci-E9 for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 13:54:34 -0400 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImYok-0004eY-1G for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 13:54:34 -0400 Received: from dnab422275.stanford.edu ([171.66.34.117]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1ImYoZ-0006hK-27; Mon, 29 Oct 2007 10:54:15 -0700 In-Reply-To: <47261A9A.3030906@eecs.berkeley.edu> References: <04F7625E-0178-43CC-9EFB-35BE632DEC1B@cisco.com> <47261A9A.3030906@eecs.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C86FC94-3256-4C61-AB6A-0F187ECED326@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Mon, 29 Oct 2007 10:54:19 -0700 To: Kris Pister X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: c6b7461a7773f457175e025605fe13fe X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [6lowpan] Re: [RSN] RL2N BOF in Vancouver X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Oct 29, 2007, at 10:38 AM, Kris Pister wrote: > JP - the RL2N charter looks good. My only concern is over the > second L in L2 - are these networks intrinsically lossy, or is that > just due to the current protocols? The "lossy" means at the link layer. There aren't any wireless link layers that don't have losses. They might mask them to higher layers through retransmissions, but losses occur. Of course, a network layer may select links that have a very low loss rate, but, well, that's part of what all of this effort is about. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 29 14:00:01 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYu8-00040z-3a; Mon, 29 Oct 2007 14:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYu7-00040K-0u for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 13:59:59 -0400 Received: from mail180.messagelabs.com ([85.158.139.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ImYtz-0004tE-OZ for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 13:59:59 -0400 X-VirusChecked: Checked X-Env-Sender: nicolas.chevrollier@tno.nl X-Msg-Ref: server-7.tower-180.messagelabs.com!1193680780!11593321!1 X-StarScan-Version: 5.5.12.14.2; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 2753 invoked from network); 29 Oct 2007 17:59:41 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-7.tower-180.messagelabs.com with SMTP; 29 Oct 2007 17:59:41 -0000 Received: from ms-dt01thalia.tsn.tno.nl (ms-dt01thalia.tno.nl [134.221.225.157]) by zeus.tno.nl (8.11.7p1+Sun/8.11.7) with ESMTP id l9THxe028531; Mon, 29 Oct 2007 18:59:40 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Oct 2007 18:59:40 +0100 Message-ID: <7877C5C0B5CC894AB26113CF06CF8863D3DA6D@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <04F7625E-0178-43CC-9EFB-35BE632DEC1B@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] RL2N BOF in Vancouver thread-index: AcgX/qfG00QBOQ85SeGUV5zPugCZAwCVmS/g References: <04F7625E-0178-43CC-9EFB-35BE632DEC1B@cisco.com> From: "Chevrollier, N.G. (Nicolas)" To: "JP Vasseur" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 6lowpan <6lowpan@lists.ietf.org> Subject: [6lowpan] RE: [RSN] RL2N BOF in Vancouver X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org HI=20JP, Could=20you=20give=20an=20example=20of=20L2Ns=20in=20"smart=20cities"?=20I= =20am=20not=20sure=20to get=20what=20it=20encompasses. Best, Nicolas >=20-----Original=20Message----- >=20From:=20JP=20Vasseur=20[mailto:jvasseur@cisco.com] >=20Sent:=20Friday,=20October=2026,=202007=208:32=20PM >=20To:=20rsn@ietf.org >=20Cc:=206lowpan >=20Subject:=20[RSN]=20RL2N=20BOF=20in=20Vancouver >=20 >=20Dear=20list, >=20 >=20The=20RL2N=20BOF=20has=20been=20approved=20for=20Vancouver. >=20 >=20I've=20updated=20www.employees.org/~jvasseur=20with=20the=20related=20= information >=20-=20please=20provide >=20your=20comments. >=20 >=20We're=20planning=20to=20have=20a=20pre-WG=20meeting=20in=20Boston=20No= v=2015=20with=2015-20 >=20people >=20who=20expressed=20some=20interest=20in=20this=20work.=20Let=20us=20kno= w=20if=20you=20would >=20like=20to=20attend. >=20Otherwise,=20we=20will=20post=20the=20minutes=20of=20that=20meeting=20= on=20the=20list. >=20 >=20Thanks. >=20 >=20JP. >=20 >=20 >=20_______________________________________________ >=20RSN=20mailing=20list >=20RSN@ietf.org >=20https://www1.ietf.org/mailman/listinfo/rsn This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 29 14:32:02 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZOb-0001hQ-FC; Mon, 29 Oct 2007 14:31:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZOa-0001hF-KZ for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 14:31:29 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImZOH-0006qi-EE for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 14:31:28 -0400 Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.1/8.13.5) with ESMTP id l9TIUg3S000243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Oct 2007 11:30:43 -0700 (PDT) Message-ID: <472626CD.7050104@eecs.berkeley.edu> Date: Mon, 29 Oct 2007 11:30:37 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Levis References: <04F7625E-0178-43CC-9EFB-35BE632DEC1B@cisco.com> <47261A9A.3030906@eecs.berkeley.edu> <0C86FC94-3256-4C61-AB6A-0F187ECED326@cs.stanford.edu> In-Reply-To: <0C86FC94-3256-4C61-AB6A-0F187ECED326@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [6lowpan] Re: [RSN] RL2N BOF in Vancouver X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hmm. You could probably make the claim that there aren't any wired link layers that don't have losses, too. I guess that it's all relative. What are the loss rates in wired systems? Certainly it is possible to find path/channel combinations in 802.15.4 networks that have zero loss at the link layer over periods of many weeks and millions of packets, which I think gets called "carrier class" reliability. If we're smart, we'll be able to build networks that use such path/channel combos almost exclusively. As you point out, this is a DLL/MAC issue, so its solution doesn't belong in this forum (that's what the 15.4E task group was created to address). But the abstraction does belong here, and it's important to understand what's really going on in 15.4 (and other RF) channels to make intelligent routing decisions on them. To date most of the published WSN channel models have interpreted abrupt multi-path interference as a lossy path, and that will lead to bad decisions at the routing layer. ksjp Philip Levis wrote: > On Oct 29, 2007, at 10:38 AM, Kris Pister wrote: > >> JP - the RL2N charter looks good. My only concern is over the second >> L in L2 - are these networks intrinsically lossy, or is that just due >> to the current protocols? > > The "lossy" means at the link layer. There aren't any wireless link > layers that don't have losses. They might mask them to higher layers > through retransmissions, but losses occur. Of course, a network layer > may select links that have a very low loss rate, but, well, that's > part of what all of this effort is about. > > Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 29 14:34:23 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZRA-0003yS-RB; Mon, 29 Oct 2007 14:34:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZRA-0003yN-DE for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 14:34:08 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImZR6-0007FE-Ku for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 14:34:08 -0400 Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.1/8.13.5) with ESMTP id l9TIY00H000352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Oct 2007 11:34:01 -0700 (PDT) Message-ID: <47262793.3030809@eecs.berkeley.edu> Date: Mon, 29 Oct 2007 11:33:55 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Chevrollier, N.G. (Nicolas)" References: <04F7625E-0178-43CC-9EFB-35BE632DEC1B@cisco.com> <7877C5C0B5CC894AB26113CF06CF8863D3DA6D@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7877C5C0B5CC894AB26113CF06CF8863D3DA6D@ms-dt01thalia.tsn.tno.nl> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [6lowpan] Re: [RSN] RL2N BOF in Vancouver X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1250175830==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1250175830== Content-Type: multipart/alternative; boundary="------------000407070700090506090305" This is a multi-part message in MIME format. --------------000407070700090506090305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I don't know if this is what JP's thinking about, but this is a cool company: http://www.StreetlineNetworks.com ksjp Chevrollier, N.G. (Nicolas) wrote: > HI JP, > > Could you give an example of L2Ns in "smart cities"? I am not sure to > get what it encompasses. > > Best, > > Nicolas > > >> -----Original Message----- >> From: JP Vasseur [mailto:jvasseur@cisco.com] >> Sent: Friday, October 26, 2007 8:32 PM >> To: rsn@ietf.org >> Cc: 6lowpan >> Subject: [RSN] RL2N BOF in Vancouver >> >> Dear list, >> >> The RL2N BOF has been approved for Vancouver. >> >> I've updated www.employees.org/~jvasseur with the related information >> - please provide >> your comments. >> >> We're planning to have a pre-WG meeting in Boston Nov 15 with 15-20 >> people >> who expressed some interest in this work. Let us know if you would >> like to attend. >> Otherwise, we will post the minutes of that meeting on the list. >> >> Thanks. >> >> JP. >> >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn >> > > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > --------------000407070700090506090305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I don't know if this is what JP's thinking about, but this is a cool company:

http://www.StreetlineNetworks.com

ksjp

Chevrollier, N.G. (Nicolas) wrote: 
HI JP,

Could you give an example of L2Ns in "smart cities"? I am not sure to
get what it encompasses.

Best,

Nicolas

  
-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Friday, October 26, 2007 8:32 PM
To: rsn@ietf.org
Cc: 6lowpan
Subject: [RSN] RL2N BOF in Vancouver

Dear list,

The RL2N BOF has been approved for Vancouver.

I've updated www.employees.org/~jvasseur with the related information
- please provide
your comments.

We're planning to have a pre-WG meeting in Boston Nov 15 with 15-20
people
who expressed some interest in this work. Let us know if you would
like to attend.
Otherwise, we will post the minutes of that meeting on the list.

Thanks.

JP.


_______________________________________________
RSN mailing list
RSN@ietf.org
https://www1.ietf.org/mailman/listinfo/rsn
    

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html


_______________________________________________
RSN mailing list
RSN@ietf.org
https://www1.ietf.org/mailman/listinfo/rsn
--------------000407070700090506090305-- --===============1250175830== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1250175830==-- From 6lowpan-bounces@ietf.org Mon Oct 29 15:04:07 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZtI-0005zs-Iy; Mon, 29 Oct 2007 15:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZtG-0005zb-IR for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 15:03:10 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImZqv-0000AY-7W for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 15:03:10 -0400 Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.1/8.13.5) with ESMTP id l9TJ0fnN001065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Oct 2007 12:00:42 -0700 (PDT) Message-ID: <47262DD4.8040905@eecs.berkeley.edu> Date: Mon, 29 Oct 2007 12:00:36 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Geoff Mulligan References: <1193681449.8079.16.camel@dellx1> In-Reply-To: <1193681449.8079.16.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92788d1b003e07b99aff407d30cf4598 Cc: 6lowpan <6lowpan@lists.ietf.org>, Phy/DLL/Network/Transport group Subject: [6lowpan] Re: [sp100.11a-pdnt] Re: Transport layer requirements; first cut X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0018212833==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0018212833== Content-Type: multipart/alternative; boundary="------------090001040506080205010106" This is a multi-part message in MIME format. --------------090001040506080205010106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit yes, that much is clear. But why number 8 byte chunks instead of 15.4 payloads? When the originator fragments the packet, it's going to break it up into a small number of fragments that fit into mesh/mac/phy payloads, not a byte stream with unknown (and shifting?!? "fragment overlap"?!?) boundaries. I don't get the 16 bit datagram tag either. That implies that we might be sending thousands of separately fragmented datagrams during the timeout+transit period for a single one? The radio can't even do that at 100% duty cycle. It seems like even with the 5 bits for the frag-type, this could all have fit into 2 bytes, not 5. So with the 1280 requirement, and use cases that I understand, I get 2 bytes. Are there other things that I'm missing that lead to 4 and 5 bytes for first and subsequent? ksjp Geoff Mulligan wrote: > The design was based on the requirement to support 1280byte MTU to IP. > > geoff > > On Mon, 2007-10-29 at 10:43 -0700, Kris Pister wrote: > >> Discussing simple ERP seems like a worthy sp100 topic, but it probably >> doesn't matter that much if you believe my claim that even 1280 byte >> datagrams will arrive with all fragments intact >99% of the time. >> >> Can anyone explain why 6LoWPAN chose such a funky fragment header? >> They must have been trying to address something important to spend so >> many bytes on it. >> >> ksjp >> >> Pascal Thubert (pthubert) wrote: >> >>> Hi Kris: >>> >>> Resending one lost fragment under the fragmentation sub-layer would be >>> neat indeed. >>> >>> IBM's SNA employed error recovery procedures (ERP) at layer 2, in >>> particular SDLC, LAPB and 802.2. Note that none of these can actually >>> resend a specific piece and all require orderly delivery. HPR's RTP >>> could do it but was very confidential, mostly used with IBM's parallel >>> Sysplex. >>> >>> TCP supports but does not like out of order. Fast recovery is quickly >>> triggered. >>> >>> I'd be interested in discussing the requirements for an ERP at DLL. I'm >>> not sure that it is in scope for ISA100.11a right now, is it? I do not >>> mean it's wrong, just that we are considering real issues, and real >>> solutions. >>> >>> Pascal >>> >>> >>> >>>> -----Original Message----- >>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>> Sent: Sunday, October 28, 2007 10:30 PM >>>> To: Pascal Thubert (pthubert) >>>> Cc: Phy/DLL/Network/Transport group >>>> Subject: Re: [sp100.11a-pdnt] Re: Transport layer requirements; first >>>> >>>> >>> cut >>> >>> >>>> * fragmentation >>>> Here's the way that I see fragmentation: >>>> Mote A fragments the packet. The first fragment contains the >>>> fragmentation info and a delete/ARQ mode bit and time limit: "if you >>>> haven't seen all 9 segments in 30 seconds, either {delete what you >>>> >>>> >>> have} >>> >>> >>>> or {send me a message saying which ones you're missing}". >>>> These packets work their way through the network, potentially over many >>>> paths, each arriving at its destination potentially out of order but >>>> with over 99.9% probability. The receiving mote reassembles the lot, >>>> and checks the transport MIC on the entire thing (no transport MIC per >>>> segment, just DLL MIC). >>>> If we can't hit 100B of transport payload per packet, we need to go >>>> >>>> >>> back >>> >>> >>>> and fix 6LoWPAN (well, actually I already know that we have to fix >>>> 6LoWPAN), so your TFTP chunk will take no more than 6 fragments no >>>> matter what the security level is. So the probability of losing one or >>>> more segments is less than 1%. Even a 1280B chunk should have less >>>> >>>> >>> than >>> >>> >>>> 1% probability of a missing segment. I can't *prove* that, but I have >>>> >>>> >>> a >>> >>> >>>> LOT of data from real deployments to support the assertion. >>>> But even if the probability is high that one or more segments is lost, >>>> the timeout for ARQ included in the source makes things simple, and the >>>> ARQ itself keeps things from being too inefficient - you don't throw >>>> >>>> >>> out >>> >>> >>>> 95% of a chunk, you just ask for the last 5% (if that's the way that >>>> >>>> >>> the >>> >>> >>>> sender requested it - some applications may want to explicitly say to >>>> throw them away if they haven't all arrived by a certain time). >>>> Motes can have a default timeout for fragment sets for which they have >>>> not yet received the first fragment. >>>> >>>> I'm guessing that these ideas are not new, and that if I knew the IETF >>>> literature better I'd be able to point to an RFC that describes >>>> something like this. >>>> >>>> ksjp >>>> >>>> Pascal Thubert (pthubert) wrote: >>>> >>>> >>>>> [...] >>>>> [Pascal] That was the beginning of this thread. A major drawback of >>>>> fragmentation is that if most frags for a packet make it but not all >>>>> >>>>> >>> of >>> >>> >>>>> them, the whole effort is wasted because the packet can not be >>>>> reassembled and it will retried or lost. More than that, resources >>>>> >>>>> >>> are >>> >>> >>>>> locked on the receive side for some time waiting for the frag that >>>>> >>>>> >>> will >>> >>> >>>>> never come. If fragments are not in order, the situation is very hard >>>>> >>>>> >>> to >>> >>> >>>>> even detect. So it is generally better to send a flow on a same path >>>>> >>>>> >>> so >>> >>> >>>>> that if something goes wrong a given flow is fully impacted or not >>>>> impacted at all. >>>>> >>>>> Say we do a file transfer for software image to a mote. TFTP will >>>>> >>>>> >>> chunk >>> >>> >>>>> it into 512 bytes TPDUs. Those will make around 8 or 9 6LoWPAN >>>>> >>>>> >>> fragments >>> >>> >>>>> if security is high. If the fragments are disseminated on many >>>>> >>>>> >>> different >>> >>> >>>>> path and one fragments gets lost because one path is faulty, the >>>>> >>>>> >>> effort >>> >>> >>>>> for carrying all the other fragments is more than a waste. It >>>>> >>>>> >>> actually >>> >>> >>>>> locks resources in the receiving mote for a long time. If we have >>>>> >>>>> >>> less >>> >>> >>>>> that 90% reliability, that means that most packets will never make it >>>>> through integrally. If we have a number of transfers going on, it >>>>> >>>>> >>> might >>> >>> >>>>> happen that the full bandwidth of the network is used, and nothing is >>>>> actually received at transport layer, and all the available memory is >>>>> locked in the motes. >>>>> >>>>> Obviously, if 99.999% packets make it through thanks to path >>>>> >>>>> >>> redundancy >>> >>> >>>>> and retries, then the problem is much less visible and the benefits >>>>> >>>>> >>> of >>> >>> >>>>> the simple mechanism that Rick detailed prevail. I'm just unsure >>>>> >>>>> >>> where >>> >>> >>>>> the limit is, so I'm pointing out the potential threat and proposing >>>>> classical techniques in place for that containing that risk. Maybe we >>>>> can prove it's not needed and I'm sorry for wasting your time but at >>>>> least we can document the case; or maybe it might happen to be needed >>>>> and I proposed a simple hash to mitigate the risk. There are also >>>>> >>>>> >>> more >>> >>> >>>>> complex solutions in the art of mesh that use Forward Error >>>>> >>>>> >>> Correction, >>> >>> >>>>> network coding, or even an LLC with Error Recovery Procedure (like >>>>> 802.2) to alleviate that risk... >>>>> >>>>> >>>>> Pascal >>>>> >>>>> >>>>> >> --- You are currently subscribed to sp100.11a-pdnt as: >> geoff-sp100@mulligan.org To unsubscribe send a blank email to >> leave-sp100.11a-pdnt-127034X@isa-online.org >> > > --------------090001040506080205010106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit yes, that much is clear. 
But why number 8 byte chunks instead of 15.4 payloads?
When the originator fragments the packet, it's going to break it up into a small number of fragments that fit into mesh/mac/phy payloads, not a byte stream with unknown (and shifting?!? "fragment overlap"?!?) boundaries.
I don't get the 16 bit datagram tag either.  That implies that we might be sending thousands of separately fragmented datagrams during the timeout+transit period for a single one?  The radio can't even do that at 100% duty cycle.
It seems like even with the 5 bits for the frag-type, this could all have fit into 2 bytes, not 5.

So with the 1280 requirement, and use cases that I understand, I get 2 bytes.  Are there other things that I'm missing that lead to 4 and 5 bytes for first and subsequent?

ksjp

Geoff Mulligan wrote: 
The design was based on the requirement to support 1280byte MTU to IP.

	geoff

On Mon, 2007-10-29 at 10:43 -0700, Kris Pister wrote:
  
Discussing simple ERP seems like a worthy sp100 topic, but it probably
doesn't matter that much if you believe my claim that even 1280 byte
datagrams will arrive with all fragments intact >99% of the time.

Can anyone explain why 6LoWPAN chose such a funky fragment header?
They must have been trying to address something important to spend so
many bytes on it.

ksjp

Pascal Thubert (pthubert) wrote: 
    
Hi Kris:

Resending one lost fragment under the fragmentation sub-layer would be
neat indeed.

IBM's SNA employed error recovery procedures (ERP) at layer 2, in
particular SDLC, LAPB and 802.2. Note that none of these can actually
resend a specific piece and all require orderly delivery. HPR's RTP
could do it but was very confidential, mostly used with IBM's parallel
Sysplex.

TCP supports but does not like out of order. Fast recovery is quickly
triggered.

I'd be interested in discussing the requirements for an ERP at DLL. I'm
not sure that it is in scope for ISA100.11a right now, is it? I do not
mean it's wrong, just that we are considering real issues, and real
solutions.

Pascal

  
      
-----Original Message-----
From: Kris Pister [mailto:pister@eecs.berkeley.edu]
Sent: Sunday, October 28, 2007 10:30 PM
To: Pascal Thubert (pthubert)
Cc: Phy/DLL/Network/Transport group
Subject: Re: [sp100.11a-pdnt] Re: Transport layer requirements; first
    
        
cut
  
      
* fragmentation
Here's the way that I see fragmentation:
Mote A fragments the packet.  The first fragment contains the
fragmentation info and a delete/ARQ mode bit and time limit: "if you
haven't seen all 9 segments in 30 seconds, either {delete what you
    
        
have}
  
      
or {send me a message saying which ones you're missing}".
These packets work their way through the network, potentially over many
paths, each arriving at its destination potentially out of order but
with over 99.9% probability.  The receiving mote reassembles the lot,
and checks the transport MIC on the entire thing (no transport MIC per
segment, just DLL MIC).
If we can't hit 100B of transport payload per packet, we need to go
    
        
back
  
      
and fix 6LoWPAN (well, actually I already know that we have to fix
6LoWPAN), so your TFTP chunk will take no more than 6 fragments no
matter what the security level is.  So the probability of losing one or
more segments is less than 1%.  Even a 1280B chunk should have less
    
        
than
  
      
1% probability of a missing segment.  I can't *prove* that, but I have
    
        
a
  
      
LOT of data from real deployments to support the assertion.
But even if the probability is high that one or more segments is lost,
the timeout for ARQ included in the source makes things simple, and the
ARQ itself keeps things from being too inefficient - you don't throw
    
        
out
  
      
95% of a chunk, you just ask for the last 5% (if that's the way that
    
        
the
  
      
sender requested it - some applications may want to explicitly say to
throw them away if they haven't all arrived by a certain time).
Motes can have a default timeout for fragment sets for which they have
not yet received the first fragment.

I'm guessing that these ideas are not new, and that if I knew the IETF
literature better I'd be able to point to an RFC that describes
something like this.

ksjp

Pascal Thubert (pthubert) wrote:
    
        
[...]
[Pascal] That was the beginning of this thread. A major drawback of
fragmentation is that if most frags for a packet make it but not all
      
          
of
  
      
them, the whole effort is wasted because the packet can not be
reassembled and it will retried or lost. More than that, resources
      
          
are
  
      
locked on the receive side for some time waiting for the frag that
      
          
will
  
      
never come. If fragments are not in order, the situation is very hard
      
          
to
  
      
even detect. So it is generally better to send a flow on a same path
      
          
so
  
      
that if something goes wrong a given flow is fully impacted or not
impacted at all.

Say we do a file transfer for software image to a mote. TFTP will
      
          
chunk
  
      
it into 512 bytes TPDUs. Those will make around 8 or 9 6LoWPAN
      
          
fragments
  
      
if security is high. If the fragments are disseminated on many
      
          
different
  
      
path and one fragments gets lost because one path is faulty, the
      
          
effort
  
      
for carrying all the other fragments is more than a waste. It
      
          
actually
  
      
locks resources in the receiving mote for a long time. If we have
      
          
less
  
      
that 90% reliability, that means that most packets will never make it
through integrally. If we have a number of transfers going on, it
      
          
might
  
      
happen that the full bandwidth of the network is used, and nothing is
actually received at transport layer, and all the available memory is
locked in the motes.

Obviously, if 99.999% packets make it through thanks to path
      
          
redundancy
  
      
and retries, then the problem is much less visible and the benefits
      
          
of
  
      
the simple mechanism that Rick detailed prevail. I'm just unsure
      
          
where
  
      
the limit is, so I'm pointing out the potential threat and proposing
classical techniques in place for that containing that risk. Maybe we
can prove it's not needed and I'm sorry for wasting your time but at
least we can document the case; or maybe it might happen to be needed
and I proposed a simple hash to mitigate the risk. There are also
      
          
more
  
      
complex solutions in the art of mesh that use Forward Error
      
          
Correction,
  
      
network coding, or even an LLC with Error Recovery Procedure (like
802.2) to alleviate that risk...


Pascal

      
          
--- You are currently subscribed to sp100.11a-pdnt as:
geoff-sp100@mulligan.org To unsubscribe send a blank email to
leave-sp100.11a-pdnt-127034X@isa-online.org
--------------090001040506080205010106-- --===============0018212833== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0018212833==-- From 6lowpan-bounces@ietf.org Mon Oct 29 15:08:34 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZyL-0001h2-Pw; Mon, 29 Oct 2007 15:08:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZyK-0001gk-No for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 15:08:24 -0400 Received: from [199.233.92.34] (helo=grab.coslabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImZvX-0000NN-8q for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 15:08:24 -0400 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l9TJ4k47002760; Mon, 29 Oct 2007 13:04:46 -0600 (MDT) From: Geoff Mulligan To: Kris Pister In-Reply-To: References: Content-Type: text/plain Date: Mon, 29 Oct 2007 13:04:51 -0600 Message-Id: <1193684691.8079.33.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: 6lowpan <6lowpan@lists.ietf.org>, Phy/DLL/Network/Transport group Subject: [6lowpan] Re: [sp100.11a-pdnt] Re: Transport layer requirements; first cut X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org yes. quite a bit else that was hashed out on the 6lowpan mailing list during the design of the 6lowpan header formats. geoff On Mon, 2007-10-29 at 12:00 -0700, Kris Pister wrote: > yes, that much is clear. > But why number 8 byte chunks instead of 15.4 payloads? > When the originator fragments the packet, it's going to break it up > into a small number of fragments that fit into mesh/mac/phy payloads, > not a byte stream with unknown (and shifting?!? "fragment overlap"?!?) > boundaries. > I don't get the 16 bit datagram tag either. That implies that we > might be sending thousands of separately fragmented datagrams during > the timeout+transit period for a single one? The radio can't even do > that at 100% duty cycle. > It seems like even with the 5 bits for the frag-type, this could all > have fit into 2 bytes, not 5. > > So with the 1280 requirement, and use cases that I understand, I get 2 > bytes. Are there other things that I'm missing that lead to 4 and 5 > bytes for first and subsequent? > > ksjp > > Geoff Mulligan wrote: > > The design was based on the requirement to support 1280byte MTU to IP. > > > > geoff > > > > On Mon, 2007-10-29 at 10:43 -0700, Kris Pister wrote: > > > > > Discussing simple ERP seems like a worthy sp100 topic, but it probably > > > doesn't matter that much if you believe my claim that even 1280 byte > > > datagrams will arrive with all fragments intact >99% of the time. > > > > > > Can anyone explain why 6LoWPAN chose such a funky fragment header? > > > They must have been trying to address something important to spend so > > > many bytes on it. > > > > > > ksjp > > > > > > Pascal Thubert (pthubert) wrote: > > > > > > > Hi Kris: > > > > > > > > Resending one lost fragment under the fragmentation sub-layer would be > > > > neat indeed. > > > > > > > > IBM's SNA employed error recovery procedures (ERP) at layer 2, in > > > > particular SDLC, LAPB and 802.2. Note that none of these can actually > > > > resend a specific piece and all require orderly delivery. HPR's RTP > > > > could do it but was very confidential, mostly used with IBM's parallel > > > > Sysplex. > > > > > > > > TCP supports but does not like out of order. Fast recovery is quickly > > > > triggered. > > > > > > > > I'd be interested in discussing the requirements for an ERP at DLL. I'm > > > > not sure that it is in scope for ISA100.11a right now, is it? I do not > > > > mean it's wrong, just that we are considering real issues, and real > > > > solutions. > > > > > > > > Pascal > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Kris Pister [mailto:pister@eecs.berkeley.edu] > > > > > Sent: Sunday, October 28, 2007 10:30 PM > > > > > To: Pascal Thubert (pthubert) > > > > > Cc: Phy/DLL/Network/Transport group > > > > > Subject: Re: [sp100.11a-pdnt] Re: Transport layer requirements; first > > > > > > > > > > > > > > cut > > > > > > > > > > > > > * fragmentation > > > > > Here's the way that I see fragmentation: > > > > > Mote A fragments the packet. The first fragment contains the > > > > > fragmentation info and a delete/ARQ mode bit and time limit: "if you > > > > > haven't seen all 9 segments in 30 seconds, either {delete what you > > > > > > > > > > > > > > have} > > > > > > > > > > > > > or {send me a message saying which ones you're missing}". > > > > > These packets work their way through the network, potentially over many > > > > > paths, each arriving at its destination potentially out of order but > > > > > with over 99.9% probability. The receiving mote reassembles the lot, > > > > > and checks the transport MIC on the entire thing (no transport MIC per > > > > > segment, just DLL MIC). > > > > > If we can't hit 100B of transport payload per packet, we need to go > > > > > > > > > > > > > > back > > > > > > > > > > > > > and fix 6LoWPAN (well, actually I already know that we have to fix > > > > > 6LoWPAN), so your TFTP chunk will take no more than 6 fragments no > > > > > matter what the security level is. So the probability of losing one or > > > > > more segments is less than 1%. Even a 1280B chunk should have less > > > > > > > > > > > > > > than > > > > > > > > > > > > > 1% probability of a missing segment. I can't *prove* that, but I have > > > > > > > > > > > > > > a > > > > > > > > > > > > > LOT of data from real deployments to support the assertion. > > > > > But even if the probability is high that one or more segments is lost, > > > > > the timeout for ARQ included in the source makes things simple, and the > > > > > ARQ itself keeps things from being too inefficient - you don't throw > > > > > > > > > > > > > > out > > > > > > > > > > > > > 95% of a chunk, you just ask for the last 5% (if that's the way that > > > > > > > > > > > > > > the > > > > > > > > > > > > > sender requested it - some applications may want to explicitly say to > > > > > throw them away if they haven't all arrived by a certain time). > > > > > Motes can have a default timeout for fragment sets for which they have > > > > > not yet received the first fragment. > > > > > > > > > > I'm guessing that these ideas are not new, and that if I knew the IETF > > > > > literature better I'd be able to point to an RFC that describes > > > > > something like this. > > > > > > > > > > ksjp > > > > > > > > > > Pascal Thubert (pthubert) wrote: > > > > > > > > > > > > > > > > [...] > > > > > > [Pascal] That was the beginning of this thread. A major drawback of > > > > > > fragmentation is that if most frags for a packet make it but not all > > > > > > > > > > > > > > > > of > > > > > > > > > > > > > > them, the whole effort is wasted because the packet can not be > > > > > > reassembled and it will retried or lost. More than that, resources > > > > > > > > > > > > > > > > are > > > > > > > > > > > > > > locked on the receive side for some time waiting for the frag that > > > > > > > > > > > > > > > > will > > > > > > > > > > > > > > never come. If fragments are not in order, the situation is very hard > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > even detect. So it is generally better to send a flow on a same path > > > > > > > > > > > > > > > > so > > > > > > > > > > > > > > that if something goes wrong a given flow is fully impacted or not > > > > > > impacted at all. > > > > > > > > > > > > Say we do a file transfer for software image to a mote. TFTP will > > > > > > > > > > > > > > > > chunk > > > > > > > > > > > > > > it into 512 bytes TPDUs. Those will make around 8 or 9 6LoWPAN > > > > > > > > > > > > > > > > fragments > > > > > > > > > > > > > > if security is high. If the fragments are disseminated on many > > > > > > > > > > > > > > > > different > > > > > > > > > > > > > > path and one fragments gets lost because one path is faulty, the > > > > > > > > > > > > > > > > effort > > > > > > > > > > > > > > for carrying all the other fragments is more than a waste. It > > > > > > > > > > > > > > > > actually > > > > > > > > > > > > > > locks resources in the receiving mote for a long time. If we have > > > > > > > > > > > > > > > > less > > > > > > > > > > > > > > that 90% reliability, that means that most packets will never make it > > > > > > through integrally. If we have a number of transfers going on, it > > > > > > > > > > > > > > > > might > > > > > > > > > > > > > > happen that the full bandwidth of the network is used, and nothing is > > > > > > actually received at transport layer, and all the available memory is > > > > > > locked in the motes. > > > > > > > > > > > > Obviously, if 99.999% packets make it through thanks to path > > > > > > > > > > > > > > > > redundancy > > > > > > > > > > > > > > and retries, then the problem is much less visible and the benefits > > > > > > > > > > > > > > > > of > > > > > > > > > > > > > > the simple mechanism that Rick detailed prevail. I'm just unsure > > > > > > > > > > > > > > > > where > > > > > > > > > > > > > > the limit is, so I'm pointing out the potential threat and proposing > > > > > > classical techniques in place for that containing that risk. Maybe we > > > > > > can prove it's not needed and I'm sorry for wasting your time but at > > > > > > least we can document the case; or maybe it might happen to be needed > > > > > > and I proposed a simple hash to mitigate the risk. There are also > > > > > > > > > > > > > > > > more > > > > > > > > > > > > > > complex solutions in the art of mesh that use Forward Error > > > > > > > > > > > > > > > > Correction, > > > > > > > > > > > > > > network coding, or even an LLC with Error Recovery Procedure (like > > > > > > 802.2) to alleviate that risk... > > > > > > > > > > > > > > > > > > Pascal > > > > > > > > > > > > > > > > > > > > > --- You are currently subscribed to sp100.11a-pdnt as: > > > geoff-sp100@mulligan.org To unsubscribe send a blank email to > > > leave-sp100.11a-pdnt-127034X@isa-online.org > > > > > > > > --- You are currently subscribed to sp100.11a-pdnt as: > geoff-sp100@mulligan.org To unsubscribe send a blank email to > leave-sp100.11a-pdnt-127034X@isa-online.org _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 29 17:36:03 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImcGC-0005IN-QM; Mon, 29 Oct 2007 17:35:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImcGC-0005Bj-Bl for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 17:35:00 -0400 Received: from mail.sf.archrock.com ([64.147.171.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImcG3-0001I5-4E for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 17:34:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 86E3FA9631; Mon, 29 Oct 2007 14:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-10 required=6.6 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDoaRBhEfRdD; Mon, 29 Oct 2007 14:34:46 -0700 (PDT) Received: from [192.168.7.194] (69-12-164-135.sfo.archedrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id A17BFA962E; Mon, 29 Oct 2007 14:34:46 -0700 (PDT) Message-ID: <472651F6.7010307@archrock.com> Date: Mon, 29 Oct 2007 14:34:46 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kris Pister Subject: Re: [6lowpan] Re: [sp100.11a-pdnt] Re: Transport layer requirements; first cut References: <1193681449.8079.16.camel@dellx1> <47262DD4.8040905@eecs.berkeley.edu> In-Reply-To: <47262DD4.8040905@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: 6lowpan <6lowpan@lists.ietf.org>, Phy/DLL/Network/Transport group X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org The frag tag was originally 10-bits, but feedback from IESG review indicated that 10-bits was not enough. Many on this list (including me) thought that 10-bits was more than sufficient for practical use cases. But under what is possible, a node with 100% duty cycle could send enough frames to cycle through 1024 frag tags in 60 seconds. If you do the calculation, you'll find that 15.4 radios can send well more than 2048 frames in 60 seconds. So the decision came down to decreasing the 60s timeout or increasing the number of bits. The WG chose the latter. BTW, the overall frag header in the 10-bit version was 3 octets for first and 4 octets for subsequent. The discussion is archived here: http://www1.ietf.org/mail-archive/web/6lowpan/current/msg00588.html The decision on the use of frag size was before my time, but from what I can tell, the format was originally derived from RFC2734. The offset was reduced to save some bits. This optimization makes less sense with the expansion of the frag tag, but we already very deep in the process. I assume that an explicit offset was chosen because it gives flexibility in having different header lengths between frames. -- Jonathan Hui Kris Pister wrote: > yes, that much is clear. > But why number 8 byte chunks instead of 15.4 payloads? > When the originator fragments the packet, it's going to break it up into > a small number of fragments that fit into mesh/mac/phy payloads, not a > byte stream with unknown (and shifting?!? "fragment overlap"?!?) boundaries. > I don't get the 16 bit datagram tag either. That implies that we might > be sending thousands of separately fragmented datagrams during the > timeout+transit period for a single one? The radio can't even do that > at 100% duty cycle. > It seems like even with the 5 bits for the frag-type, this could all > have fit into 2 bytes, not 5. > > So with the 1280 requirement, and use cases that I understand, I get 2 > bytes. Are there other things that I'm missing that lead to 4 and 5 > bytes for first and subsequent? > > ksjp > > Geoff Mulligan wrote: >> The design was based on the requirement to support 1280byte MTU to IP. >> >> geoff >> >> On Mon, 2007-10-29 at 10:43 -0700, Kris Pister wrote: >> >>> Discussing simple ERP seems like a worthy sp100 topic, but it probably >>> doesn't matter that much if you believe my claim that even 1280 byte >>> datagrams will arrive with all fragments intact >99% of the time. >>> >>> Can anyone explain why 6LoWPAN chose such a funky fragment header? >>> They must have been trying to address something important to spend so >>> many bytes on it. >>> >>> ksjp >>> >>> Pascal Thubert (pthubert) wrote: >>> >>>> Hi Kris: >>>> >>>> Resending one lost fragment under the fragmentation sub-layer would be >>>> neat indeed. >>>> >>>> IBM's SNA employed error recovery procedures (ERP) at layer 2, in >>>> particular SDLC, LAPB and 802.2. Note that none of these can actually >>>> resend a specific piece and all require orderly delivery. HPR's RTP >>>> could do it but was very confidential, mostly used with IBM's parallel >>>> Sysplex. >>>> >>>> TCP supports but does not like out of order. Fast recovery is quickly >>>> triggered. >>>> >>>> I'd be interested in discussing the requirements for an ERP at DLL. I'm >>>> not sure that it is in scope for ISA100.11a right now, is it? I do not >>>> mean it's wrong, just that we are considering real issues, and real >>>> solutions. >>>> >>>> Pascal >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>> Sent: Sunday, October 28, 2007 10:30 PM >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: Phy/DLL/Network/Transport group >>>>> Subject: Re: [sp100.11a-pdnt] Re: Transport layer requirements; first >>>>> >>>>> >>>> cut >>>> >>>> >>>>> * fragmentation >>>>> Here's the way that I see fragmentation: >>>>> Mote A fragments the packet. The first fragment contains the >>>>> fragmentation info and a delete/ARQ mode bit and time limit: "if you >>>>> haven't seen all 9 segments in 30 seconds, either {delete what you >>>>> >>>>> >>>> have} >>>> >>>> >>>>> or {send me a message saying which ones you're missing}". >>>>> These packets work their way through the network, potentially over many >>>>> paths, each arriving at its destination potentially out of order but >>>>> with over 99.9% probability. The receiving mote reassembles the lot, >>>>> and checks the transport MIC on the entire thing (no transport MIC per >>>>> segment, just DLL MIC). >>>>> If we can't hit 100B of transport payload per packet, we need to go >>>>> >>>>> >>>> back >>>> >>>> >>>>> and fix 6LoWPAN (well, actually I already know that we have to fix >>>>> 6LoWPAN), so your TFTP chunk will take no more than 6 fragments no >>>>> matter what the security level is. So the probability of losing one or >>>>> more segments is less than 1%. Even a 1280B chunk should have less >>>>> >>>>> >>>> than >>>> >>>> >>>>> 1% probability of a missing segment. I can't *prove* that, but I have >>>>> >>>>> >>>> a >>>> >>>> >>>>> LOT of data from real deployments to support the assertion. >>>>> But even if the probability is high that one or more segments is lost, >>>>> the timeout for ARQ included in the source makes things simple, and the >>>>> ARQ itself keeps things from being too inefficient - you don't throw >>>>> >>>>> >>>> out >>>> >>>> >>>>> 95% of a chunk, you just ask for the last 5% (if that's the way that >>>>> >>>>> >>>> the >>>> >>>> >>>>> sender requested it - some applications may want to explicitly say to >>>>> throw them away if they haven't all arrived by a certain time). >>>>> Motes can have a default timeout for fragment sets for which they have >>>>> not yet received the first fragment. >>>>> >>>>> I'm guessing that these ideas are not new, and that if I knew the IETF >>>>> literature better I'd be able to point to an RFC that describes >>>>> something like this. >>>>> >>>>> ksjp >>>>> >>>>> Pascal Thubert (pthubert) wrote: >>>>> >>>>> >>>>>> [...] >>>>>> [Pascal] That was the beginning of this thread. A major drawback of >>>>>> fragmentation is that if most frags for a packet make it but not all >>>>>> >>>>>> >>>> of >>>> >>>> >>>>>> them, the whole effort is wasted because the packet can not be >>>>>> reassembled and it will retried or lost. More than that, resources >>>>>> >>>>>> >>>> are >>>> >>>> >>>>>> locked on the receive side for some time waiting for the frag that >>>>>> >>>>>> >>>> will >>>> >>>> >>>>>> never come. If fragments are not in order, the situation is very hard >>>>>> >>>>>> >>>> to >>>> >>>> >>>>>> even detect. So it is generally better to send a flow on a same path >>>>>> >>>>>> >>>> so >>>> >>>> >>>>>> that if something goes wrong a given flow is fully impacted or not >>>>>> impacted at all. >>>>>> >>>>>> Say we do a file transfer for software image to a mote. TFTP will >>>>>> >>>>>> >>>> chunk >>>> >>>> >>>>>> it into 512 bytes TPDUs. Those will make around 8 or 9 6LoWPAN >>>>>> >>>>>> >>>> fragments >>>> >>>> >>>>>> if security is high. If the fragments are disseminated on many >>>>>> >>>>>> >>>> different >>>> >>>> >>>>>> path and one fragments gets lost because one path is faulty, the >>>>>> >>>>>> >>>> effort >>>> >>>> >>>>>> for carrying all the other fragments is more than a waste. It >>>>>> >>>>>> >>>> actually >>>> >>>> >>>>>> locks resources in the receiving mote for a long time. If we have >>>>>> >>>>>> >>>> less >>>> >>>> >>>>>> that 90% reliability, that means that most packets will never make it >>>>>> through integrally. If we have a number of transfers going on, it >>>>>> >>>>>> >>>> might >>>> >>>> >>>>>> happen that the full bandwidth of the network is used, and nothing is >>>>>> actually received at transport layer, and all the available memory is >>>>>> locked in the motes. >>>>>> >>>>>> Obviously, if 99.999% packets make it through thanks to path >>>>>> >>>>>> >>>> redundancy >>>> >>>> >>>>>> and retries, then the problem is much less visible and the benefits >>>>>> >>>>>> >>>> of >>>> >>>> >>>>>> the simple mechanism that Rick detailed prevail. I'm just unsure >>>>>> >>>>>> >>>> where >>>> >>>> >>>>>> the limit is, so I'm pointing out the potential threat and proposing >>>>>> classical techniques in place for that containing that risk. Maybe we >>>>>> can prove it's not needed and I'm sorry for wasting your time but at >>>>>> least we can document the case; or maybe it might happen to be needed >>>>>> and I proposed a simple hash to mitigate the risk. There are also >>>>>> >>>>>> >>>> more >>>> >>>> >>>>>> complex solutions in the art of mesh that use Forward Error >>>>>> >>>>>> >>>> Correction, >>>> >>>> >>>>>> network coding, or even an LLC with Error Recovery Procedure (like >>>>>> 802.2) to alleviate that risk... >>>>>> >>>>>> >>>>>> Pascal >>>>>> >>>>>> >>>>>> >>> --- You are currently subscribed to sp100.11a-pdnt as: >>> geoff-sp100@mulligan.org To unsubscribe send a blank email to >>> leave-sp100.11a-pdnt-127034X@isa-online.org >>> >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 29 21:04:01 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImfVR-0003yt-NB; Mon, 29 Oct 2007 21:02:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImfVO-0003xw-Gh for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 21:02:54 -0400 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImfVN-0004Vj-EM for 6lowpan@lists.ietf.org; Mon, 29 Oct 2007 21:02:54 -0400 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1ImfUs-0000JB-2h; Mon, 29 Oct 2007 18:02:22 -0700 In-Reply-To: <472626CD.7050104@eecs.berkeley.edu> References: <04F7625E-0178-43CC-9EFB-35BE632DEC1B@cisco.com> <47261A9A.3030906@eecs.berkeley.edu> <0C86FC94-3256-4C61-AB6A-0F187ECED326@cs.stanford.edu> <472626CD.7050104@eecs.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04D3BF68-2464-4BE9-BFF9-479A662D7313@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Mon, 29 Oct 2007 17:14:00 -0700 To: Kris Pister X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -2.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 3acef658708772c1d00935e7d4d752c5 X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [6lowpan] Re: [RSN] RL2N BOF in Vancouver X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Oct 29, 2007, at 11:30 AM, Kris Pister wrote: > Hmm. You could probably make the claim that there aren't any wired > link layers that don't have losses, too. I guess that it's all > relative. What are the loss rates in wired systems? The point is relative; losses of course exist in wired systems. A lot of it boils down to assumptions; if line loss rates are such that most losses are due to congestion, you want different rate control than if they are link losses. The many efforts to get TCP working on wireless, as well as high-speed TCP and fast TCP are some of the major examples. > Certainly it is possible to find path/channel combinations in > 802.15.4 networks that have zero loss at the link layer over > periods of many weeks and millions of packets, which I think gets > called "carrier class" reliability. It's important to note that this only applies for particular topologies and environments. Zero loss at the link layer over periods of weeks is unlikely if you're next to a microwave. It's the edge cases that always get you. > If we're smart, we'll be able to build networks that use such path/ > channel combos almost exclusively. I think I might word it slightly differently: if we're smart, we'll be able to build networks that detect such path/channel combinations when they exist. Assuming they always exist seems dangerous to me. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 30 11:50:41 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtM0-0005IG-BA; Tue, 30 Oct 2007 11:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtLz-0005Fw-8z for 6lowpan@lists.ietf.org; Tue, 30 Oct 2007 11:50:07 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImtLy-0000pn-2P for 6lowpan@lists.ietf.org; Tue, 30 Oct 2007 11:50:07 -0400 X-IronPort-AV: E=Sophos;i="4.21,347,1188802800"; d="scan'208";a="411692605" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 30 Oct 2007 08:50:06 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9UFo57j018758; Tue, 30 Oct 2007 08:50:05 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9UFnlTm017400; Tue, 30 Oct 2007 15:50:05 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 08:49:58 -0700 Received: from [135.16.16.76] ([10.21.69.89]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 08:49:57 -0700 In-Reply-To: <04D3BF68-2464-4BE9-BFF9-479A662D7313@cs.stanford.edu> References: <04F7625E-0178-43CC-9EFB-35BE632DEC1B@cisco.com> <47261A9A.3030906@eecs.berkeley.edu> <0C86FC94-3256-4C61-AB6A-0F187ECED326@cs.stanford.edu> <472626CD.7050104@eecs.berkeley.edu> <04D3BF68-2464-4BE9-BFF9-479A662D7313@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D1B1EE9-AEB5-439F-8BC9-52F501ACFEE4@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Tue, 30 Oct 2007 11:48:50 -0400 To: Philip Levis X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 30 Oct 2007 15:49:57.0804 (UTC) FILETIME=[85C72EC0:01C81B0C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1810; t=1193759405; x=1194623405; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20RL2N=20BOF=20in=20Vancouver |Sender:=20; bh=pBgjR0/3Vsq6ZcDCkw0coIwmJiba6s/Im5U1Mm9xwq0=; b=dbmy8/1qt/nEod3EMCRGxriAHoQjkkbp5pdFeVJebZeb5hEcajkXjwljp2IfeoGlf9eDP7Fg p4i2Jiux1Vmh2MBqrQv2XW7s8EyDvKFEWaUFBLfdI+mRyvjjls5+SOff; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -3.7 (---) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [6lowpan] Re: [RSN] RL2N BOF in Vancouver X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org The point is indeed to specify routing protocol for networks comprising constrained devices ( e.g. low power) interconnected via lossy links/nodes since indeed the node failure rate is likely to be higher than in typical IP networks. Cheers. JP. On Oct 29, 2007, at 8:14 PM, Philip Levis wrote: > On Oct 29, 2007, at 11:30 AM, Kris Pister wrote: > >> Hmm. You could probably make the claim that there aren't any >> wired link layers that don't have losses, too. I guess that it's >> all relative. What are the loss rates in wired systems? > > The point is relative; losses of course exist in wired systems. A > lot of it boils down to assumptions; if line loss rates are such > that most losses are due to congestion, you want different rate > control than if they are link losses. The many efforts to get TCP > working on wireless, as well as high-speed TCP and fast TCP are > some of the major examples. > > >> Certainly it is possible to find path/channel combinations in >> 802.15.4 networks that have zero loss at the link layer over >> periods of many weeks and millions of packets, which I think gets >> called "carrier class" reliability. > > It's important to note that this only applies for particular > topologies and environments. Zero loss at the link layer over > periods of weeks is unlikely if you're next to a microwave. It's > the edge cases that always get you. > >> If we're smart, we'll be able to build networks that use such path/ >> channel combos almost exclusively. > > I think I might word it slightly differently: if we're smart, we'll > be able to build networks that detect such path/channel > combinations when they exist. Assuming they always exist seems > dangerous to me. > > Phil > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 30 12:19:32 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imto8-0008C8-S3; Tue, 30 Oct 2007 12:19:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imto7-00087i-Si for 6lowpan@lists.ietf.org; Tue, 30 Oct 2007 12:19:11 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imto3-0001u8-JG for 6lowpan@lists.ietf.org; Tue, 30 Oct 2007 12:19:11 -0400 Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.1/8.13.5) with ESMTP id l9UGImEf001448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Oct 2007 09:18:49 -0700 (PDT) Message-ID: <47275963.2050001@eecs.berkeley.edu> Date: Tue, 30 Oct 2007 09:18:43 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> In-Reply-To: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: Subject: [6lowpan] Re: [sp100] interoperability problems at ISA Houston X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Here's a thread from ISA that may be of interest. 6lowpan had some=20 email a few months ago on the topic of coexistence, and the level of=20 safety afforded by the dispatch byte. If you read Gerry's email below,=20 you'll see that once again this approach has proven hazardous in a=20 public forum. I'd say at least half of the WSN companies that I've=20 talked to have fallen victim to this (Dust included - back in 2003!). ksjp Kris Pister wrote: > This is an example of a very common problem seen in the early stages of= software development in sensor networks. Wireless HART does not, and SP= 100.11a should not, suffer from it. > The general problem is that those unfamiliar with working in a regulate= d but unlicensed band are not used to the idea that there is a lot of tra= ffic flying around at 2.4GHz, employing a wide range of MAC protocols. M= ore subtly, even well-formed packets in your own network can be corrupted= in flight in such a way that the frame check sequence (FCS) does not cat= ch the errors. In both cases, the naive system will try to execute the i= nstructions in a packet that is essentially random, with disastrous resul= ts. > In TSMP (the basis of Wireless HART and SP100.11a data link layers), th= e solution to this problem is to use a message integrity code (MIC) on ev= ery packet. This 32 bit number is a cryptographic hash of the entire pac= ket, and prevents corrupted or foreign packets from being accepted at the= lowest layer of the communication stack, with a probability of 99.999999= 98% (fewer than one in 4 billion get through on average). For a reliable = network, even this is not enough, since undetected errors might occur on = the order of once per year per network. > Another 32 bit MIC is used at the application layer to verify the authe= nticity of the sender of the message. Combined with the DLL MIC, this re= duces the probability of executing random packets to something like once = per age-of-the-universe per network. Even with energy scavenging, that's= a long time! :) > =20 > The lesson here is simple: never *ever* turn off crypto in your network= s. Use well-known published keys if you want to, but keep the integrity = codes in place. > =20 > ksjp > -- > Prof. EECS, UC Berkeley > Founder & CTO, Dust Networks > =20 > > ________________________________ > > From: Gerry Nadler [mailto:gnadler@machinetalker.com] > Sent: Mon 10/29/2007 10:31 AM > To: ISA100 > Subject: [sp100] interoperability problems at ISA Houston > > > Everyone: > > =20 > > On the evening before the ISA exhibition (Monday night) I visited the s= how floor to see the ISA-100 booth. Most all the booths were unmanned a= nd all was quiet except for a small group in one booth that was having pr= oblems. They were using Zigbee. Their Zigbee system was not functionin= g due to some type of interference. (The name of the company is not ment= ioned here because for the purpose of this note it is not necessary). I = walked by the booth and the people were very frustrated as to the cause o= f their problem. I tried to help. We set up a 15.4 packet sniffer to l= ook at the packets to see what was the cause of the problem. The vendor = was using Ember chips and software stack. We got the sniffer running and= looked at the packets and we saw the problem. There was nothing we coul= d do because the 15.4 stack was being corrupted by an illegal packet(or s= o I thought at the time). The packets were sent to the Ember software te= am for analysis and they made modification to their stack and the vendor = was up and running by the time the show opened on Tuesday. > > =20 > > I walked around the show floor at about 11 PM at night and looked to se= e who might be transmitting 15.4 packets. I checked the ISA-100 booth an= d the surrounding area and everything seemed to be shut down. I walked u= p and down every aisle looking for a possible transmission site. I didn= 't see anything except for the wireless HART booth where there was "flash= ing LEDs", a possible sign of RF transmissions. It could have been anoth= er Zigbee/SP-100 transmission site as well. > > =20 > > On Tuesday I stopped by the booth and Bob LeFort the president of Ember= was at the booth. We had a nice chat and when I got back home I asked h= im if he could have his software people write up what they found. Below = is a short analysis of the problem written by the VP of engineering at Em= ber. They did a great job and had the problem diagnosed and fixed before= Houston show opened the next day. > > =20 > > I have included this because depending on your point of view this may b= e harbinger of things to come or it can be dismissed.. I thought the gr= oup should know what we may or may not expect in the future. > > =20 > > Gerry > > =20 > > Ember report by Skip Ashton, Ember VP Engineering.=20 > > =20 > > The cause of the problem was an Ember device receiving a coordinator re= alignment packet. Under the 15.4 specification, this packet is intended = to be unicast to an orphan device, or broadcast to a network that is chan= ging its parameters. Receipt of this packet was causing the Ember device= to change channels and PAN ID. The 15.4 specification requires this pac= ket be sent with a 64 bit extended address for the source. However, in t= his case the 16 bit coordinator address for the source was being used mak= ing this an illegal packet. This illegal packet to change PAN ID was bei= ng generated by another network device at a regular interval. > > =20 > > Reception and processing of the coordinator realignment command is mand= atory within 802.15.4. However, it should be ignored by devices that are= using higher levels of control over items such as channel change. A Zig= Bee network device is not expecting a coordinator realignment. This comm= and is not used to change channels within ZigBee, because a higher layer = network command is used instead. As such, these type of MAC commands sho= uld be ignored. > > =20 > > A change was made to our stack to ignore such MAC command frames once t= he ZigBee stack is operational. =20 > > =20 > > --- You are currently subscribed to sp100 as: kpister@dustnetworks.com = To unsubscribe send a blank email to leave-sp100-100144H@isa-online.org=20 > =20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 30 13:02:27 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImuTd-0002kL-Hj; Tue, 30 Oct 2007 13:02:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImuTc-0002k8-9b for 6lowpan@lists.ietf.org; Tue, 30 Oct 2007 13:02:04 -0400 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImuTT-0003Te-Qj for 6lowpan@lists.ietf.org; Tue, 30 Oct 2007 13:02:04 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id E9BD6A9647; Tue, 30 Oct 2007 10:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-10 required=6.6 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSikGzhkgIgI; Tue, 30 Oct 2007 10:01:32 -0700 (PDT) Received: from [192.168.7.194] (69-12-164-135.sfo.archedrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 13661A9644; Tue, 30 Oct 2007 10:01:32 -0700 (PDT) Message-ID: <47276369.8020603@archrock.com> Date: Tue, 30 Oct 2007 10:01:29 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kris Pister Subject: Re: [6lowpan] Re: [sp100] interoperability problems at ISA Houston References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> <47275963.2050001@eecs.berkeley.edu> In-Reply-To: <47275963.2050001@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Kris, I think you're a bit confused on the purpose of the 6lowpan header type. The header type is completely orthogonal to whether people choose to utilize strong integrity checks. The dispatch type is analogous to the Next Header field in IP packets. It gives flexibility in constructing different header stacks, yet is easy to parse. Its what enables IPv6 to support extension headers. Robust networks always need strong integrity checks, but integrity checks don't replace dispatch types. -- Jonathan Hui Kris Pister wrote: > Here's a thread from ISA that may be of interest. 6lowpan had some > email a few months ago on the topic of coexistence, and the level of > safety afforded by the dispatch byte. If you read Gerry's email below, > you'll see that once again this approach has proven hazardous in a > public forum. I'd say at least half of the WSN companies that I've > talked to have fallen victim to this (Dust included - back in 2003!). > > ksjp > > Kris Pister wrote: >> This is an example of a very common problem seen in the early stages >> of software development in sensor networks. Wireless HART does not, >> and SP100.11a should not, suffer from it. >> The general problem is that those unfamiliar with working in a >> regulated but unlicensed band are not used to the idea that there is a >> lot of traffic flying around at 2.4GHz, employing a wide range of MAC >> protocols. More subtly, even well-formed packets in your own network >> can be corrupted in flight in such a way that the frame check sequence >> (FCS) does not catch the errors. In both cases, the naive system will >> try to execute the instructions in a packet that is essentially >> random, with disastrous results. >> In TSMP (the basis of Wireless HART and SP100.11a data link layers), >> the solution to this problem is to use a message integrity code (MIC) >> on every packet. This 32 bit number is a cryptographic hash of the >> entire packet, and prevents corrupted or foreign packets from being >> accepted at the lowest layer of the communication stack, with a >> probability of 99.99999998% (fewer than one in 4 billion get through >> on average). For a reliable network, even this is not enough, since >> undetected errors might occur on the order of once per year per network. >> Another 32 bit MIC is used at the application layer to verify the >> authenticity of the sender of the message. Combined with the DLL MIC, >> this reduces the probability of executing random packets to something >> like once per age-of-the-universe per network. Even with energy >> scavenging, that's a long time! :) >> >> The lesson here is simple: never *ever* turn off crypto in your >> networks. Use well-known published keys if you want to, but keep the >> integrity codes in place. >> >> ksjp >> -- >> Prof. EECS, UC Berkeley >> Founder & CTO, Dust Networks >> >> >> ________________________________ >> >> From: Gerry Nadler [mailto:gnadler@machinetalker.com] >> Sent: Mon 10/29/2007 10:31 AM >> To: ISA100 >> Subject: [sp100] interoperability problems at ISA Houston >> >> >> Everyone: >> >> >> >> On the evening before the ISA exhibition (Monday night) I visited the >> show floor to see the ISA-100 booth. Most all the booths were >> unmanned and all was quiet except for a small group in one booth that >> was having problems. They were using Zigbee. Their Zigbee system >> was not functioning due to some type of interference. (The name of >> the company is not mentioned here because for the purpose of this note >> it is not necessary). I walked by the booth and the people were very >> frustrated as to the cause of their problem. I tried to help. We >> set up a 15.4 packet sniffer to look at the packets to see what was >> the cause of the problem. The vendor was using Ember chips and >> software stack. We got the sniffer running and looked at the packets >> and we saw the problem. There was nothing we could do because the >> 15.4 stack was being corrupted by an illegal packet(or so I thought at >> the time). The packets were sent to the Ember software team for >> analysis and they made modification to their stack and the vendor was >> up and running by the time the show opened on Tuesday. >> >> >> >> I walked around the show floor at about 11 PM at night and looked to >> see who might be transmitting 15.4 packets. I checked the ISA-100 >> booth and the surrounding area and everything seemed to be shut down. >> I walked up and down every aisle looking for a possible transmission >> site. I didn't see anything except for the wireless HART booth where >> there was "flashing LEDs", a possible sign of RF transmissions. It >> could have been another Zigbee/SP-100 transmission site as well. >> >> >> >> On Tuesday I stopped by the booth and Bob LeFort the president of >> Ember was at the booth. We had a nice chat and when I got back home I >> asked him if he could have his software people write up what they >> found. Below is a short analysis of the problem written by the VP of >> engineering at Ember. They did a great job and had the problem >> diagnosed and fixed before Houston show opened the next day. >> >> >> >> I have included this because depending on your point of view this may >> be harbinger of things to come or it can be dismissed.. I thought >> the group should know what we may or may not expect in the future. >> >> >> >> Gerry >> >> >> >> Ember report by Skip Ashton, Ember VP Engineering. >> >> >> The cause of the problem was an Ember device receiving a coordinator >> realignment packet. Under the 15.4 specification, this packet is >> intended to be unicast to an orphan device, or broadcast to a network >> that is changing its parameters. Receipt of this packet was causing >> the Ember device to change channels and PAN ID. The 15.4 >> specification requires this packet be sent with a 64 bit extended >> address for the source. However, in this case the 16 bit coordinator >> address for the source was being used making this an illegal packet. >> This illegal packet to change PAN ID was being generated by another >> network device at a regular interval. >> >> >> >> Reception and processing of the coordinator realignment command is >> mandatory within 802.15.4. However, it should be ignored by devices >> that are using higher levels of control over items such as channel >> change. A ZigBee network device is not expecting a coordinator >> realignment. This command is not used to change channels within >> ZigBee, because a higher layer network command is used instead. As >> such, these type of MAC commands should be ignored. >> >> >> >> A change was made to our stack to ignore such MAC command frames once >> the ZigBee stack is operational. >> >> >> --- You are currently subscribed to sp100 as: kpister@dustnetworks.com >> To unsubscribe send a blank email to leave-sp100-100144H@isa-online.org > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 30 16:09:52 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImxON-00065x-RU; Tue, 30 Oct 2007 16:08:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImxOM-00065Z-Tc for 6lowpan@lists.ietf.org; Tue, 30 Oct 2007 16:08:50 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImxOI-0003aC-7K for 6lowpan@lists.ietf.org; Tue, 30 Oct 2007 16:08:50 -0400 X-IronPort-AV: E=Sophos;i="4.21,348,1188802800"; d="scan'208";a="244613782" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Oct 2007 13:08:45 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9UK8jnM008098; Tue, 30 Oct 2007 13:08:45 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l9UK8Xbd027697; Tue, 30 Oct 2007 20:08:45 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 13:08:43 -0700 Received: from [135.16.16.76] ([10.21.121.158]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 13:08:43 -0700 In-Reply-To: <47261A9A.3030906@eecs.berkeley.edu> References: <04F7625E-0178-43CC-9EFB-35BE632DEC1B@cisco.com> <47261A9A.3030906@eecs.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Tue, 30 Oct 2007 16:06:12 -0400 To: Kris Pister X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 30 Oct 2007 20:08:43.0201 (UTC) FILETIME=[ABA2C310:01C81B30] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1312; t=1193774925; x=1194638925; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20RL2N=20BOF=20in=20Vancouver |Sender:=20; bh=l8AOn42q1aghMlIoYt+6obrYEeDas8Fttzn4MS3HRlY=; b=IR/HeZVX7fEVhzbg2PKOiZyEeDhVSWXK97286jP2zxkVTaYU6a0Kd1oM0ZrODaOZ0rl6NZRV xszhBlyt0k0vBA62XqFLMdpO+JEInZ3zLR9jVQn3+yauBsmli1eVal1s; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [6lowpan] Re: [RSN] RL2N BOF in Vancouver X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Kris, On Oct 29, 2007, at 1:38 PM, Kris Pister wrote: > JP - the RL2N charter looks good. My only concern is over the > second L in L2 - are these networks intrinsically lossy, or is that > just due to the current protocols? > > I'll be at the meeting in Boston. > > Question about Vancouver: I've never been to an IETF meeting > before. Are there any important rules/regs that a newbie should > know before attending? The IEEE has lots... I'll send you some data off-line. > Related question: what day(s)/time(s) should we plan on attending? > This will be known on November 12. I'll send a note to the ML. Cheers. JP. > ksjp > > JP Vasseur wrote: >> Dear list, >> >> The RL2N BOF has been approved for Vancouver. >> >> I've updated www.employees.org/~jvasseur with the related >> information - please provide >> your comments. >> >> We're planning to have a pre-WG meeting in Boston Nov 15 with >> 15-20 people >> who expressed some interest in this work. Let us know if you would >> like to attend. >> Otherwise, we will post the minutes of that meeting on the list. >> >> Thanks. >> >> JP. >> >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 30 17:32:50 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imygw-0005ls-7Y; Tue, 30 Oct 2007 17:32:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imygu-0005kj-0g for 6lowpan@lists.ietf.org; Tue, 30 Oct 2007 17:32:04 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imygs-0007Q4-Mz for 6lowpan@lists.ietf.org; Tue, 30 Oct 2007 17:32:03 -0400 Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.1/8.13.5) with ESMTP id l9ULVii9007778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Oct 2007 14:31:46 -0700 (PDT) Message-ID: <4727A2BC.4060807@eecs.berkeley.edu> Date: Tue, 30 Oct 2007 14:31:40 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jonathan Hui Subject: Re: [6lowpan] Re: [sp100] interoperability problems at ISA Houston References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> <47275963.2050001@eecs.berkeley.edu> <47276369.8020603@archrock.com> In-Reply-To: <47276369.8020603@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Jonathan - funny, that's just what I was saying a few months ago :) As long as everyone agrees with Jonathan, all is well. ksjp Jonathan Hui wrote: > > Kris, I think you're a bit confused on the purpose of the 6lowpan > header type. The header type is completely orthogonal to whether > people choose to utilize strong integrity checks. The dispatch type is > analogous to the Next Header field in IP packets. It gives flexibility > in constructing different header stacks, yet is easy to parse. Its > what enables IPv6 to support extension headers. > > Robust networks always need strong integrity checks, but integrity > checks don't replace dispatch types. > > -- > Jonathan Hui > > > Kris Pister wrote: >> Here's a thread from ISA that may be of interest. 6lowpan had some >> email a few months ago on the topic of coexistence, and the level of >> safety afforded by the dispatch byte. If you read Gerry's email >> below, you'll see that once again this approach has proven hazardous >> in a public forum. I'd say at least half of the WSN companies that >> I've talked to have fallen victim to this (Dust included - back in >> 2003!). >> >> ksjp >> >> Kris Pister wrote: >>> This is an example of a very common problem seen in the early stages >>> of software development in sensor networks. Wireless HART does not, >>> and SP100.11a should not, suffer from it. >>> The general problem is that those unfamiliar with working in a >>> regulated but unlicensed band are not used to the idea that there is >>> a lot of traffic flying around at 2.4GHz, employing a wide range of >>> MAC protocols. More subtly, even well-formed packets in your own >>> network can be corrupted in flight in such a way that the frame >>> check sequence (FCS) does not catch the errors. In both cases, the >>> naive system will try to execute the instructions in a packet that >>> is essentially random, with disastrous results. >>> In TSMP (the basis of Wireless HART and SP100.11a data link layers), >>> the solution to this problem is to use a message integrity code >>> (MIC) on every packet. This 32 bit number is a cryptographic hash >>> of the entire packet, and prevents corrupted or foreign packets from >>> being accepted at the lowest layer of the communication stack, with >>> a probability of 99.99999998% (fewer than one in 4 billion get >>> through on average). For a reliable network, even this is not >>> enough, since undetected errors might occur on the order of once per >>> year per network. >>> Another 32 bit MIC is used at the application layer to verify the >>> authenticity of the sender of the message. Combined with the DLL >>> MIC, this reduces the probability of executing random packets to >>> something like once per age-of-the-universe per network. Even with >>> energy scavenging, that's a long time! :) >>> >>> The lesson here is simple: never *ever* turn off crypto in your >>> networks. Use well-known published keys if you want to, but keep >>> the integrity codes in place. >>> >>> ksjp >>> -- >>> Prof. EECS, UC Berkeley >>> Founder & CTO, Dust Networks >>> >>> >>> ________________________________ >>> >>> From: Gerry Nadler [mailto:gnadler@machinetalker.com] >>> Sent: Mon 10/29/2007 10:31 AM >>> To: ISA100 >>> Subject: [sp100] interoperability problems at ISA Houston >>> >>> >>> Everyone: >>> >>> >>> >>> On the evening before the ISA exhibition (Monday night) I visited >>> the show floor to see the ISA-100 booth. Most all the booths were >>> unmanned and all was quiet except for a small group in one booth >>> that was having problems. They were using Zigbee. Their Zigbee >>> system was not functioning due to some type of interference. (The >>> name of the company is not mentioned here because for the purpose of >>> this note it is not necessary). I walked by the booth and the >>> people were very frustrated as to the cause of their problem. I >>> tried to help. We set up a 15.4 packet sniffer to look at the >>> packets to see what was the cause of the problem. The vendor was >>> using Ember chips and software stack. We got the sniffer running >>> and looked at the packets and we saw the problem. There was nothing >>> we could do because the 15.4 stack was being corrupted by an illegal >>> packet(or so I thought at the time). The packets were sent to the >>> Ember software team for analysis and they made modification to their >>> stack and the vendor was up and running by the time the show opened >>> on Tuesday. >>> >>> >>> >>> I walked around the show floor at about 11 PM at night and looked to >>> see who might be transmitting 15.4 packets. I checked the ISA-100 >>> booth and the surrounding area and everything seemed to be shut >>> down. I walked up and down every aisle looking for a possible >>> transmission site. I didn't see anything except for the wireless >>> HART booth where there was "flashing LEDs", a possible sign of RF >>> transmissions. It could have been another Zigbee/SP-100 >>> transmission site as well. >>> >>> >>> >>> On Tuesday I stopped by the booth and Bob LeFort the president of >>> Ember was at the booth. We had a nice chat and when I got back home >>> I asked him if he could have his software people write up what they >>> found. Below is a short analysis of the problem written by the VP >>> of engineering at Ember. They did a great job and had the problem >>> diagnosed and fixed before Houston show opened the next day. >>> >>> >>> >>> I have included this because depending on your point of view this >>> may be harbinger of things to come or it can be dismissed.. I >>> thought the group should know what we may or may not expect in the >>> future. >>> >>> >>> >>> Gerry >>> >>> >>> >>> Ember report by Skip Ashton, Ember VP Engineering. >>> >>> >>> The cause of the problem was an Ember device receiving a coordinator >>> realignment packet. Under the 15.4 specification, this packet is >>> intended to be unicast to an orphan device, or broadcast to a >>> network that is changing its parameters. Receipt of this packet was >>> causing the Ember device to change channels and PAN ID. The 15.4 >>> specification requires this packet be sent with a 64 bit extended >>> address for the source. However, in this case the 16 bit >>> coordinator address for the source was being used making this an >>> illegal packet. This illegal packet to change PAN ID was being >>> generated by another network device at a regular interval. >>> >>> >>> >>> Reception and processing of the coordinator realignment command is >>> mandatory within 802.15.4. However, it should be ignored by devices >>> that are using higher levels of control over items such as channel >>> change. A ZigBee network device is not expecting a coordinator >>> realignment. This command is not used to change channels within >>> ZigBee, because a higher layer network command is used instead. As >>> such, these type of MAC commands should be ignored. >>> >>> >>> >>> A change was made to our stack to ignore such MAC command frames >>> once the ZigBee stack is operational. >>> >>> --- You are currently subscribed to sp100 as: >>> kpister@dustnetworks.com To unsubscribe send a blank email to >>> leave-sp100-100144H@isa-online.org >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 31 18:07:57 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InLhJ-0003tJ-8K; Wed, 31 Oct 2007 18:06:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InLhG-0003sL-4A for 6lowpan@lists.ietf.org; Wed, 31 Oct 2007 18:05:58 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InLh9-00077I-Qr for 6lowpan@lists.ietf.org; Wed, 31 Oct 2007 18:05:58 -0400 Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.1/8.13.5) with ESMTP id l9VM5QGP023402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Oct 2007 15:05:28 -0700 (PDT) Message-ID: <4728FC22.1030500@eecs.berkeley.edu> Date: Wed, 31 Oct 2007 15:05:22 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jonathan Hui Subject: Re: [6lowpan] Re: [sp100] interoperability problems at ISA Houston References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> <47275963.2050001@eecs.berkeley.edu> <47276369.8020603@archrock.com> In-Reply-To: <47276369.8020603@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hmm. I guess you're right after all - I am confused. I completely agree with your statements below, but then I re-read RFC4944 and it says: "Other non-LoWPAN protocols that wish to coexist with LoWPAN nodes should include a byte matching this pattern immediately following the 802.15.4. header." And I read the Arch Rock 6LoWPAN tutorial (which is really well done, by the way), and it says "dispatch: coexistence with other protocols over the same link". These statements do not appear to be aligned with what you wrote below. As I see it, there are only three options: 1) we assume that MAC-layer MICs are always used for 6LoWPAN, perhaps with a well-known 6LoWPAN key, and then there is never any question about coexistence. If you're parsing the dispatch byte, you already know that this is a 6LoWPAN frame. 2) we assume 1, but plan to share MAC-layer crypto with other non-LoWPAN protocols. This sounds like a bad idea from a crypto standpoint. 3) we believe that non-6LoWPAN frames may get through to the network layer, talk about "coexsistence", and cross our fingers that 15.4 toy designers are all familiar with and abide by the IETF recommendations. Down this path lies mysteriously failed networks, broken deployments, and more of the same semi-functionality that has held WSN commercialization back for the last 5 years. So which is it? My vote is #1. ksjp Jonathan Hui wrote: > > Kris, I think you're a bit confused on the purpose of the 6lowpan > header type. The header type is completely orthogonal to whether > people choose to utilize strong integrity checks. The dispatch type is > analogous to the Next Header field in IP packets. It gives flexibility > in constructing different header stacks, yet is easy to parse. Its > what enables IPv6 to support extension headers. > > Robust networks always need strong integrity checks, but integrity > checks don't replace dispatch types. > > -- > Jonathan Hui > > > Kris Pister wrote: >> Here's a thread from ISA that may be of interest. 6lowpan had some >> email a few months ago on the topic of coexistence, and the level of >> safety afforded by the dispatch byte. If you read Gerry's email >> below, you'll see that once again this approach has proven hazardous >> in a public forum. I'd say at least half of the WSN companies that >> I've talked to have fallen victim to this (Dust included - back in >> 2003!). >> >> ksjp >> >> Kris Pister wrote: >>> This is an example of a very common problem seen in the early stages >>> of software development in sensor networks. Wireless HART does not, >>> and SP100.11a should not, suffer from it. >>> The general problem is that those unfamiliar with working in a >>> regulated but unlicensed band are not used to the idea that there is >>> a lot of traffic flying around at 2.4GHz, employing a wide range of >>> MAC protocols. More subtly, even well-formed packets in your own >>> network can be corrupted in flight in such a way that the frame >>> check sequence (FCS) does not catch the errors. In both cases, the >>> naive system will try to execute the instructions in a packet that >>> is essentially random, with disastrous results. >>> In TSMP (the basis of Wireless HART and SP100.11a data link layers), >>> the solution to this problem is to use a message integrity code >>> (MIC) on every packet. This 32 bit number is a cryptographic hash >>> of the entire packet, and prevents corrupted or foreign packets from >>> being accepted at the lowest layer of the communication stack, with >>> a probability of 99.99999998% (fewer than one in 4 billion get >>> through on average). For a reliable network, even this is not >>> enough, since undetected errors might occur on the order of once per >>> year per network. >>> Another 32 bit MIC is used at the application layer to verify the >>> authenticity of the sender of the message. Combined with the DLL >>> MIC, this reduces the probability of executing random packets to >>> something like once per age-of-the-universe per network. Even with >>> energy scavenging, that's a long time! :) >>> >>> The lesson here is simple: never *ever* turn off crypto in your >>> networks. Use well-known published keys if you want to, but keep >>> the integrity codes in place. >>> >>> ksjp >>> -- >>> Prof. EECS, UC Berkeley >>> Founder & CTO, Dust Networks >>> >>> >>> ________________________________ >>> >>> From: Gerry Nadler [mailto:gnadler@machinetalker.com] >>> Sent: Mon 10/29/2007 10:31 AM >>> To: ISA100 >>> Subject: [sp100] interoperability problems at ISA Houston >>> >>> >>> Everyone: >>> >>> >>> >>> On the evening before the ISA exhibition (Monday night) I visited >>> the show floor to see the ISA-100 booth. Most all the booths were >>> unmanned and all was quiet except for a small group in one booth >>> that was having problems. They were using Zigbee. Their Zigbee >>> system was not functioning due to some type of interference. (The >>> name of the company is not mentioned here because for the purpose of >>> this note it is not necessary). I walked by the booth and the >>> people were very frustrated as to the cause of their problem. I >>> tried to help. We set up a 15.4 packet sniffer to look at the >>> packets to see what was the cause of the problem. The vendor was >>> using Ember chips and software stack. We got the sniffer running >>> and looked at the packets and we saw the problem. There was nothing >>> we could do because the 15.4 stack was being corrupted by an illegal >>> packet(or so I thought at the time). The packets were sent to the >>> Ember software team for analysis and they made modification to their >>> stack and the vendor was up and running by the time the show opened >>> on Tuesday. >>> >>> >>> >>> I walked around the show floor at about 11 PM at night and looked to >>> see who might be transmitting 15.4 packets. I checked the ISA-100 >>> booth and the surrounding area and everything seemed to be shut >>> down. I walked up and down every aisle looking for a possible >>> transmission site. I didn't see anything except for the wireless >>> HART booth where there was "flashing LEDs", a possible sign of RF >>> transmissions. It could have been another Zigbee/SP-100 >>> transmission site as well. >>> >>> >>> >>> On Tuesday I stopped by the booth and Bob LeFort the president of >>> Ember was at the booth. We had a nice chat and when I got back home >>> I asked him if he could have his software people write up what they >>> found. Below is a short analysis of the problem written by the VP >>> of engineering at Ember. They did a great job and had the problem >>> diagnosed and fixed before Houston show opened the next day. >>> >>> >>> >>> I have included this because depending on your point of view this >>> may be harbinger of things to come or it can be dismissed.. I >>> thought the group should know what we may or may not expect in the >>> future. >>> >>> >>> >>> Gerry >>> >>> >>> >>> Ember report by Skip Ashton, Ember VP Engineering. >>> >>> >>> The cause of the problem was an Ember device receiving a coordinator >>> realignment packet. Under the 15.4 specification, this packet is >>> intended to be unicast to an orphan device, or broadcast to a >>> network that is changing its parameters. Receipt of this packet was >>> causing the Ember device to change channels and PAN ID. The 15.4 >>> specification requires this packet be sent with a 64 bit extended >>> address for the source. However, in this case the 16 bit >>> coordinator address for the source was being used making this an >>> illegal packet. This illegal packet to change PAN ID was being >>> generated by another network device at a regular interval. >>> >>> >>> >>> Reception and processing of the coordinator realignment command is >>> mandatory within 802.15.4. However, it should be ignored by devices >>> that are using higher levels of control over items such as channel >>> change. A ZigBee network device is not expecting a coordinator >>> realignment. This command is not used to change channels within >>> ZigBee, because a higher layer network command is used instead. As >>> such, these type of MAC commands should be ignored. >>> >>> >>> >>> A change was made to our stack to ignore such MAC command frames >>> once the ZigBee stack is operational. >>> >>> --- You are currently subscribed to sp100 as: >>> kpister@dustnetworks.com To unsubscribe send a blank email to >>> leave-sp100-100144H@isa-online.org >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 31 18:19:17 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InLtV-0001sa-Jn; Wed, 31 Oct 2007 18:18:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InLtU-0001sL-Gt for 6lowpan@lists.ietf.org; Wed, 31 Oct 2007 18:18:36 -0400 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InLtO-0007Z5-89 for 6lowpan@lists.ietf.org; Wed, 31 Oct 2007 18:18:36 -0400 Received: from dnab42330e.stanford.edu ([171.66.51.14]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1InLtD-0000Ib-Br; Wed, 31 Oct 2007 15:18:19 -0700 In-Reply-To: <4728FC22.1030500@eecs.berkeley.edu> References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> <47275963.2050001@eecs.berkeley.edu> <47276369.8020603@archrock.com> <4728FC22.1030500@eecs.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59516A93-BA7F-4D6A-B568-C0A39CCB6B7C@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [6lowpan] Re: [sp100] interoperability problems at ISA Houston Date: Wed, 31 Oct 2007 15:18:24 -0700 To: Kris Pister X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Oct 31, 2007, at 3:05 PM, Kris Pister wrote: > Hmm. I guess you're right after all - I am confused. I completely > agree with your statements below, but then I re-read RFC4944 and it > says: > "Other non-LoWPAN protocols that wish to coexist with LoWPAN nodes > should include a byte matching this pattern immediately following > the 802.15.4. header." > And I read the Arch Rock 6LoWPAN tutorial (which is really well > done, by the way), and it says "dispatch: coexistence with other > protocols over the same link". These statements do not appear to > be aligned with what you wrote below. > > As I see it, there are only three options: > 1) we assume that MAC-layer MICs are always used for 6LoWPAN, > perhaps with a well-known 6LoWPAN key, and then there is never any > question about coexistence. If you're parsing the dispatch byte, > you already know that this is a 6LoWPAN frame. > 2) we assume 1, but plan to share MAC-layer crypto with other non- > LoWPAN protocols. This sounds like a bad idea from a crypto > standpoint. > 3) we believe that non-6LoWPAN frames may get through to the > network layer, talk about "coexsistence", and cross our fingers > that 15.4 toy designers are all familiar with and abide by the IETF > recommendations. Down this path lies mysteriously failed networks, > broken deployments, and more of the same semi-functionality that > has held WSN commercialization back for the last 5 years. > > So which is it? My vote is #1. I think it's #2. The idea is that you can design protocols that safely operate alongside 6lowpan. If you're concerned about people just grabbing NALP identifiers willy-nilly, well, that's what IANA is for. To give an example, chances are TinyOS 2.1 will introduce an NALP byte for its protocols so TinyOS research protocols can coexist on a node also running 6lowpan. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 31 22:13:13 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InPXd-0005Ry-39; Wed, 31 Oct 2007 22:12:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InPXb-0005Rl-VJ for 6lowpan@lists.ietf.org; Wed, 31 Oct 2007 22:12:15 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InPXa-0008MK-LP for 6lowpan@lists.ietf.org; Wed, 31 Oct 2007 22:12:15 -0400 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id lA12Bl8t018131; Wed, 31 Oct 2007 20:11:47 -0600 (MDT) Subject: Re: [RSN] Re: [6lowpan] Re: [sp100] interoperability problems at ISA Houston From: Geoff Mulligan To: Philip Levis In-Reply-To: <59516A93-BA7F-4D6A-B568-C0A39CCB6B7C@cs.stanford.edu> References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> <47275963.2050001@eecs.berkeley.edu> <47276369.8020603@archrock.com> <4728FC22.1030500@eecs.berkeley.edu> <59516A93-BA7F-4D6A-B568-C0A39CCB6B7C@cs.stanford.edu> Content-Type: text/plain Date: Wed, 31 Oct 2007 20:11:50 -0600 Message-Id: <1193883110.8654.40.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Phil, If the TinyOS research protocol would be possibly using 6lowpan designated other headers, such as HC1 or HC1g or the Frag header, then I would think that rather than using NALP, they could request a non-NALP dispatch value. I would like to see devices that not attempting to utilize any IP and 6lowpan headers/functions assign the first 2 bits after the 15.4 header to Zero. What they do with the other 6 bits then are up to them. I would recommend that IANA stay out of that fray. geoff On Wed, 2007-10-31 at 15:18 -0700, Philip Levis wrote: > On Oct 31, 2007, at 3:05 PM, Kris Pister wrote: > > > Hmm. I guess you're right after all - I am confused. I completely > > agree with your statements below, but then I re-read RFC4944 and it > > says: > > "Other non-LoWPAN protocols that wish to coexist with LoWPAN nodes > > should include a byte matching this pattern immediately following > > the 802.15.4. header." > > And I read the Arch Rock 6LoWPAN tutorial (which is really well > > done, by the way), and it says "dispatch: coexistence with other > > protocols over the same link". These statements do not appear to > > be aligned with what you wrote below. > > > > As I see it, there are only three options: > > 1) we assume that MAC-layer MICs are always used for 6LoWPAN, > > perhaps with a well-known 6LoWPAN key, and then there is never any > > question about coexistence. If you're parsing the dispatch byte, > > you already know that this is a 6LoWPAN frame. > > 2) we assume 1, but plan to share MAC-layer crypto with other non- > > LoWPAN protocols. This sounds like a bad idea from a crypto > > standpoint. > > 3) we believe that non-6LoWPAN frames may get through to the > > network layer, talk about "coexsistence", and cross our fingers > > that 15.4 toy designers are all familiar with and abide by the IETF > > recommendations. Down this path lies mysteriously failed networks, > > broken deployments, and more of the same semi-functionality that > > has held WSN commercialization back for the last 5 years. > > > > So which is it? My vote is #1. > > I think it's #2. > > The idea is that you can design protocols that safely operate > alongside 6lowpan. If you're concerned about people just grabbing > NALP identifiers willy-nilly, well, that's what IANA is for. To give > an example, chances are TinyOS 2.1 will introduce an NALP byte for > its protocols so TinyOS research protocols can coexist on a node also > running 6lowpan. > > Phil > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 31 23:46:40 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InR04-0003eU-T4; Wed, 31 Oct 2007 23:45:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InR02-0003U0-V2; Wed, 31 Oct 2007 23:45:42 -0400 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InQzn-0002gG-UM; Wed, 31 Oct 2007 23:45:33 -0400 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[10.56.142.203]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1InQzJ-00013G-OY; Wed, 31 Oct 2007 20:44:58 -0700 In-Reply-To: <1193883110.8654.40.camel@dellx1> References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> <47275963.2050001@eecs.berkeley.edu> <47276369.8020603@archrock.com> <4728FC22.1030500@eecs.berkeley.edu> <59516A93-BA7F-4D6A-B568-C0A39CCB6B7C@cs.stanford.edu> <1193883110.8654.40.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [RSN] Re: [6lowpan] Re: [sp100] interoperability problems at ISA Houston Date: Wed, 31 Oct 2007 20:44:56 -0700 To: Geoff Mulligan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -2.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: acf3039aa8d32d1ac60a71149e52b94c X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Oct 31, 2007, at 7:11 PM, Geoff Mulligan wrote: > Phil, > > If the TinyOS research protocol would be possibly using 6lowpan > designated other headers, such as HC1 or HC1g or the Frag header, > then I > would think that rather than using NALP, they could request a non-NALP > dispatch value. > > I would like to see devices that not attempting to utilize any IP and > 6lowpan headers/functions assign the first 2 bits after the 15.4 > header > to Zero. What they do with the other 6 bits then are up to them. I > would recommend that IANA stay out of that fray. I don't understand; NALP is the set of all dispatch bytes whose first two bits are zero. If IANA isn't responsible for the NALP values, then I assume no-one is and it's a free-for-all of collision? Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan