From 6lowpan-bounces@ietf.org Sun Jun 03 17:16:56 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 1HuxRT-0004fq-8T; Sun, 03 Jun 2007 17:16:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuxRR-0004Yo-4i; Sun, 03 Jun 2007 17:16:49 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuxRQ-0001xW-9d; Sun, 03 Jun 2007 17:16:49 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jun 2007 17:16:48 -0400 X-IronPort-AV: i="4.16,378,1175486400"; d="scan'208"; a="122679267:sNHT46819934" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l53LGlM1017769; Sun, 3 Jun 2007 17:16:47 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l53LGh5f018841; Sun, 3 Jun 2007 21:16:43 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 17:16:43 -0400 Received: from [10.83.1.98] ([10.83.1.98]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 17:16:42 -0400 Message-ID: <46632FB9.6080705@cisco.com> Date: Sun, 03 Jun 2007 23:16:41 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: "Timothy J. Salo" References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> <46632986.3000401@saloits.com> In-Reply-To: <46632986.3000401@saloits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2007 21:16:43.0177 (UTC) FILETIME=[7BF0F190:01C7A624] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2126; t=1180905408; x=1181769408; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[RSN]=20Update |Sender:=20 |To:=20=22Timothy=20J.=20Salo=22=20; bh=qTwwHhviIRIG/qDj8bcSUlBDjuHrB7v8oWCaP4zQs7o=; b=U2F2JcCkq4aDz8bsh8LUnWZE/UY2WJ5R93v9mZyLj1CL2wClJY0V31vCP1upBFZe0vhh3W+8 cV6YEBBldOwcJeXO2RUzegnBGG3kBq5m0jm1fXnImGESIZOQQtMcA/MJ; Authentication-Results: rtp-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: rsn@ietf.org, 6lowpan@ietf.org Subject: [6lowpan] Re: [RSN] Update 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 Timothy J. Salo wrote: > JP Vasseur wrote: >> 2) New name >> Although we called this initiative RSN: Routing for Sensor Networks, >> it does apply more generally to constrained nodes (Low Power) >> operating in Lossy Networks. Objects in general would typically be >> part of those networks. So from now on, let's rename this work >> R2LN: "Routing issues for Low Power, Lossy Networks", and use that >> acronym in all IDs. > > I suggest that "Routing Issues in Low-Power Wireless Networks" > might be more descriptive. > > "Wireless" implies "lossy". "Wireless" also implies a variety > of other behaviors, such as a limited-range broadcast (usually), > and a variety of others. > > I doubt that we will spend any time at all thinking about > low power wired networks. > > "Low-Power" sounds better than "Resource-Constrained", although > the latter might be more descriptive. > > And finally, to do the job well, this group must look at more > than just routing issues (e.g., neighbor discovery and management > in low-power wireless networks). We might consider: This part should be part of the 6lowpan recharter. The idea amongst the ADs has been to split off the routing portion of the work on low-power networks to the routing area, and continue forward with work on ND, bootstrapping, etc. within the int-area. > > "Internetworking Issues in Low-Power Wireless Networks" > > or > > "Internetworking Issues in Resource-Constrained Wireless Networks" > > or even > > "Internetworking Issues in Resource-Constrained Networks" (I2RCN) > > One (non-trivial) advantage of "Internetworking" is that it > helps answer the question: Why should the IETF (e.g., rather than > the IEEE) be interested in this work? (Assuming that we think > about how low-power wireless networks should be interconnected > with the Internet.) I agree that this is an important topic that should be part of both charters. - Mark > > -tjs > > > _______________________________________________ > 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 Sun Jun 03 18:07:06 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 1HuyE4-0003Kx-E0; Sun, 03 Jun 2007 18:07:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuyE2-0003Js-7e; Sun, 03 Jun 2007 18:07:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuyE1-0007Xb-UL; Sun, 03 Jun 2007 18:07:02 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jun 2007 18:07:00 -0400 X-IronPort-AV: i="4.16,378,1175486400"; d="scan'208"; a="122680616:sNHT49884948" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l53M6xtJ026791; Sun, 3 Jun 2007 18:06:59 -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 l53M6x5f025316; Sun, 3 Jun 2007 22:06:59 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 18:06:59 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 18:06:58 -0400 In-Reply-To: <46632FB9.6080705@cisco.com> References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> <46632986.3000401@saloits.com> <46632FB9.6080705@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B8C1A92-0FC1-4627-8F08-AE189D00078C@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Sun, 3 Jun 2007 18:06:26 -0400 To: Mark Townsley , "Timothy J. Salo" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 03 Jun 2007 22:06:58.0969 (UTC) FILETIME=[817E4890:01C7A62B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2838; t=1180908419; x=1181772419; c=relaxed/simple; s=rtpdkim1001; 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]=20Update |Sender:=20 |To:=20Mark=20Townsley=20, =20=22Timothy=20J.=20Salo=2 2=20; bh=EghmwqmZ5lRcfca+J7Tqtuzd1tie/JDCEQx7xrpocNo=; b=j0+vJsj0kC5nFgGD5Z6cOL2+kCqidN46gEm3Ep96LUDK8RCP9gbPxl4u8p7XYzkuNW8DhzOE 0Ul+AElmwUnDj5SZ4OJ1lA9wIEFhyQku0dzoSQy6uCjkLe2V25jurLfJ; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: rsn@ietf.org, 6lowpan@ietf.org Subject: [6lowpan] Re: [RSN] Update 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, On Jun 3, 2007, at 5:16 PM, Mark Townsley wrote: > Timothy J. Salo wrote: >> JP Vasseur wrote: >>> 2) New name >>> Although we called this initiative RSN: Routing for Sensor >>> Networks, it does apply more generally to constrained nodes (Low >>> Power) >>> operating in Lossy Networks. Objects in general would typically >>> be part of those networks. So from now on, let's rename this work >>> R2LN: "Routing issues for Low Power, Lossy Networks", and use >>> that acronym in all IDs. >> >> I suggest that "Routing Issues in Low-Power Wireless Networks" >> might be more descriptive. >> >> "Wireless" implies "lossy". "Wireless" also implies a variety >> of other behaviors, such as a limited-range broadcast (usually), >> and a variety of others. >> >> I doubt that we will spend any time at all thinking about >> low power wired networks. >> >> "Low-Power" sounds better than "Resource-Constrained", although >> the latter might be more descriptive. >> >> And finally, to do the job well, this group must look at more >> than just routing issues (e.g., neighbor discovery and management >> in low-power wireless networks). We might consider: > This part should be part of the 6lowpan recharter. The idea amongst > the ADs has been to split off the routing portion of the work on > low-power networks to the routing area, and continue forward with > work on ND, bootstrapping, etc. within the int-area. Indeed ... By the way this gives the opportunity to re-enforce the fact that this initiative deals with routing issues *only*. If we need additional specifications for the routing that do not deal with pure routing issues, then we need to ask to 6lowpan indeed. >> >> "Internetworking Issues in Low-Power Wireless Networks" >> >> or >> >> "Internetworking Issues in Resource-Constrained Wireless Networks" >> >> or even >> >> "Internetworking Issues in Resource-Constrained Networks" (I2RCN) >> >> One (non-trivial) advantage of "Internetworking" is that it >> helps answer the question: Why should the IETF (e.g., rather than >> the IEEE) be interested in this work? (Assuming that we think >> about how low-power wireless networks should be interconnected >> with the Internet.) Because I think that these devices will soon be part of the Internet ;-) Quite seriously. And we need to keep the word Routing here. > I agree that this is an important topic that should be part of both > charters. > Thanks. JP. > - Mark >> >> -tjs >> >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn >> > > _______________________________________________ > 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 Jun 04 00:43:45 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 1Hv4Pn-0004U1-TT; Mon, 04 Jun 2007 00:43:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv4Pj-0004HI-Pn for 6lowpan@lists.ietf.org; Mon, 04 Jun 2007 00:43:32 -0400 Received: from seowon.ajou.ac.kr ([202.30.0.18] helo=mail.ajou.ac.kr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hv4Pg-0000V5-F7 for 6lowpan@lists.ietf.org; Mon, 04 Jun 2007 00:43:31 -0400 Received: from ajou.ac.kr (127.0.0.1) by mail.ajou.ac.kr with ESMTP imoxion SensMail SmtpServer 5.0 id <46639bb83fe32b082e1b0da9> for <6lowpan@lists.ietf.org> from ; Mon, 04 Jun 2007 13:43:41 +0900 Message-ID: <46639b193fd1@imoxion.com> Date: Mon, 4 Jun 2007 13:43:44 +0900 (KST) From: Zeeshan Hameed Mir To: manet@ietf.org, rsn@ietf.org, tccc@cs.columbia.edu, 6lowpan@lists.ietf.org, dbworld-request@cs.wisc.edu MIME-Version: 1.0 X-Priority: 3 X-Spam-Score: 1.3 (+) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: Subject: [6lowpan] USN 2007 Extended Deadline to June 15 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="===============0492087753==" Errors-To: 6lowpan-bounces@ietf.org --===============0492087753== Content-Type: multipart/alternative; boundary="----=_Part_2714160_11466737.1180932224370" ------=_Part_2714160_11466737.1180932224370 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 W1BsZWFzZSBhY2NlcHQgb3VyIGFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2ZSBtdWx0aXBsZSBjb3Bp ZXMgb2YgdGhpcyBDRlBdIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tIA0KQ0FMTCBGT1IgUEFQRVJTIGZvciBVU04gMjAwNyANCg0KVGhlIDNy ZCBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIFJGSUQgYW5kIFViaXF1aXRvdXMgU2Vuc29yIE5l dHdvcmtzIChVU04pIA0KDQpodHRwOi8vdW5zLmFqb3UuYWMua3IvfnVzbjIwMDcvLCBEZWNlbWJl ciAxNy0yMCwgMjAwNywgVGFpcGVpLCBUYWl3YW4pIA0KDQpUbyBiZSBoZWxkIGluIGNvbmp1bmN0 aW9uIHdpdGggRVVDIDIwMDcgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tIA0KDQoNCkltcG9ydGFudCBEYXRlczogDQoNCiogU3VibWlzc2lvbiBE dWU6IEp1bmUgMTUsIDIwMDcgKGV4dGVuZGVkIGRlYWRsaW5lKSANCg0KKiBBY2NlcHRhbmNlIG5v dGlmaWNhdGlvbjogQXVndXN0IDYsIDIwMDcgDQoNCiogQ2FtZXJhLXJlYWR5IGR1ZTogU2VwdGVt YmVyIDQsIDIwMDcgDQoNCiAgDQpBYm91dCB0aGUgd29ya3Nob3A6IA0KDQpUaGUgcHVycG9zZSBv ZiBVU04gMjAwNyBpcyB0byBlc3RhYmxpc2ggYSBkaXNjdXNzaW9uIGZyYW1ld29yayBvbiBhbGwg dGhlIGNoYWxsZW5nZXMgcmFpc2VkIGZyb20gdGhlIGV2b2x1dGlvbiBvZiB0aGUgVWJpcXVpdG91 cyBTZW5zb3IgTmV0d29ya3MgYW5kIFJGSUQgdGVjaG5vbG9naWVzLiBBcyBhIHVuaXF1ZSBvcHBv cnR1bml0eSB0byBvYnRhaW4gYW4gaW5zaWdodCBvbiB0aGUgbGVhZGluZyB0ZWNobm9sb2dpZXMg b2YgdGhlIG5leHQgcGVydmFzaXZlIGVyYSwgVVNOIDIwMDcgd2FudHMgdG8gaW52aXRlIHJlc2Vh cmNoZXJzIHRvIHByZXNlbnQgYW5kIGRpc2N1c3MgdGhlaXIgaWRlYXMuIA0KICANCg0KVG9waWNz IG9mIHRoaXMgd29ya3Nob3AgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0bzogDQoNCqGk ICAgICAgICAgUkZJRCBTeXN0ZW1zIGFuZCBBcmNoaXRlY3R1cmUgDQoNCqGkICAgICAgICAgUkZJ RCBNaWRkbGV3YXJlIERlc2lnbiANCg0KoaQgICAgICAgICBBbnRpLWNvbGxpc2lvbiBhbGdvcml0 aG1zIA0KDQqhpCAgICAgICAgIE1vYmlsZSBSRklEIFN5c3RlbXMgYW5kIEFwcGxpY2F0aW9ucyAN Cg0KoaQgICAgICAgICBEYXRhIE1vZGVsaW5nIGFuZCBNYW5hZ2VtZW50IA0KDQqhpCAgICAgICAg IEVtYmVkZGVkIFJGSUQtZW5hYmxlZCBEZXZpY2UgVGVjaG5vbG9neSANCg0KoaQgICAgICAgICBT ZW5zb3IgTmV0d29yayBBcmNoaXRlY3R1cmVzIGFuZCBQcm90b2NvbHMgDQoNCqGkICAgICAgICAg TmV0d29yayBwcm90b2NvbHMsIGUuZy4sIE1BQyBhbmQgcm91dGluZyANCg0KoaQgICAgICAgICBE aXN0cmlidXRlZCBBbGdvcml0aG1zLCBlLmcuLCBMb2NhbGl6YXRpb24gYW5kIFN5bmNocm9uaXph dGlvbiANCg0KoaQgICAgICAgICBDcm9zcyBMYXllciBhbmQgRW5lcmd5IEVmZmljaWVudCBEZXNp Z24gDQoNCqGkICAgICAgICAgVVNOIE1pZGRsZXdhcmUgSXNzdWVzLCBlLmcuLCBPUyBhbmQgRGF0 YWJhc2UgDQoNCqGkICAgICAgICAgQ29leGlzdGVuY2Ugb2YgUkZJRCAmIFVTTiANCg0KoaQgICAg ICAgICBRb1MgYW5kIFJlYWwtVGltZSBJc3N1ZXMgDQoNCqGkICAgICAgICAgU2VjdXJpdHkgYW5k IHByaXZhY3kgaXNzdWVzIA0KDQqhpCAgICAgICAgIE5ldHdvcmsgTWFuYWdlbWVudCBpbiBMYXJn ZS1zY2FsZSBEZXBsb3ltZW50IA0KDQqhpCAgICAgICAgIENvZXhpc3RlbmNlIG9mIFJGSUQgJiBV U04gDQoNCqGkICAgICAgICAgTm92ZWwgUkZJRCBhbmQgVVNOIEFwcGxpY2F0aW9ucyANCiAgDQoN CldvcmtzaG9wIENoYWlycyANCi0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KDQpZb3VuZy1CYWUgS28s IEFqb3UgVW5pdmVyc2l0eSwgS29yZWEgDQoNCkthbmctV29uIExlZSwgSUJNIFQuSiBXYXRzb24g UmVzZWFyY2gsIFVTQSANCg0KICANCg0KU3RlZXJpbmcgQ29tbWl0dGVlIA0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSANCg0KSm9uZ3N1ayBDaGFlLCBFVFJJLCBLb3JlYSANCg0KU2V1bmctV2hhIFlv bywgQWpvdSBVbml2ZXJzaXR5LCBLb3JlYSANCg0KWXUtQ2hlZSBUc2VuZywgTmF0aW9uYWwgQ2hp YW8gVHVuZyBVbml2LiwgVGFpd2FuIA0KDQpEYWV5b3VuZyBLaW0sIEluZm9ybWF0aW9uIGFuZCBD b21tdW5pY2F0aW9ucyBVbml2ZXJzaXR5LCBLb3JlYSANCg0KICANCg0KUHJvZ3JhbSBDb21taXR0 ZWUgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoNCkJ5dW5naHVuIFNvbmcsIEtFVEksIEtv cmVhIA0KDQpDaGFuc3UgWXUsIENsZXZlbGFuZCBTdGF0ZSBVbml2ZXJzaXR5LCBVU0EgDQoNCkNo aWgtWXVuZyBDaGFuZywgVGFta2FuZyBVbml2ZXJzaXR5LCBUYWl3YW4gDQoNCkRvbmctS3l1biBL aW0sIEt5dW5ncG9vayBOYXRpb25hbCBVbml2ZXJzaXR5LCBLb3JlYSANCg0KSmFlLUh5dW4gS2lt LCBBam91IFVuaXZlcnNpdHksIEtvcmVhIA0KDQpKYXZpZXIgR29tZXosIE5hdGlvbmFsIFVuaXZl cnNpdHkgb2YgTWV4aWNvLCBNZXhpY28gDQoNCkthbmctV29uIExlZSwgSUJNIFQuSiBXYXRzb24g UmVzZWFyY2gsIFVTQSANCg0KS3VpIFd1LCBVbml2ZXJzaXR5IG9mIFZpY3RvcmlhLCBDYW5hZGEg DQoNCkxpbmctSnloIENoZW4sIEluc3RpdHV0ZSBvZiBJbmZvcm1hdGlvbiBTY2llbmNlLCBUYWl3 YW4gDQoNCk1pbmVvIFRha2FpLCBVQ0xBLCBVU0EgDQoNCk1pbmctSmVyIFRzYWksIE5hdGlvbmFs IFRzaW5nLUh1YSBVbml2LiwgVGFpd2FuIA0KDQpNaXNjaGEgRG9obGVyLCBGcmFuY2UgVGVsZWNv bSwgRnJhbmNlIA0KDQpNb2hhbWVkIFlvdW5pcywgVW5pdmVyc2l0eSBvZiBNYXJ5bGFuZCwgVVNB IA0KDQpPemd1ciBFcmNldGluLCBTYWJhbmNpIFVuaXZlcnNpdHksIFR1cmtleSANCg0KU2FhZCBC aWF6LCBBdWJ1cm4gVW5pdmVyc2l0eSwgVVNBIA0KDQpUYWVreXVuZyBLd29uLCBTZW91bCBOYXRp b25hbCBVbml2ZXJzaXR5LCBLb3JlYSANCg0KVGFlLUppbiBMZWUsIFN1bmdreXVua3dhbiBVbml2 ZXJzaXR5LCBLb3JlYSANCg0KWXVoLVNoeWFuIENoZW4sIE5hdGlvbmFsIENodW5nIENoZW5nIFVu aXZlcnNpdHksIFRhaXdhbiANCg0KV2VpIExvdSwgSG9uZyBLb25nIFBvbHl0ZWNobmljIFVuaXZl cnNpdHksIENoaW5hIA0KDQpXZW4tQ2hpaCBQZW5nLCBOYXRpb25hbCBDaGlhbyBUdW5nIFVuaXYu LCBUYWl3YW4gDQoNCldvbmp1biBMZWUsIEtvcmVhIFVuaXZlcnNpdHksIEtvcmVhIA0KDQotLS0t LQ0KDQpaZWVzaGFuIEhhbWVlZCBNaXIsDQpBam91IFVuaXZlcnNpdHksIFNvdXRoIEtvcmVhDQoN Cg== ------=_Part_2714160_11466737.1180932224370 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlIHR5cGU9J3RleHQvY3NzJz4gUCB7cGFkZGluZzowcHg7IG1hcmdp bjoycHg7IGJvcmRlcjowcHg7Zm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6J2FyaWFsJzt9ICBi b2R5IHtwYWRkaW5nOjVweDsgbWFyZ2luOjBweDsgYm9yZGVyOjBweDtmb250LXNpemU6MTNweDtm b250LWZhbWlseTonYXJpYWwnO30gPC9zdHlsZT48L2hlYWQ+PGJvZHk+PHRhYmxlIHdpZHRoPTk5 JSBhbGlnbj1jZW50ZXIgaGVpZ2h0PScxMDAnPjx0ciB2YWxpZ249dG9wPjx0ZD48Zm9udCBzaXpl PTI+PFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogc2Fucy1zZXJpZiI+W1BsZWFzZSBhY2NlcHQgb3VyIGFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2 ZSBtdWx0aXBsZSBjb3BpZXMgb2YgdGhpcyBDRlBdPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVM+IDxC Uj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvU1BBTj48L0ZP TlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IHNhbnMtc2VyaWYiPkNBTEwgRk9SIFBBUEVSUyBmb3IgVVNOIDIwMDc8L1NQQU4+PC9GT05UPjxT UEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXpl PTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog c2Fucy1zZXJpZiI+VGhlIDNyZCBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIFJGSUQgYW5kIFVi aXF1aXRvdXMgU2Vuc29yIE5ldHdvcmtzIChVU04pIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1F Ti1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxh bmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYi Pmh0dHA6Ly91bnMuYWpvdS5hYy5rci9+dXNuMjAwNy8sIERlY2VtYmVyIDE3LTIwLCAyMDA3LCBU YWlwZWksIFRhaXdhbik8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9T UEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+VG8gYmUgaGVsZCBpbiBj b25qdW5jdGlvbiB3aXRoIEVVQyAyMDA3PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8 QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvU1BBTj48L0ZPTlQ+ PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJp ZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogc2Fucy1zZXJpZiI+SW1wb3J0YW50IERhdGVzOjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFu Zz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNl cmlmIj4qIFN1Ym1pc3Npb24gRHVlOiBKdW5lIDE1LCAyMDA3IChleHRlbmRlZCBkZWFkbGluZSk8 L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+KiBBY2NlcHRhbmNlIG5vdGlmaWNhdGlvbjogQXVn dXN0IDYsIDIwMDcgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFO PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+KiBDYW1lcmEtcmVhZHkgZHVl OiBTZXB0ZW1iZXIgNCwgMjAwNyA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxC Uj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4mbmJzcDs8L1NQ QU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBzYW5zLXNlcmlmIj5BYm91dCB0aGUgd29ya3Nob3A6PC9TUEFOPjwvRk9OVD48U1BB TiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNh bnMtc2VyaWYiPlRoZSBwdXJwb3NlIG9mIFVTTiAyMDA3IGlzIHRvIGVzdGFibGlzaCBhIGRpc2N1 c3Npb24gZnJhbWV3b3JrIG9uIGFsbCB0aGUgY2hhbGxlbmdlcyByYWlzZWQgZnJvbSB0aGUgZXZv bHV0aW9uIG9mIHRoZSBVYmlxdWl0b3VzIFNlbnNvciBOZXR3b3JrcyBhbmQgUkZJRCB0ZWNobm9s b2dpZXMuIEFzIGEgdW5pcXVlIG9wcG9ydHVuaXR5IHRvIG9idGFpbiBhbiBpbnNpZ2h0IG9uIHRo ZSBsZWFkaW5nIHRlY2hub2xvZ2llcyBvZiB0aGUgbmV4dCBwZXJ2YXNpdmUgZXJhLCBVU04gMjAw NyB3YW50cyB0byBpbnZpdGUgcmVzZWFyY2hlcnMgdG8gcHJlc2VudCBhbmQgZGlzY3VzcyB0aGVp ciBpZGVhcy4gPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48L1NQQU4+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4mbmJzcDs8L1NQQU4+PC9GT05UPjxTUEFO IGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fu cy1zZXJpZiI+VG9waWNzIG9mIHRoaXMgd29ya3Nob3AgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGlt aXRlZCB0bzogPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFJGSUQgU3lzdGVtcyBhbmQgQXJjaGl0ZWN0dXJlIDwvU1BBTj48L0ZPTlQ+PFNQ QU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNh bnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSRklEIE1pZGRsZXdhcmUg RGVzaWduIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9O VCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBBbnRpLWNvbGxpc2lvbiBhbGdvcml0aG1zIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFu Zz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2Vy aWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNb2JpbGUgUkZJRCBTeXN0ZW1zIGFu ZCBBcHBsaWNhdGlvbnMgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9T UEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IERhdGEgTW9kZWxpbmcgYW5kIE1hbmFnZW1lbnQgPC9TUEFOPjwvRk9O VD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEVtYmVkZGVkIFJG SUQtZW5hYmxlZCBEZXZpY2UgVGVjaG5vbG9neSA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4t VVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6h pCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2Vuc29yIE5ldHdvcmsgQXJjaGl0ZWN0dXJl cyBhbmQgUHJvdG9jb2xzIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwv U1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBOZXR3b3JrIHByb3RvY29scywgZS5nLiwgTUFDIGFuZCByb3V0aW5n IDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNl PXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBEaXN0cmlidXRlZCBBbGdvcml0aG1zLCBlLmcuLCBMb2NhbGl6YXRpb24gYW5kIFN5bmNocm9u aXphdGlvbiA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZP TlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgQ3Jvc3MgTGF5ZXIgYW5kIEVuZXJneSBFZmZpY2llbnQgRGVzaWduIDwvU1BBTj48 L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2Vy aWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBVU04gTWlk ZGxld2FyZSBJc3N1ZXMsIGUuZy4sIE9TIGFuZCBEYXRhYmFzZSA8L1NQQU4+PC9GT05UPjxTUEFO IGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5z LXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ29leGlzdGVuY2Ugb2YgUkZJ RCAmYW1wOyBVU04gPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFO PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFFvUyBhbmQgUmVhbC1UaW1lIElzc3VlcyA8L1NQQU4+PC9GT05UPjxTUEFO IGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5z LXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2VjdXJpdHkgYW5kIHByaXZh Y3kgaXNzdWVzIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48 Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBOZXR3b3JrIE1hbmFnZW1lbnQgaW4gTGFyZ2Utc2NhbGUgRGVwbG95bWVudCA8 L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1z YW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Q29leGlzdGVuY2Ugb2YgUkZJRCAmYW1wOyBVU04gPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVO LVVTPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+ oaQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE5vdmVsIFJGSUQgYW5kIFVTTiBBcHBsaWNh dGlvbnMgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48L1NQQU4+PEZPTlQgZmFj ZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4mbmJzcDs8L1NQQU4+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1z ZXJpZiI+V29ya3Nob3AgQ2hhaXJzPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+ PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+LS0tLS0tLS0tLS0t LS0tLS0tLS08L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+WW91bmctQmFlIEtvLCBBam91IFVu aXZlcnNpdHksIEtvcmVhIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwv U1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkthbmctV29uIExlZSwg SUJNIFQuSiBXYXRzb24gUmVzZWFyY2gsIFVTQTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1V Uz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4m bmJzcDs8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05U IGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+U3RlZXJpbmcgQ29tbWl0dGVlIDwvU1BB Tj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJp ZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogc2Fucy1zZXJpZiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvU1BBTj48L0ZPTlQ+PFNQ QU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9 Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBz YW5zLXNlcmlmIj5Kb25nc3VrIENoYWUsIEVUUkksIEtvcmVhPC9TUEFOPjwvRk9OVD48U1BBTiBs YW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMt c2VyaWYiPlNldW5nLVdoYSBZb28sIEFqb3UgVW5pdmVyc2l0eSwgS29yZWE8L1NQQU4+PC9GT05U PjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogc2Fucy1zZXJpZiI+WXUtQ2hlZSBUc2VuZywgTmF0aW9uYWwgQ2hpYW8gVHVuZyBVbml2Liwg VGFpd2FuPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9O VCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkRhZXlvdW5nIEtpbSwgSW5mb3JtYXRp b24gYW5kIENvbW11bmljYXRpb25zIFVuaXZlcnNpdHksIEtvcmVhPC9TUEFOPjwvRk9OVD48U1BB TiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNh bnMtc2VyaWYiPiZuYnNwOzwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48 L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5Qcm9ncmFtIENvbW1p dHRlZTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjwvU1BBTj48Rk9OVCBmYWNl PXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvU1BB Tj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5z LXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5CeXVuZ2h1biBTb25nLCBLRVRJLCBLb3JlYTwvU1BBTj48 L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBzYW5zLXNlcmlmIj5DaGFuc3UgWXUsIENsZXZlbGFuZCBTdGF0ZSBVbml2ZXJzaXR5 LCBVU0E8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05U IGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+Q2hpaC1ZdW5nIENoYW5nLCBUYW1rYW5n IFVuaXZlcnNpdHksIFRhaXdhbjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxC Uj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5Eb25nLUt5dW4g S2ltLCBLeXVuZ3Bvb2sgTmF0aW9uYWwgVW5pdmVyc2l0eSwgS29yZWE8L1NQQU4+PC9GT05UPjxT UEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXpl PTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog c2Fucy1zZXJpZiI+SmFlLUh5dW4gS2ltLCBBam91IFVuaXZlcnNpdHksIEtvcmVhPC9TUEFOPjwv Rk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2Vy aWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IHNhbnMtc2VyaWYiPkphdmllciBHb21leiwgTmF0aW9uYWwgVW5pdmVyc2l0eSBvZiBN ZXhpY28sIE1leGljbzwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQ QU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5LYW5nLVdvbiBMZWUsIElC TSBULkogV2F0c29uIFJlc2VhcmNoLCBVU0E8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+ IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+S3Vp IFd1LCBVbml2ZXJzaXR5IG9mIFZpY3RvcmlhLCBDYW5hZGE8L1NQQU4+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1z ZXJpZiI+TGluZy1KeWggQ2hlbiwgSW5zdGl0dXRlIG9mIEluZm9ybWF0aW9uIFNjaWVuY2UsIFRh aXdhbjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5NaW5lbyBUYWthaSwgVUNMQSwgVVNBPC9T UEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPk1pbmctSmVyIFRzYWksIE5hdGlvbmFsIFRzaW5nLUh1 YSBVbml2LiwgVGFpd2FuPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwv U1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPk1pc2NoYSBEb2hsZXIs IEZyYW5jZSBUZWxlY29tLCBGcmFuY2U8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxC Uj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+TW9oYW1l ZCBZb3VuaXMsIFVuaXZlcnNpdHkgb2YgTWFyeWxhbmQsIFVTQTwvU1BBTj48L0ZPTlQ+PFNQQU4g bGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5z LXNlcmlmIj5Pemd1ciBFcmNldGluLCBTYWJhbmNpIFVuaXZlcnNpdHksIFR1cmtleTwvU1BBTj48 L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBzYW5zLXNlcmlmIj5TYWFkIEJpYXosIEF1YnVybiBVbml2ZXJzaXR5LCBVU0E8L1NQ QU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fu cy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogc2Fucy1zZXJpZiI+VGFla3l1bmcgS3dvbiwgU2VvdWwgTmF0aW9uYWwgVW5p dmVyc2l0eSwgS29yZWE8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9T UEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+VGFlLUppbiBMZWUsIFN1 bmdreXVua3dhbiBVbml2ZXJzaXR5LCBLb3JlYTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1V Uz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5Z dWgtU2h5YW4gQ2hlbiwgTmF0aW9uYWwgQ2h1bmcgQ2hlbmcgVW5pdmVyc2l0eSwgVGFpd2FuPC9T UEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPldlaSBMb3UsIEhvbmcgS29uZyBQb2x5dGVjaG5pYyBV bml2ZXJzaXR5LCBDaGluYTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48 L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5XZW4tQ2hpaCBQZW5n LCBOYXRpb25hbCBDaGlhbyBUdW5nIFVuaXYuLCBUYWl3YW48L1NQQU4+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1z ZXJpZiI+V29uanVuIExlZSwgS29yZWEgVW5pdmVyc2l0eSwgS29yZWE8L1NQQU4+PC9GT05UPjxT UEFOIGxhbmc9RU4tVVM+IDxCUj48L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1FTi1VUz4tLS0t LTwvU1BBTj48L1A+DQo8UD48U1BBTiBsYW5nPUVOLVVTPjwvU1BBTj4mbmJzcDs8L1A+DQo8UD48 U1BBTiBsYW5nPUVOLVVTPlplZXNoYW4gSGFtZWVkIE1pciw8L1NQQU4+PC9QPg0KPFA+PFNQQU4g bGFuZz1FTi1VUz5Bam91IFVuaXZlcnNpdHksIFNvdXRoIEtvcmVhPC9QPjwvU1BBTj48L2ZvbnQ+ PC90ZD48L3RyPjwvdGFibGU+PGJyPg0KPGltZyBpZD0nbWFpbGV4cCcgd2lkdGg9MCBoZWlnaD0w IGJvcmRlcj0wIHNyYz0naHR0cDovL21haWwuYWpvdS5hYy5rcjo4MC9tYWlsX3JlY2VpcHRfY2hl Y2suanNwP3VrZXk9NDY2MzliMTgzZmU2ZDkzYTYwZTkwNjViJnVzZXJpZD16aG1pciZhaG9zdD1h am91X2FjX2tyJz48L2JvZHk+PC9odG1sPg== ------=_Part_2714160_11466737.1180932224370-- --===============0492087753== 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 --===============0492087753==-- From 6lowpan-bounces@ietf.org Mon Jun 04 00:51:43 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 1Hv4Xf-0001Mu-AY; Mon, 04 Jun 2007 00:51:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv4Xe-0001Mp-AS for 6lowpan@ietf.org; Mon, 04 Jun 2007 00:51:42 -0400 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv4Xd-0001Xz-Rn for 6lowpan@ietf.org; Mon, 04 Jun 2007 00:51:42 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id 3593716B0002; Sun, 3 Jun 2007 21:51:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,TW_KS,TW_SJ autolearn=no version=3.1.8 Received: from [127.0.0.1] (adsl-71-142-92-55.dsl.pltn13.pacbell.net [71.142.92.55]) by secure.archedrock.com (Postfix) with ESMTP id 1F9E416B0001; Sun, 3 Jun 2007 21:51:40 -0700 (PDT) Message-ID: <46639A57.8060807@archrock.com> Date: Sun, 03 Jun 2007 21:51:35 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Kris Pister Subject: Re: [6lowpan] Dispatch value bit pattern for 6lowPAN References: <3D8BC6C339A9894C9955EF58D3722D6591257C@dust-exch-02.dusthq.dust-inc.com> In-Reply-To: <3D8BC6C339A9894C9955EF58D3722D6591257C@dust-exch-02.dusthq.dust-inc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: 6lowpan@ietf.org, David Culler 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 There are two cases when we talk about coexistence of protocols: (i)=20 protocols that run on logically distinct networks and (ii) protocols=20 that run on the same network. In the former case, I agree that computing=20 MICs is the answer to keep the logically distinct networks separate, and=20 should not rely on a few defined bits in the message payload. Using MICs=20 is simply common sense when building a robust network. However, allowing=20 multiple protocols to coexist on the same network is an important notion=20 to keep when moving forward. LLC/SNAP allows different protocols to=20 coexist above 802.3 and 802.11. IPv4 networks rely on a some of these=20 protocols (e.g. ARP). While IPv6 has essentially moved ARP into ND,=20 there may be other (possibly yet unforeseen) cases where we want one or=20 more protocols operating directly on top of L2 to coexist with 6lowpan. -- Jonathan Hui jhui@archrock.com Kris Pister wrote: > David =96 nice tutorial. That=92s very helpful. >=20 > =20 >=20 > Regarding the dispatch discussion, I=92m still concerned that this appe= ars=20 > to be leading people to draw the wrong conclusions, or worse, carry=20 > forward the wrong assumptions. >=20 > =20 >=20 > Successful coexistence has nothing to do with the first two bits of the= =20 > network header. Any implementations that make that assumption are=20 > doomed. Even if we could get the whole world to agree on dispatch=20 > values, those bits (and others) are still going to get flipped=20 > undetected every now and then between TX and RX. None of the=20 > proprietary protocols and international standards with which I=92ve bee= n=20 > associated have ignored the issue of coexistence. Quite the contrary,=20 > we=92ve spent countless hours in discussion and debate on the topic. >=20 > =20 >=20 > The conclusion is that without a message integrity check above and=20 > beyond the 802.15.4 FCS, you=92re doomed. With the CRC16, you can=20 > probably get away with a 2 byte MIC, but 4 is safer and in any case=20 > that=92s what the 15.4 standard supports. So if you=92ve got to have M= IC,=20 > then coexistence is simple. We can choose a default 6lowPAN key=20 > (0x495056366F766572366C6F7750414E21 encodes =93IPv6over6lowPAN=94 nicel= y in=20 > 128 bits J ), and unless someone intentionally uses that same key, then= =20 > the chances of 6lowPAN networks having coexistence problems with=20 > SmartMesh or HART or sp100 (or zigbee with security turned on) are=20 > effectively zero. The only coexistence problems then are for people wh= o=20 > **don=92t** use a MIC (e.g. zigbee with security turned off), and the=20 > problem is for them, not for us. >=20 > Once the MAC layer has signed off on the MIC, then your network layer=20 > knows with confidence that this is in fact a valid packet, and **then**= =20 > it can look at the first two bits of the network header and do its job. >=20 > =20 >=20 > This seems really simple and obvious to me. Am I missing something? >=20 > =20 >=20 > ksjp >=20 > =20 >=20 > Kristofer S.J.Pister, Founder & CTO >=20 > Dust Networks, 30695 Huntwood Ave. > Hayward, CA 94544 > 510-548-DUST >=20 > -----------------------------------------------------------------------= - >=20 > *From:* David Culler [mailto:david.culler@gmail.com] > *Sent:* Wednesday, May 30, 2007 4:39 PM > *To:* 6lowpan@ietf.org; anthony.schoofs@philips.com > *Subject:* [6lowpan] Dispatch value bit pattern for 6lowPAN >=20 > =20 >=20 > Anthony, > There was a good bit of discussion on the partitioning of the=20 > dispatch field following the San Diego meeting. Many felt that ideally= ,=20 > the protocol identifier would have been carried in the 15.4 header, so=20 > we were back filling. There was discussion about utilizing only a smal= l=20 > fraction of the initial dispatch address space, so there would be more=20 > room for coexistence with other protocols. There was not a lot of=20 > discussion about whether we could define the initial dispatch in such a= =20 > way that it would provide backward-going coexistence pre-existing=20 > protocols, since none of the proprietary or industry forum protocols=20 > seemed to have considered leaving room for others to fit alongside. =20 > Perhaps the forward-going hope was that new efforts would at least live= =20 > along side of 6LoWPAN and all the protocols built on top of it. >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > 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 Jun 04 01:23:36 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 1Hv52T-000220-A1; Mon, 04 Jun 2007 01:23:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv52R-00021t-SU for 6lowpan@ietf.org; Mon, 04 Jun 2007 01:23:31 -0400 Received: from an-out-0708.google.com ([209.85.132.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv52P-0004nE-FT for 6lowpan@ietf.org; Mon, 04 Jun 2007 01:23:31 -0400 Received: by an-out-0708.google.com with SMTP id c17so314248anc for <6lowpan@ietf.org>; Sun, 03 Jun 2007 22:23:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=rDR4FyxvO6n3gdO3Ym7uWmoBhU3CYKfdE5LimUCB6ihBTnOT4uXwCCOqi7Ef7jQG39xvb4LEmhehHq69exdN5IkouZjehEb3Jbib/Ffy/CxAAF2yzqOS433txkv843P9eDWroK+gTej5Dti0GM5Fe5WTinNLNG8YBHKtO2Ikx0c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=drlc0xNoSxFiArdDrOpgEpOnmPaiMHXhmFIwoW9LqXHSgOqcnd+7naHsW+sW/nk7BviWIbaRaB2RwEXi1WDOuXIv9sQxHpYfNqmJwnAyhKWZzW7CyisJz6eEVrGSZqQsCnX63uaF3urrorPQCrMKfDGzIphRruXqD+LAS9YIWqo= Received: by 10.100.210.10 with SMTP id i10mr2370871ang.1180934608955; Sun, 03 Jun 2007 22:23:28 -0700 (PDT) Received: by 10.100.11.16 with HTTP; Sun, 3 Jun 2007 22:23:28 -0700 (PDT) Message-ID: <1edd46e70706032223q445004b8j105ef127c4ad19da@mail.gmail.com> Date: Sun, 3 Jun 2007 22:23:28 -0700 From: "Joe Polastre" To: "Jonathan Hui" Subject: Re: [6lowpan] Dispatch value bit pattern for 6lowPAN In-Reply-To: <46639A57.8060807@archrock.com> MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <3D8BC6C339A9894C9955EF58D3722D6591257C@dust-exch-02.dusthq.dust-inc.com> <46639A57.8060807@archrock.com> X-Google-Sender-Auth: 375014a11178db98 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: 6lowpan@ietf.org, David Culler 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 What Kris was proposing achieves the goals of both (i) and (ii) networks. The MIC has become a standard parameter for a variety of different networking standards. By including it at layer 2, you're promoting co-existence with other protocols of the same layer 2 implementation while permitting flexibility in the network protocol selection (pick from the alphabet soup of IPv6, SP100.11a, Zigbee Pro, or Wireless HART). Quite frankly, LLC/802.2 has been ineffective at best in promoting different protocols to coexist. Most major operating systems build their own abstraction, or do implement 802.2 but bypass it for quite a few instances. Linux, for example, implements case statements in its IP implementation that changes the behavior of IP based on the type of underlying link. Given that this is an IP-based standards group, the only clear existing abstraction that has effectively decoupled the lower layers and permitted coexistence is IP and not 802.2 or LLC. That doesn't mean it should be ignored; however, it does not achieve the goals that you outline in your email. -Joe On 6/3/07, Jonathan Hui wrote: > > There are two cases when we talk about coexistence of protocols: (i) > protocols that run on logically distinct networks and (ii) protocols > that run on the same network. In the former case, I agree that computing > MICs is the answer to keep the logically distinct networks separate, and > should not rely on a few defined bits in the message payload. Using MICs > is simply common sense when building a robust network. However, allowing > multiple protocols to coexist on the same network is an important notion > to keep when moving forward. LLC/SNAP allows different protocols to > coexist above 802.3 and 802.11. IPv4 networks rely on a some of these > protocols (e.g. ARP). While IPv6 has essentially moved ARP into ND, > there may be other (possibly yet unforeseen) cases where we want one or > more protocols operating directly on top of L2 to coexist with 6lowpan. > > -- > Jonathan Hui > jhui@archrock.com > > > Kris Pister wrote: > > David =96 nice tutorial. That's very helpful. > > > > > > > > Regarding the dispatch discussion, I'm still concerned that this appear= s > > to be leading people to draw the wrong conclusions, or worse, carry > > forward the wrong assumptions. > > > > > > > > Successful coexistence has nothing to do with the first two bits of the > > network header. Any implementations that make that assumption are > > doomed. Even if we could get the whole world to agree on dispatch > > values, those bits (and others) are still going to get flipped > > undetected every now and then between TX and RX. None of the > > proprietary protocols and international standards with which I've been > > associated have ignored the issue of coexistence. Quite the contrary, > > we've spent countless hours in discussion and debate on the topic. > > > > > > > > The conclusion is that without a message integrity check above and > > beyond the 802.15.4 FCS, you're doomed. With the CRC16, you can > > probably get away with a 2 byte MIC, but 4 is safer and in any case > > that's what the 15.4 standard supports. So if you've got to have MIC, > > then coexistence is simple. We can choose a default 6lowPAN key > > (0x495056366F766572366C6F7750414E21 encodes "IPv6over6lowPAN" nicely in > > 128 bits J ), and unless someone intentionally uses that same key, then > > the chances of 6lowPAN networks having coexistence problems with > > SmartMesh or HART or sp100 (or zigbee with security turned on) are > > effectively zero. The only coexistence problems then are for people wh= o > > **don't** use a MIC (e.g. zigbee with security turned off), and the > > problem is for them, not for us. > > > > Once the MAC layer has signed off on the MIC, then your network layer > > knows with confidence that this is in fact a valid packet, and **then** > > it can look at the first two bits of the network header and do its job. > > > > > > > > This seems really simple and obvious to me. Am I missing something? > > > > > > > > ksjp > > > > > > > > Kristofer S.J.Pister, Founder & CTO > > > > Dust Networks, 30695 Huntwood Ave. > > Hayward, CA 94544 > > 510-548-DUST > > > > -----------------------------------------------------------------------= - > > > > *From:* David Culler [mailto:david.culler@gmail.com] > > *Sent:* Wednesday, May 30, 2007 4:39 PM > > *To:* 6lowpan@ietf.org; anthony.schoofs@philips.com > > *Subject:* [6lowpan] Dispatch value bit pattern for 6lowPAN > > > > > > > > Anthony, > > There was a good bit of discussion on the partitioning of the > > dispatch field following the San Diego meeting. Many felt that ideally= , > > the protocol identifier would have been carried in the 15.4 header, so > > we were back filling. There was discussion about utilizing only a smal= l > > fraction of the initial dispatch address space, so there would be more > > room for coexistence with other protocols. There was not a lot of > > discussion about whether we could define the initial dispatch in such a > > way that it would provide backward-going coexistence pre-existing > > protocols, since none of the proprietary or industry forum protocols > > seemed to have considered leaving room for others to fit alongside. > > Perhaps the forward-going hope was that new efforts would at least live > > along side of 6LoWPAN and all the protocols built on top of it. > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > 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 > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 04 02:08:47 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 1Hv5kE-0003S6-2m; Mon, 04 Jun 2007 02:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv5kC-0003Ry-8m for 6lowpan@ietf.org; Mon, 04 Jun 2007 02:08:44 -0400 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv5kB-0000gO-Tv for 6lowpan@ietf.org; Mon, 04 Jun 2007 02:08:44 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id 4CE3E16B0001; Sun, 3 Jun 2007 23:08:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.8 Received: from [127.0.0.1] (adsl-71-142-92-55.dsl.pltn13.pacbell.net [71.142.92.55]) by secure.archedrock.com (Postfix) with ESMTP id 8863016B0001; Sun, 3 Jun 2007 23:08:42 -0700 (PDT) Message-ID: <4663AC66.9000409@archrock.com> Date: Sun, 03 Jun 2007 23:08:38 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Joe Polastre Subject: Re: [6lowpan] Dispatch value bit pattern for 6lowPAN References: <3D8BC6C339A9894C9955EF58D3722D6591257C@dust-exch-02.dusthq.dust-inc.com> <46639A57.8060807@archrock.com> <1edd46e70706032223q445004b8j105ef127c4ad19da@mail.gmail.com> In-Reply-To: <1edd46e70706032223q445004b8j105ef127c4ad19da@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 6lowpan@ietf.org, David Culler 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 Joe Polastre wrote: > What Kris was proposing achieves the goals of both (i) and (ii) > networks. The MIC has become a standard parameter for a variety of > different networking standards. By including it at layer 2, you're > promoting co-existence with other protocols of the same layer 2 > implementation while permitting flexibility in the network protocol > selection (pick from the alphabet soup of IPv6, SP100.11a, Zigbee Pro, > or Wireless HART). So lets take a concrete example: your favorite networking protocol (YFNP) and a over-the-air programming protocol (OTAP). One could argue that OTAP should not depend on YFNP in the case where you want to upgrade YFNP to YFNPng. Such incompatibility already exists with ZigBee 2006 and Pro. So for them to coexist in my network, I'll need to have two different keys, one for each protocol. When decoding a packet, I'll either need to try both keys and pick the one that works or rely on some common understanding of 802.15.4's key-identifier. The former is fairly inefficient. Maybe the argument is with appropriate hardware, we can efficiently apply a set of keys and have it return the one that worked, or none at all. Are there protocols operating on 802.15.4 that have scoped out more efficient ways of selecting the key to use? Or are you satisfied with the trial-and-error approach? > Quite frankly, LLC/802.2 has been ineffective at best in promoting > different protocols to coexist. Most major operating systems build > their own abstraction, or do implement 802.2 but bypass it for quite a > few instances. Linux, for example, implements case statements in its > IP implementation that changes the behavior of IP based on the type of > underlying link. Given that this is an IP-based standards group, the > only clear existing abstraction that has effectively decoupled the > lower layers and permitted coexistence is IP and not 802.2 or LLC. > That doesn't mean it should be ignored; however, it does not achieve > the goals that you outline in your email. While LLC/802.2 may have been ineffective at promoting different protocols to coexist in general, it does allow IPv4 and ARP to coexist by adapting EtherType values. Try running an IP box without one of these services. Maybe it would have been better to say that 802.15.4 lacks the upper-layer protocol type field of 802.3. Remember that 6lowpan is not about trying to run IPv6 on link-layers other than 802.15.4, so I wasn't trying to propose LLC as a useful abstraction to link layers. This of this discussion is probably best left to the IEEE. Just trying to shed some light on why NALP exists in the first place. -- Jonathan Hui jhui@archrock.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 04 02:15:43 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 1Hv5qx-0001fp-5e; Mon, 04 Jun 2007 02:15:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv5qw-0001ff-81 for 6lowpan@ietf.org; Mon, 04 Jun 2007 02:15:42 -0400 Received: from an-out-0708.google.com ([209.85.132.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv5qu-0001b4-TH for 6lowpan@ietf.org; Mon, 04 Jun 2007 02:15:42 -0400 Received: by an-out-0708.google.com with SMTP id c17so316051anc for <6lowpan@ietf.org>; Sun, 03 Jun 2007 23:15:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=NrRFoGRptVO5/q2YdQeDT86R7g0Ip2jG6jwrR/u5RDN5MSS7FO4AspMwUdQQBUYe9wDiSyXhm/RonCRUd2wnSGvNW5o03QEqFu1LfIdS60EK1al5QcQy1MoVF4Rb4DGmp2mUsKhGPmfWpogJ52wQ2GY/F/8/bYXwJlnDxgf00dQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=CUL3pOARnQRNKznq6oBJtS6Iy+mQW5cSRUSYEEEg06ZW2kfQTjm1UnV9pf8vD5wvm9RkRns0ApA8eNIXbpC+ocr0yqSYuFfttdMnKFi9HZBZYcTw6LJdaXtRZSsQi5TOFMNCSFYa1fPKg1LQimfQpB0t37rHev+f3iZwHXpIoLw= Received: by 10.100.254.10 with SMTP id b10mr2365470ani.1180937740379; Sun, 03 Jun 2007 23:15:40 -0700 (PDT) Received: by 10.100.11.16 with HTTP; Sun, 3 Jun 2007 23:15:40 -0700 (PDT) Message-ID: <1edd46e70706032315q3b173194g41890f81f4f88854@mail.gmail.com> Date: Sun, 3 Jun 2007 23:15:40 -0700 From: "Joe Polastre" To: 6lowpan@ietf.org Subject: Re: [6lowpan] Dispatch value bit pattern for 6lowPAN In-Reply-To: <1edd46e70706032314m6ace0007r8b6e42ed0f6186b7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3D8BC6C339A9894C9955EF58D3722D6591257C@dust-exch-02.dusthq.dust-inc.com> <46639A57.8060807@archrock.com> <1edd46e70706032223q445004b8j105ef127c4ad19da@mail.gmail.com> <4663AC66.9000409@archrock.com> <1edd46e70706032314m6ace0007r8b6e42ed0f6186b7@mail.gmail.com> X-Google-Sender-Auth: 25835e660f978589 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 > (YFNP) and a over-the-air programming protocol (OTAP). One could argue > that OTAP should not depend on YFNP in the case where you want to > upgrade YFNP to YFNPng. Such incompatibility already exists with ZigBee > 2006 and Pro. So for them to coexist in my network, I'll need to have > two different keys, one for each protocol. When decoding a packet, I'll > either need to try both keys and pick the one that works or rely on some > common understanding of 802.15.4's key-identifier. The former is fairly > inefficient. Maybe the argument is with appropriate hardware, we can > efficiently apply a set of keys and have it return the one that worked, > or none at all. Are there protocols operating on 802.15.4 that have > scoped out more efficient ways of selecting the key to use? Or are you > satisfied with the trial-and-error approach? The problem is that you're trying to cross layer boundaries and IEEE 802.15.4 was never intended to allow such usage. IEEE 802.15.4 specifies a link key--a key that can be used to validate traffic between two hosts at the data link level. What you are describing is network keying, which is beyond the scope of IEEE 802.15.4. YFNP, YFNPng, and OTAP can all specify their desired security scheme and keying approach (for example, OTAP may implement a network-wide keying scheme while YFNP is a multicast protocol that uses group keying). Either way, these are concerns above the data link layer, and we should not confuse security at the network layer with security at the data link layer. -Joe _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 04 02:48: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 1Hv6MC-0006L3-Qk; Mon, 04 Jun 2007 02:48:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv6MB-0006Ky-IG for 6lowpan@ietf.org; Mon, 04 Jun 2007 02:47:59 -0400 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv6MA-00065l-7d for 6lowpan@ietf.org; Mon, 04 Jun 2007 02:47:59 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id BB0EB16B0001; Sun, 3 Jun 2007 23:47:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.8 Received: from [127.0.0.1] (adsl-71-142-92-55.dsl.pltn13.pacbell.net [71.142.92.55]) by secure.archedrock.com (Postfix) with ESMTP id 23F2C16B0001; Sun, 3 Jun 2007 23:47:57 -0700 (PDT) Message-ID: <4663B598.1070203@archrock.com> Date: Sun, 03 Jun 2007 23:47:52 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Joe Polastre Subject: Re: [6lowpan] Dispatch value bit pattern for 6lowPAN References: <3D8BC6C339A9894C9955EF58D3722D6591257C@dust-exch-02.dusthq.dust-inc.com> <46639A57.8060807@archrock.com> <1edd46e70706032223q445004b8j105ef127c4ad19da@mail.gmail.com> <4663AC66.9000409@archrock.com> <1edd46e70706032314m6ace0007r8b6e42ed0f6186b7@mail.gmail.com> <1edd46e70706032315q3b173194g41890f81f4f88854@mail.gmail.com> In-Reply-To: <1edd46e70706032315q3b173194g41890f81f4f88854@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 6lowpan@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 > The problem is that you're trying to cross layer boundaries and IEEE > 802.15.4 was never intended to allow such usage. Which brings us back to the two kinds of coexistence. In one case, we have coexistance of 6lowpan, zigbee, wireless hart. This is easily solvable with Kris' proposal. In the other, we have coexistance of YFNP and OTAP. Which 6lowpan has provided provisions for with the use of NALP. > IEEE 802.15.4 specifies a link key--a key that can be used to validate > traffic between two hosts at the data link level. What you are > describing is network keying, which is beyond the scope of IEEE > 802.15.4. YFNP, YFNPng, and OTAP can all specify their desired > security scheme and keying approach (for example, OTAP may implement a > network-wide keying scheme while YFNP is a multicast protocol that > uses group keying). Either way, these are concerns above the data > link layer, and we should not confuse security at the network layer > with security at the data link layer. There's no confusion here. Kris' argument was based on the fact that an 802.15.4 4-byte MIC provide better integrity checks than 16-bit CRCs while also providing a convenient mechanism for segmenting a collection of nodes. With link-layer MICs in place, then a simple and now plausible solution is to have some bits in the payload define what upper-layer protocol is running. Having a 6lowpan-specific key still works since NALP protocols are necessarily aware of 6lowpan, since they conform to its protocol-identifier mechanism. Another way is, as you suggest, to provide network-level keying for segmentation, which then gets back to the "how do i determine what key to use" problem. -- Jonathan Hui jhui@archrock.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 04 23:03:37 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 1HvPKY-0003NX-J4; Mon, 04 Jun 2007 23:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvPKY-0003NO-2Y; Mon, 04 Jun 2007 23:03:34 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvPKW-000484-GR; Mon, 04 Jun 2007 23:03:34 -0400 Received: from [127.0.0.1] (mpls.saloits.com [216.243.132.62]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id l553347s091193; Mon, 4 Jun 2007 22:03:24 -0500 (CDT) (envelope-from salo@saloits.com) Message-ID: <4664D24E.2000803@saloits.com> Date: Mon, 04 Jun 2007 22:02:38 -0500 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: rsn@ietf.org, 6lowpan@ietf.org References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> <46632986.3000401@saloits.com> <46632FB9.6080705@cisco.com> In-Reply-To: <46632FB9.6080705@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Subject: [6lowpan] Re: [RSN] Update 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 Mark Townsley wrote: >> And finally, to do the job well, this group must look at more >> than just routing issues (e.g., neighbor discovery and management >> in low-power wireless networks). We might consider: >> > This part should be part of the 6lowpan recharter. The idea amongst the > ADs has been to split off the routing portion of the work on low-power > networks to the routing area, and continue forward with work on ND, > bootstrapping, etc. within the int-area. I strongly recommend that serious consideration be given to creating a single working group that is responsible for both the routing and the non-routing aspects of low-power wireless networks. While it is important to apply the IETF's routing expertise to these issues, I believe that, in this arena, there is also a need for close coordination between the routing solutions and the non-routing solutions. o I believe that the IETF's low-power wireless network activity (both the routing and the non-routing portions) will benefit from (perhaps even require) outside experts and expertise. (i.e., people who don't traditionally attend IETF working group meetings). I also believe that it will be much easier for these people to attend working group meetings if there is a single working group, rather than two. Yes, we could have two working groups and promise that they will always meet on the same day. But, given the complexities of scheduling working group meetings, it seems much easier and much more reliable to simply have a single working group. Groups I would like to see attend include: - Wireless Sensor Network (WSN) Research Commmunity - The WSN research community has considerable domain expertise that would benefit the IETF. Furthermore, this community is developing routing protocols adapted to the unique needs of WSNs that are radically different than anything the IETF is thinking about (e.g., protocols that propagate _only_ a default route, and enable nodes to route packets to _only_ to an exit router or to immediately adjacent nodes; and protocols that enable at least some nodes to sleep most of the time). - Home Automation and Industrial Automation Vendors - These groups have strong ideas about their requirements and have developed some initial solutions. - Standards Bodies and Industry Consortiums - It is possible that some of these groups (e.g., ZigBee Alliance, IEEE etc.) might choose to send some representatives. o I believe that low-power wireless networks are, in many respects, radically different than the networks with which the IETF has experience. As a result, both those working on the routing and the non-routing aspects of this problem will need to collectively develop a detailed understanding of the of the unique characteristics of these environments. Some of these unique characteristics have strong implications for the routing solutions (e.g., some nodes may sleep much of the time; some nodes may be severely energy-constrained, while other nodes may be mains-powered; nodes may have [at least in academic discussions] thousands of neighbors]). It would be useful for the routing and non-routing participants to develop this domain expertise jointly, rather than have after-the-fact discussions of the form: But, you didn't tell us about _that_ requirement... o Finally, I believe that there must be much closer collaboration between the routing and the non-routing solutions than is common in the IETF. For example, some proposed WSN routing protocols assume that clocks are reasonably well synchronized (no, they don't run NTP). Some system-level design issues should be decided in close coordination with the routing protocol design, such as: - Should some nodes, such as power-rich or gateway nodes, act as proxies (for some functions) for power constrained node? - Should a link/subnet use both MAC addresses and network-addresses, or should only a single set of addresses be used for both purposes? - Should full IP (particularly IPv6) addresses _ever_ be transmitted over a low-power wireless link (except to request translation to a short, link-local address)? Having said all that, I do think that it is important for a single (or maybe "joint") low-power wireless networking working group to be associated with both the Internet Area and the Routing Area. Perhaps, it is possible for this working group to be associated with, and have oversight from, both Areas. Thoughts on whether this new working group should result from a rechartering of the 6lowpan working group, or whether a fresh start would be beneficial, is the topic of some future pontification^H^H^H^H^H^H e-mail. More unsolicited opinions from, -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 14 22:07:21 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 1Hz1Dc-0005on-QV; Thu, 14 Jun 2007 22:07:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz1Da-0005mp-A5 for 6lowpan@lists.ietf.org; Thu, 14 Jun 2007 22:07:18 -0400 Received: from mail.ajou.ac.kr ([202.30.0.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hz1DX-0002ro-Hh for 6lowpan@lists.ietf.org; Thu, 14 Jun 2007 22:07:18 -0400 Received: from ajou.ac.kr (127.0.0.1) by mail.ajou.ac.kr with ESMTP imoxion SensMail SmtpServer 5.0 id <4671f4c93fe526d1e3ae4703> for <6lowpan@lists.ietf.org> from ; Fri, 15 Jun 2007 11:07:15 +0900 Message-ID: <4671f65c3fec@imoxion.com> Date: Fri, 15 Jun 2007 11:07:15 +0900 (KST) From: Zeeshan Hameed Mir To: rsn@ietf.org, tccc@cs.columbia.edu, 6lowpan@lists.ietf.org MIME-Version: 1.0 X-Priority: 3 X-Spam-Score: 1.3 (+) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: Subject: [6lowpan] USN 2007 Extended Deadline to June 15 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="===============0555490796==" Errors-To: 6lowpan-bounces@ietf.org --===============0555490796== Content-Type: multipart/alternative; boundary="----=_Part_364600_10243915.1181873235403" ------=_Part_364600_10243915.1181873235403 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 IA0KW1BsZWFzZSBhY2NlcHQgb3VyIGFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2ZSBtdWx0aXBsZSBj b3BpZXMgb2YgdGhpcyBDRlBdIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tIA0KQ0FMTCBGT1IgUEFQRVJTIGZvciBVU04gMjAwNyANCg0KVGhl IDNyZCBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIFJGSUQgYW5kIFViaXF1aXRvdXMgU2Vuc29y IE5ldHdvcmtzIChVU04pIA0KDQpodHRwOi8vdW5zLmFqb3UuYWMua3IvfnVzbjIwMDcvLCBEZWNl bWJlciAxNy0yMCwgMjAwNywgVGFpcGVpLCBUYWl3YW4pIA0KDQpUbyBiZSBoZWxkIGluIGNvbmp1 bmN0aW9uIHdpdGggRVVDIDIwMDcgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tIA0KDQoNCkltcG9ydGFudCBEYXRlczogDQoNCiogU3VibWlzc2lv biBEdWU6IEp1bmUgMTUsIDIwMDcgKGV4dGVuZGVkIGRlYWRsaW5lKSANCg0KKiBBY2NlcHRhbmNl IG5vdGlmaWNhdGlvbjogQXVndXN0IDYsIDIwMDcgDQoNCiogQ2FtZXJhLXJlYWR5IGR1ZTogU2Vw dGVtYmVyIDQsIDIwMDcgDQoNCiAgDQpBYm91dCB0aGUgd29ya3Nob3A6IA0KDQpUaGUgcHVycG9z ZSBvZiBVU04gMjAwNyBpcyB0byBlc3RhYmxpc2ggYSBkaXNjdXNzaW9uIGZyYW1ld29yayBvbiBh bGwgdGhlIGNoYWxsZW5nZXMgcmFpc2VkIGZyb20gdGhlIGV2b2x1dGlvbiBvZiB0aGUgVWJpcXVp dG91cyBTZW5zb3IgTmV0d29ya3MgYW5kIFJGSUQgdGVjaG5vbG9naWVzLiBBcyBhIHVuaXF1ZSBv cHBvcnR1bml0eSB0byBvYnRhaW4gYW4gaW5zaWdodCBvbiB0aGUgbGVhZGluZyB0ZWNobm9sb2dp ZXMgb2YgdGhlIG5leHQgcGVydmFzaXZlIGVyYSwgVVNOIDIwMDcgd2FudHMgdG8gaW52aXRlIHJl c2VhcmNoZXJzIHRvIHByZXNlbnQgYW5kIGRpc2N1c3MgdGhlaXIgaWRlYXMuIA0KICANCg0KVG9w aWNzIG9mIHRoaXMgd29ya3Nob3AgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0bzogDQoN CqGkICAgICAgICAgUkZJRCBTeXN0ZW1zIGFuZCBBcmNoaXRlY3R1cmUgDQoNCqGkICAgICAgICAg UkZJRCBNaWRkbGV3YXJlIERlc2lnbiANCg0KoaQgICAgICAgICBBbnRpLWNvbGxpc2lvbiBhbGdv cml0aG1zIA0KDQqhpCAgICAgICAgIE1vYmlsZSBSRklEIFN5c3RlbXMgYW5kIEFwcGxpY2F0aW9u cyANCg0KoaQgICAgICAgICBEYXRhIE1vZGVsaW5nIGFuZCBNYW5hZ2VtZW50IA0KDQqhpCAgICAg ICAgIEVtYmVkZGVkIFJGSUQtZW5hYmxlZCBEZXZpY2UgVGVjaG5vbG9neSANCg0KoaQgICAgICAg ICBTZW5zb3IgTmV0d29yayBBcmNoaXRlY3R1cmVzIGFuZCBQcm90b2NvbHMgDQoNCqGkICAgICAg ICAgTmV0d29yayBwcm90b2NvbHMsIGUuZy4sIE1BQyBhbmQgcm91dGluZyANCg0KoaQgICAgICAg ICBEaXN0cmlidXRlZCBBbGdvcml0aG1zLCBlLmcuLCBMb2NhbGl6YXRpb24gYW5kIFN5bmNocm9u aXphdGlvbiANCg0KoaQgICAgICAgICBDcm9zcyBMYXllciBhbmQgRW5lcmd5IEVmZmljaWVudCBE ZXNpZ24gDQoNCqGkICAgICAgICAgVVNOIE1pZGRsZXdhcmUgSXNzdWVzLCBlLmcuLCBPUyBhbmQg RGF0YWJhc2UgDQoNCqGkICAgICAgICAgQ29leGlzdGVuY2Ugb2YgUkZJRCAmIFVTTiANCg0KoaQg ICAgICAgICBRb1MgYW5kIFJlYWwtVGltZSBJc3N1ZXMgDQoNCqGkICAgICAgICAgU2VjdXJpdHkg YW5kIHByaXZhY3kgaXNzdWVzIA0KDQqhpCAgICAgICAgIE5ldHdvcmsgTWFuYWdlbWVudCBpbiBM YXJnZS1zY2FsZSBEZXBsb3ltZW50IA0KDQqhpCAgICAgICAgIENvZXhpc3RlbmNlIG9mIFJGSUQg JiBVU04gDQoNCqGkICAgICAgICAgTm92ZWwgUkZJRCBhbmQgVVNOIEFwcGxpY2F0aW9ucyANCiAg DQoNCldvcmtzaG9wIENoYWlycyANCi0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KDQpZb3VuZy1CYWUg S28sIEFqb3UgVW5pdmVyc2l0eSwgS29yZWEgDQoNCkthbmctV29uIExlZSwgSUJNIFQuSiBXYXRz b24gUmVzZWFyY2gsIFVTQSANCg0KICANCg0KU3RlZXJpbmcgQ29tbWl0dGVlIA0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSANCg0KSm9uZ3N1ayBDaGFlLCBFVFJJLCBLb3JlYSANCg0KU2V1bmctV2hh IFlvbywgQWpvdSBVbml2ZXJzaXR5LCBLb3JlYSANCg0KWXUtQ2hlZSBUc2VuZywgTmF0aW9uYWwg Q2hpYW8gVHVuZyBVbml2LiwgVGFpd2FuIA0KDQpEYWV5b3VuZyBLaW0sIEluZm9ybWF0aW9uIGFu ZCBDb21tdW5pY2F0aW9ucyBVbml2ZXJzaXR5LCBLb3JlYSANCg0KICANCg0KUHJvZ3JhbSBDb21t aXR0ZWUgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoNCkJ5dW5naHVuIFNvbmcsIEtFVEks IEtvcmVhIA0KDQpDaGFuc3UgWXUsIENsZXZlbGFuZCBTdGF0ZSBVbml2ZXJzaXR5LCBVU0EgDQoN CkNoaWgtWXVuZyBDaGFuZywgVGFta2FuZyBVbml2ZXJzaXR5LCBUYWl3YW4gDQoNCkRvbmctS3l1 biBLaW0sIEt5dW5ncG9vayBOYXRpb25hbCBVbml2ZXJzaXR5LCBLb3JlYSANCg0KSmFlLUh5dW4g S2ltLCBBam91IFVuaXZlcnNpdHksIEtvcmVhIA0KDQpKYXZpZXIgR29tZXosIE5hdGlvbmFsIFVu aXZlcnNpdHkgb2YgTWV4aWNvLCBNZXhpY28gDQoNCkthbmctV29uIExlZSwgSUJNIFQuSiBXYXRz b24gUmVzZWFyY2gsIFVTQSANCg0KS3VpIFd1LCBVbml2ZXJzaXR5IG9mIFZpY3RvcmlhLCBDYW5h ZGEgDQoNCkxpbmctSnloIENoZW4sIEluc3RpdHV0ZSBvZiBJbmZvcm1hdGlvbiBTY2llbmNlLCBU YWl3YW4gDQoNCk1pbmVvIFRha2FpLCBVQ0xBLCBVU0EgDQoNCk1pbmctSmVyIFRzYWksIE5hdGlv bmFsIFRzaW5nLUh1YSBVbml2LiwgVGFpd2FuIA0KDQpNaXNjaGEgRG9obGVyLCBGcmFuY2UgVGVs ZWNvbSwgRnJhbmNlIA0KDQpNb2hhbWVkIFlvdW5pcywgVW5pdmVyc2l0eSBvZiBNYXJ5bGFuZCwg VVNBIA0KDQpPemd1ciBFcmNldGluLCBTYWJhbmNpIFVuaXZlcnNpdHksIFR1cmtleSANCg0KU2Fh ZCBCaWF6LCBBdWJ1cm4gVW5pdmVyc2l0eSwgVVNBIA0KDQpUYWVreXVuZyBLd29uLCBTZW91bCBO YXRpb25hbCBVbml2ZXJzaXR5LCBLb3JlYSANCg0KVGFlLUppbiBMZWUsIFN1bmdreXVua3dhbiBV bml2ZXJzaXR5LCBLb3JlYSANCg0KWXVoLVNoeWFuIENoZW4sIE5hdGlvbmFsIENodW5nIENoZW5n IFVuaXZlcnNpdHksIFRhaXdhbiANCg0KV2VpIExvdSwgSG9uZyBLb25nIFBvbHl0ZWNobmljIFVu aXZlcnNpdHksIENoaW5hIA0KDQpXZW4tQ2hpaCBQZW5nLCBOYXRpb25hbCBDaGlhbyBUdW5nIFVu aXYuLCBUYWl3YW4gDQoNCldvbmp1biBMZWUsIEtvcmVhIFVuaXZlcnNpdHksIEtvcmVhIA0KDQot LS0tLQ0KDQpaZWVzaGFuIEhhbWVlZCBNaXIsDQpBam91IFVuaXZlcnNpdHksIFNvdXRoIEtvcmVh DQoNCg== ------=_Part_364600_10243915.1181873235403 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlIHR5cGU9J3RleHQvY3NzJz4gUCB7cGFkZGluZzowcHg7IG1hcmdp bjoycHg7IGJvcmRlcjowcHg7Zm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6J2FyaWFsJzt9ICBi b2R5IHtwYWRkaW5nOjVweDsgbWFyZ2luOjBweDsgYm9yZGVyOjBweDtmb250LXNpemU6MTNweDtm b250LWZhbWlseTonYXJpYWwnO30gPC9zdHlsZT48L2hlYWQ+PGJvZHk+PHRhYmxlIHdpZHRoPTk5 JSBhbGlnbj1jZW50ZXIgaGVpZ2h0PScxMDAnPjx0ciB2YWxpZ249dG9wPjx0ZD48Zm9udCBzaXpl PTI+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRk9OVD4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPltQbGVhc2UgYWNjZXB0 IG91ciBhcG9sb2dpZXMgaWYgeW91IHJlY2VpdmUgbXVsdGlwbGUgY29waWVzIG9mIHRoaXMgQ0ZQ XTwvU1BBTj48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMt c2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IHNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48L1NQ QU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5DQUxMIEZPUiBQQVBFUlMg Zm9yIFVTTiAyMDA3PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BB Tj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPlRoZSAzcmQgSW50ZXJuYXRp b25hbCBXb3Jrc2hvcCBvbiBSRklEIGFuZCBVYmlxdWl0b3VzIFNlbnNvciBOZXR3b3JrcyAoVVNO KSA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFj ZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5odHRwOi8vdW5zLmFqb3UuYWMua3IvfnVzbjIw MDcvLCBEZWNlbWJlciAxNy0yMCwgMjAwNywgVGFpcGVpLCBUYWl3YW4pPC9TUEFOPjwvRk9OVD48 U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IHNhbnMtc2VyaWYiPlRvIGJlIGhlbGQgaW4gY29uanVuY3Rpb24gd2l0aCBFVUMgMjAwNzwvU1BB Tj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2Vy aWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IHNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PEJS PjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkltcG9ydGFudCBE YXRlczo8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05U IGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+KiBTdWJtaXNzaW9uIER1ZTogSnVuZSAx NSwgMjAwNyAoZXh0ZW5kZWQgZGVhZGxpbmUpPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVT PiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9 RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPiog QWNjZXB0YW5jZSBub3RpZmljYXRpb246IEF1Z3VzdCA2LCAyMDA3IDwvU1BBTj48L0ZPTlQ+PFNQ QU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNh bnMtc2VyaWYiPiogQ2FtZXJhLXJlYWR5IGR1ZTogU2VwdGVtYmVyIDQsIDIwMDcgPC9TUEFOPjwv Rk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJp ZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogc2Fucy1zZXJpZiI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8 QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+QWJvdXQgdGhl IHdvcmtzaG9wOjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+ PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5UaGUgcHVycG9zZSBvZiBVU04g MjAwNyBpcyB0byBlc3RhYmxpc2ggYSBkaXNjdXNzaW9uIGZyYW1ld29yayBvbiBhbGwgdGhlIGNo YWxsZW5nZXMgcmFpc2VkIGZyb20gdGhlIGV2b2x1dGlvbiBvZiB0aGUgVWJpcXVpdG91cyBTZW5z b3IgTmV0d29ya3MgYW5kIFJGSUQgdGVjaG5vbG9naWVzLiBBcyBhIHVuaXF1ZSBvcHBvcnR1bml0 eSB0byBvYnRhaW4gYW4gaW5zaWdodCBvbiB0aGUgbGVhZGluZyB0ZWNobm9sb2dpZXMgb2YgdGhl IG5leHQgcGVydmFzaXZlIGVyYSwgVVNOIDIwMDcgd2FudHMgdG8gaW52aXRlIHJlc2VhcmNoZXJz IHRvIHByZXNlbnQgYW5kIGRpc2N1c3MgdGhlaXIgaWRlYXMuIDwvU1BBTj48L0ZPTlQ+PFNQQU4g bGFuZz1FTi1VUz48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4g bGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJp ZiI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48 Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPlRvcGljcyBvZiB0aGlzIHdvcmtz aG9wIGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG86IDwvU1BBTj48L0ZPTlQ+PFNQQU4g bGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMt c2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSRklEIFN5c3RlbXMgYW5kIEFy Y2hpdGVjdHVyZSA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+ PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgUkZJRCBNaWRkbGV3YXJlIERlc2lnbiA8L1NQQU4+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNl cmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQW50aS1jb2xsaXNpb24gYWxnb3Jp dGhtcyA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgTW9iaWxlIFJGSUQgU3lzdGVtcyBhbmQgQXBwbGljYXRpb25zIDwvU1BBTj48L0ZPTlQ+ PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRhIE1vZGVsaW5n IGFuZCBNYW5hZ2VtZW50IDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwv U1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBFbWJlZGRlZCBSRklELWVuYWJsZWQgRGV2aWNlIFRlY2hub2xvZ3kg PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFNlbnNvciBOZXR3b3JrIEFyY2hpdGVjdHVyZXMgYW5kIFByb3RvY29scyA8L1NQQU4+PC9GT05U PjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNp emU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTmV0d29yayBwcm90 b2NvbHMsIGUuZy4sIE1BQyBhbmQgcm91dGluZyA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4t VVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6h pCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGlzdHJpYnV0ZWQgQWxnb3JpdGhtcywgZS5n LiwgTG9jYWxpemF0aW9uIGFuZCBTeW5jaHJvbml6YXRpb24gPC9TUEFOPjwvRk9OVD48U1BBTiBs YW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1z ZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENyb3NzIExheWVyIGFuZCBFbmVy Z3kgRWZmaWNpZW50IERlc2lnbiA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxC Uj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVVNOIE1pZGRsZXdhcmUgSXNzdWVzLCBlLmcuLCBPUyBhbmQg RGF0YWJhc2UgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IENvZXhpc3RlbmNlIG9mIFJGSUQgJmFtcDsgVVNOIDwvU1BBTj48L0ZPTlQ+PFNQ QU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNh bnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBRb1MgYW5kIFJlYWwtVGlt ZSBJc3N1ZXMgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFNlY3VyaXR5IGFuZCBwcml2YWN5IGlzc3VlcyA8L1NQQU4+PC9GT05UPjxTUEFO IGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5z LXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTmV0d29yayBNYW5hZ2VtZW50 IGluIExhcmdlLXNjYWxlIERlcGxveW1lbnQgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVT PjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENvZXhpc3RlbmNlIG9mIFJGSUQgJmFtcDsgVVNO IDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNl PXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBOb3ZlbCBSRklEIGFuZCBVU04gQXBwbGljYXRpb25zIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFu Zz1FTi1VUz48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+ Jm5ic3A7PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9O VCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPldvcmtzaG9wIENoYWlyczwvU1BBTj48 L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYg c2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6IHNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tPC9TUEFOPjwvRk9OVD48U1BBTiBs YW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMt c2VyaWYiPllvdW5nLUJhZSBLbywgQWpvdSBVbml2ZXJzaXR5LCBLb3JlYSA8L1NQQU4+PC9GT05U PjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNp emU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBzYW5zLXNlcmlmIj5LYW5nLVdvbiBMZWUsIElCTSBULkogV2F0c29uIFJlc2VhcmNoLCBVU0E8 L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5n PUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2Vy aWYiPlN0ZWVyaW5nIENvbW1pdHRlZSA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJS PjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS08L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFO PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+Sm9uZ3N1ayBDaGFlLCBFVFJJ LCBLb3JlYTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZP TlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5TZXVuZy1XaGEgWW9vLCBBam91IFVu aXZlcnNpdHksIEtvcmVhPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwv U1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPll1LUNoZWUgVHNlbmcs IE5hdGlvbmFsIENoaWFvIFR1bmcgVW5pdi4sIFRhaXdhbjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFu Zz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNl cmlmIj5EYWV5b3VuZyBLaW0sIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBVbml2ZXJz aXR5LCBLb3JlYTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+ PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4mbmJzcDs8L1NQQU4+PC9GT05U PjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogc2Fucy1zZXJpZiI+UHJvZ3JhbSBDb21taXR0ZWU8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9 RU4tVVM+IDxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxC Uj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+Qnl1bmdo dW4gU29uZywgS0VUSSwgS29yZWE8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48 QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+Q2hhbnN1IFl1 LCBDbGV2ZWxhbmQgU3RhdGUgVW5pdmVyc2l0eSwgVVNBPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5n PUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2Vy aWYiPkNoaWgtWXVuZyBDaGFuZywgVGFta2FuZyBVbml2ZXJzaXR5LCBUYWl3YW48L1NQQU4+PC9G T05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJp ZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogc2Fucy1zZXJpZiI+RG9uZy1LeXVuIEtpbSwgS3l1bmdwb29rIE5hdGlvbmFsIFVuaXZl cnNpdHksIEtvcmVhPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BB Tj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkphZS1IeXVuIEtpbSwgQWpv dSBVbml2ZXJzaXR5LCBLb3JlYTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxC Uj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5KYXZpZXIgR29t ZXosIE5hdGlvbmFsIFVuaXZlcnNpdHkgb2YgTWV4aWNvLCBNZXhpY288L1NQQU4+PC9GT05UPjxT UEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXpl PTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog c2Fucy1zZXJpZiI+S2FuZy1Xb24gTGVlLCBJQk0gVC5KIFdhdHNvbiBSZXNlYXJjaCwgVVNBPC9T UEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkt1aSBXdSwgVW5pdmVyc2l0eSBvZiBWaWN0b3JpYSwg Q2FuYWRhPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9O VCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkxpbmctSnloIENoZW4sIEluc3RpdHV0 ZSBvZiBJbmZvcm1hdGlvbiBTY2llbmNlLCBUYWl3YW48L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9 RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4g bGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJp ZiI+TWluZW8gVGFrYWksIFVDTEEsIFVTQTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4g PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5NaW5n LUplciBUc2FpLCBOYXRpb25hbCBUc2luZy1IdWEgVW5pdi4sIFRhaXdhbjwvU1BBTj48L0ZPTlQ+ PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNp emU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBzYW5zLXNlcmlmIj5NaXNjaGEgRG9obGVyLCBGcmFuY2UgVGVsZWNvbSwgRnJhbmNlPC9TUEFO PjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMt c2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IHNhbnMtc2VyaWYiPk1vaGFtZWQgWW91bmlzLCBVbml2ZXJzaXR5IG9mIE1hcnls YW5kLCBVU0E8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+T3pndXIgRXJjZXRpbiwgU2FiYW5j aSBVbml2ZXJzaXR5LCBUdXJrZXk8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48 QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+U2FhZCBCaWF6 LCBBdWJ1cm4gVW5pdmVyc2l0eSwgVVNBPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8 QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4t VVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPlRhZWt5 dW5nIEt3b24sIFNlb3VsIE5hdGlvbmFsIFVuaXZlcnNpdHksIEtvcmVhPC9TUEFOPjwvRk9OVD48 U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IHNhbnMtc2VyaWYiPlRhZS1KaW4gTGVlLCBTdW5na3l1bmt3YW4gVW5pdmVyc2l0eSwgS29yZWE8 L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+WXVoLVNoeWFuIENoZW4sIE5hdGlvbmFsIENodW5n IENoZW5nIFVuaXZlcnNpdHksIFRhaXdhbjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4g PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5XZWkg TG91LCBIb25nIEtvbmcgUG9seXRlY2huaWMgVW5pdmVyc2l0eSwgQ2hpbmE8L1NQQU4+PC9GT05U PjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogc2Fucy1zZXJpZiI+V2VuLUNoaWggUGVuZywgTmF0aW9uYWwgQ2hpYW8gVHVuZyBVbml2Liwg VGFpd2FuPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9O VCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPldvbmp1biBMZWUsIEtvcmVhIFVuaXZl cnNpdHksIEtvcmVhPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PC9TUEFOPjwv UD4NCjxQPjxTUEFOIGxhbmc9RU4tVVM+LS0tLS08L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1F Ti1VUz48L1NQQU4+Jm5ic3A7PC9QPg0KPFA+PFNQQU4gbGFuZz1FTi1VUz5aZWVzaGFuIEhhbWVl ZCBNaXIsPC9TUEFOPjwvUD4NCjxQPjxTUEFOIGxhbmc9RU4tVVM+QWpvdSBVbml2ZXJzaXR5LCBT b3V0aCBLb3JlYTwvUD48L1NQQU4+PC9mb250PjwvdGQ+PC90cj48L3RhYmxlPjxicj4NCjxpbWcg aWQ9J21haWxleHAnIHdpZHRoPTAgaGVpZ2g9MCBib3JkZXI9MCBzcmM9J2h0dHA6Ly9tYWlsLmFq b3UuYWMua3I6ODAvbWFpbF9yZWNlaXB0X2NoZWNrLmpzcD91a2V5PTQ2NzFmNjViM2ZkNzA4MWRm ZDFhNjFlNCZ1c2VyaWQ9emhtaXImYWhvc3Q9YWpvdV9hY19rcic+PC9ib2R5PjwvaHRtbD4= ------=_Part_364600_10243915.1181873235403-- --===============0555490796== 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 --===============0555490796==-- From 6lowpan-bounces@ietf.org Mon Jun 18 18:12:18 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 1I0PSL-0007e6-OR; Mon, 18 Jun 2007 18:12:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0PSL-0007d2-3G for 6lowpan@ietf.org; Mon, 18 Jun 2007 18:12:17 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0PSJ-0000jX-PJ for 6lowpan@ietf.org; Mon, 18 Jun 2007 18:12:17 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BB5E867F6 for <6lowpan@ietf.org>; Tue, 19 Jun 2007 00:12:15 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 25426-05; Tue, 19 Jun 2007 00:12:11 +0200 (CEST) Received: from [10.1.1.3] (adsl-d65.84-47-102.t-com.sk [84.47.102.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTP id E93BE867EC; Tue, 19 Jun 2007 00:12:10 +0200 (CEST) Message-ID: <46770339.1070303@jacobs-university.de> Date: Tue, 19 Jun 2007 00:12:09 +0200 From: Matus Harvan User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: 6lowpan@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [6lowpan] compressed UDP Length field 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, the format draft version 13 says that if the UDP Length field is compressed then its value "is equal to the Payload Length from the IPv6 header, minus the length of any extension headers present between the IPv6 header and the UDP header." However, IMHO there cannot be any extension headers between the IPv6 header and the UDP header if the UDP header is HC2/HC_UDP compressed. The compressed UDP header can only be used if it follows immediately after the compressed IPv6 header. If there were any extension headers following the IPv6 header, the Next Header value (bits 5 and 6) in the HC1-compressed IPv6 header would not be 01 (UDP), the HC2 encoding (bit 7) could not be set, the UDP header could not be HC2/HC_UDP compressed at all and hence there would be no compressed UDP Length field. Is the wording in the draft a provisioning for the future where extension headers could possibly be included with a compressed UDP header or should it maybe mention that given the current format draft there cannot be any extension headers if the UDP header is compressed? Matus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGdwM443LQWDWf0QIRAqrGAJ9UTncaW+1Y1cONvI0HdG4EaakpOwCfbpZc 0g6rUVsqywJ+/Ua4vC91X9M= =r/uC -----END PGP SIGNATURE----- _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 18 19:43:47 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 1I0Qso-00025O-H5; Mon, 18 Jun 2007 19:43:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Qsn-00025J-5O for 6lowpan@ietf.org; Mon, 18 Jun 2007 19:43:41 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Qsm-0002qC-MG for 6lowpan@ietf.org; Mon, 18 Jun 2007 19:43:41 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B2D585A9E for <6lowpan@ietf.org>; Tue, 19 Jun 2007 01:43:40 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30994-03; Tue, 19 Jun 2007 01:43:35 +0200 (CEST) Received: from [10.1.1.3] (adsl-d65.84-47-102.t-com.sk [84.47.102.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTP id 57B9685A8F; Tue, 19 Jun 2007 01:43:35 +0200 (CEST) Message-ID: <467718A5.8040501@jacobs-university.de> Date: Tue, 19 Jun 2007 01:43:33 +0200 From: Matus Harvan User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: 6lowpan@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [6lowpan] fragment reassembly 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, my understanding of the the 6lowpan format draft version 13 is that it specifies different behavior for different types of overlapping fragments. If a fragment is received that overlaps another fragment and differs from the overlapped fragment in either size or datagram_offset then the already accumulated fragments shall be discarded. However, if the fragment were just a duplicate of another already received fragment, the already accumulated fragments do not need to be discarded. The problem with requiring a different behavior depending on whether it is just a duplicate or really a a different overlapping fragment is that to determine which type it is, the information about the size and datagram_offset of each already accumulated fragment has to be stored until the complete datagram is reassembled. While this may allow to detect a broken fragment sender, it requires additional complexity in the implementation as well as potentially more memory. An incorrectly reassembled datagram should be detected anyway, as ICMP,TCP and UDP all use a checksum with IPv6. Hence, I am not sure it is worth the effort. My understanding of the memory requirements is that one could use a bitmap or a linked list in order to keep track of already received fragments. Assuming a maximum datagram length of 1280 bytes after fragment reassembly and given the offset unit of 8-octet increments, one could use one bit for each 8 octets of the datagram. For a 1280 octets long datagram a 160 bit or 20 byte bitmap would be required to keep track of which parts of the datagram (fragments) have already been received. However, the information in the bitmap would not be sufficient to determine whether a received overlapping fragment is really a differing overlap or just a duplicate. With a linked list approach, one way is to store the length and datagram_length for each received fragment. These alone, without any pointer the the next element of the linked list, would be 2 bytes per fragment. Given 4 octets length of the first fragment header and 5 octets length of subsequent fragment headers, the complete datagram should fit into 15 fragments if maximum length 802.15.4 frames are used. Hence, at least 30 bytes would be needed to accumulate for the longest possible 6lowpan datagram assuming the best possible fragmentation. The linked list, on the other hand allows to determine whether a fragment is just a duplicate or really a differing overlap. The above discussion assumes the best possible fragmentation. If the sender sends smaller fragments then even more fragments may be needed, up to 1280/8 = 160 fragments. Clearly, keeping the size and datagram_offset for each fragment gets much worse in terms of required memory than a simple bitmap. Instead of a linked list one could also use an array and save the memory that would be used for the pointer to the next element of the linked list. However, one could then not take the list elements out of a common pool for reassembling several datagrams concurrently. In case of shorter datagrams, the linked list may actually require less memory as less fragments would be used. However, if an implementation should be able to cope with the largest allowed datagram size, then the memory would have to be available or reserved anyway and hence the discussion with the maximum datagram length is relevant. In short, the requirement to treat duplicated fragments differently from different overlapping fragments seems to hurt when one implements fragment reassembly and IMHO is not worth the effort. Would it be possible to reconsider this requirement and possibly leave it out in a future version of the format draft? Matus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGdxik43LQWDWf0QIRAuZeAKCwonx/c0ssp1v8vFMngksIAp/C5gCgnfRn 6QuYD7bXmyBjjU+eqZk684g= =PETX -----END PGP SIGNATURE----- _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 18 20:06: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 1I0RFJ-0003L5-C7; Mon, 18 Jun 2007 20:06:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0RFG-0003L0-CB for 6lowpan@ietf.org; Mon, 18 Jun 2007 20:06:54 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0RFF-0007Lp-1r for 6lowpan@ietf.org; Mon, 18 Jun 2007 20:06:54 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97D7986802; Tue, 19 Jun 2007 02:06:52 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 32387-08; Tue, 19 Jun 2007 02:06:48 +0200 (CEST) Received: from [10.1.1.3] (adsl-d65.84-47-102.t-com.sk [84.47.102.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTP id 461F3867D0; Tue, 19 Jun 2007 02:06:48 +0200 (CEST) Message-ID: <46771E16.1000502@jacobs-university.de> Date: Tue, 19 Jun 2007 02:06:46 +0200 From: Matus Harvan User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: 6lowpan@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Carsten Bormann Subject: [6lowpan] alignment of HC-compressed/inline-carried fields 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, my understanding of the 6lowpan format draft version 13 is that the Flow Label and UDP Source/Destination Ports would might not end on a byte-boundary. As a result, all further values carried after such a field with byte-unaligned end would possibly also get misaligned and bit shifting would be needed to actually read the correct values. From a discussion with Carsten Bormann I understood that this may not have been the intention when writing the format draft and some byte-alignment/padding could take place earlier than just at the very end after all the compressed/inline-carried fields. The advantage would be easier processing of and not having to bit-shift all subsequent fields. Could someone provide more insights? IMHO, a possible workaround would be to 1) pad the Flow Label with 4 bits of zeros. It usually is not used anyway and hence the possible additional wasted byte could be acceptable in a rather unlikely situation. 2) put the UDP Ports as the last UDP fields rather than the first UDP ones and hence possibly requiring bit-shifting unless both UDP ports are compressed. Should more fields follow after the UDP one in a future version of the draft, padding with zeros could be used after the UDP Ports. Matus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGdx4W43LQWDWf0QIRAqyUAKClOXgQ7+LIldgn5fsfpcExsCi9hACfemqh G9RkSpdqAV7zww6Ob9GwzLM= =pdRZ -----END PGP SIGNATURE----- _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 18 20:17:16 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 1I0RPI-0000RM-4K; Mon, 18 Jun 2007 20:17:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0RPG-0000Od-Mg for 6lowpan@ietf.org; Mon, 18 Jun 2007 20:17:14 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0RPE-0000yc-Cm for 6lowpan@ietf.org; Mon, 18 Jun 2007 20:17:14 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8D2686802 for <6lowpan@ietf.org>; Tue, 19 Jun 2007 02:17:11 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 00544-03; Tue, 19 Jun 2007 02:17:07 +0200 (CEST) Received: from [10.1.1.3] (adsl-d65.84-47-102.t-com.sk [84.47.102.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTP id 61BFC867D0; Tue, 19 Jun 2007 02:17:07 +0200 (CEST) Message-ID: <46772081.6040207@jacobs-university.de> Date: Tue, 19 Jun 2007 02:17:05 +0200 From: Matus Harvan User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: 6lowpan@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [6lowpan] ICMP error messages - ICMP payload 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, if an implementation would like to send back an ICMP error message in response to a 6lowpan HC1-compressed IPv6 packet, shall it include the HC1-compressed IPv6 header or its uncompressed version? I guess the uncompressed version would be better, but it might require more buffer space, fragments, energy for sending,... MAtus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGdyCB43LQWDWf0QIRApOeAJ99LfysxGLTS39L9p5JfgSDrEazQwCgio3E fX6q//+JuZcYxxoyJW/sCP0= =68qV -----END PGP SIGNATURE----- _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 19 04:39: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 1I0ZEu-0003Il-VN; Tue, 19 Jun 2007 04:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ZEu-0003IW-6J for 6lowpan@lists.ietf.org; Tue, 19 Jun 2007 04:39:04 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ZEt-0006xt-Sf for 6lowpan@lists.ietf.org; Tue, 19 Jun 2007 04:39:04 -0400 Received: by wr-out-0506.google.com with SMTP id 70so1140794wra for <6lowpan@lists.ietf.org>; Tue, 19 Jun 2007 01:39:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i7p4CknVPfiOuOa6chbT8PGvtyJqU6KplOb08lUOzwmWc8sF4d+uV9hbqnTlgV52trUov9kqIkEBP8XrlWpEUW3SyeU47jvaPMKGBBrdVVzAwr8s0jQRFRYh9bpLmGPLdmfwHPljQIAZP/kFb8oUGcwxFRQVrRG+NtikMPpWtJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VVq4FuNWWm88ehx+/M26/3MTOjTJmdrFO5mScMYgNaHwnQH4Be/kSY23IunZ3jUCZg0lgnpURxL8pXSlYgEb4WALEOzWodURDtwiwmHYTtu+hoVLOAD9GlA0+yi6xp4y/rJQ+NcEmcETMuI9/dpZUTx3GFETI0bMCqlx5qICTMc= Received: by 10.142.112.5 with SMTP id k5mr345245wfc.1182242342949; Tue, 19 Jun 2007 01:39:02 -0700 (PDT) Received: by 10.143.28.13 with HTTP; Tue, 19 Jun 2007 01:39:02 -0700 (PDT) Message-ID: <77f1dba80706190139t661114f9q90d1c3e2140652ce@mail.gmail.com> Date: Tue, 19 Jun 2007 17:39:02 +0900 From: "Eunsook \"Eunah\" Kim" To: "g_e_montenegro@yahoo.com" In-Reply-To: <675024.81537.qm@web81902.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <675024.81537.qm@web81902.mail.mud.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Geoff Mulligan , 6lowpan@lists.ietf.org, rsn@ietf.org Subject: [6lowpan] Re: [RSN] The need for RSN 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 My 2 cents are in line; > The slide (see the pdf above) is pretty clear about the scope of the "mesh > routing" item: in 6lowpan we are not chartered > to develop a new routing protocol (as in the algorithm, or the engine to > generate routing tables). We have something > that looks like consensus (just need the chairs to declare it so) on > *adapting* routing protocols developed > elsewhere. 6lowpan cannot develop protocols cuz it's not in the routing > area. > /snip/ In my understanding, we had some concerns to work routing solutions at 6lowpan, as you said it's not in the routing area. However, it doesn't mean that 6lowpan doesn't need to consider routing related issues for 6lowpan. IMHO, to make a solution and to handle routing related issues are different. If RSN successfully stages in the IETF, surely, RSN would be a good place to discuss routing issues for sensor networks. However, as you said below, for 6lowpan, sub-IP operations for multi-hop delivery should be considered, as RSN considers L3 routing. In my understanding, 6lowpan can be one of the applications for RSN. One way to consider 6lowpan routing issues is to put 6lowpan specific mesh-under routing requirements to RSN, as RSN is now gathering various requirements based on different applications. 6lowpan can discuss its own requirements with RSN, or input the requirements to RSN. -eunsook > As I understand it, RSN operates at layer 3, and it is arguing that there is > room for another multi-hop routing WG in the > routing area. Perhaps MANET can't really satisfy requirements for wireless > sensors. Whether this is solved by > integrating the RSN charter/deliverables into a re-chartered MANET, or by > starting a new WG, > from 6lowpan's point of view, 6lowpan can benefit from the resultant > protocols. > Of course, adaptation from layer 3 to sub-IP operation will be required, > along the lines of the > existing independent submissions in 6lowpan. > My 2 motes (hopefully one day those will cost 1 cent each...) > > -gabriel > > > ----- Original Message ---- > From: Dominik Kaspar > To: Geoff Mulligan > Cc: rsn@ietf.org > Sent: Sunday, June 10, 2007 9:17:11 PM > Subject: Re: [RSN] The need for RSN > > Geoff, > > As far as I know, there has not been any consensus yet to what is in > the scope of 6lowpan and what is not. But concering the RSN/R2LN > efforts, it would be favorable to find consensus as soon as possible, > so that it's clear where to dedicate new work to. > > Dominik > > On 6/8/07, Geoff Mulligan wrote: > > I would like to reiterate that I think that the work RSN group has > > suggested taking on is very important to my working group - 6lowpan. > > > > Our working group is looking to recharter and the scope of the work will > > be focused on issues related to interoperability for 6lowpan networks. > > This include things like MIC identifiers, alternative mesh headers, > > security, ... > > > > What is not in the scope is routing. I think the RSN concept is > > important in that the devices we are anticipating have significant > > constraints (power, memory, processing) and as such the current set of > > protocols and development is probably not appropriate for these types of > > devices. > > > > geoff > > > > > > > > _______________________________________________ > > RSN mailing list > > RSN@ietf.org > > https://www1.ietf.org/mailman/listinfo/rsn > > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > > > _______________________________________________ > 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 Jun 19 18:03:04 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 1I0lmt-0006OJ-GK; Tue, 19 Jun 2007 18:02:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lmr-0006O1-UU for 6lowpan@lists.ietf.org; Tue, 19 Jun 2007 18:02:57 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lmr-0001k5-Fd for 6lowpan@lists.ietf.org; Tue, 19 Jun 2007 18:02:57 -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 l5JM2stX000508 for <6lowpan@lists.ietf.org>; Tue, 19 Jun 2007 16:02:56 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: multipart/mixed; boundary="=-yTYnbJHe9Y+Vby1AO3t5" Date: Tue, 19 Jun 2007 16:02:51 -0600 Message-Id: <1182290571.6218.29.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Subject: [6lowpan] Rechartering consensus... 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 --=-yTYnbJHe9Y+Vby1AO3t5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by grab.coslabs.com id l5JM2stX000508 6LoWPAN group, It would appear that we have consensus on the work items for the working group rechartering - the following 5 topics have been relatively unchanged for months. As I have been working with folks that are implementing 6LoWPAN and from some of the messages on the list I have realized that we should probably be focused on those topics that are necessary to resolve for interoperability between implementations. Some of the 5 items here are targeted to this and some of the topics mentioned on the list, such as a standard/defined MIC could fall under one of the topics. - =E2=80=9C6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations=E2=80=9D - =E2=80=9CProblem Statement for Stateful Header Compression in 6lowpans=E2= =80=9D - =E2=80=9CRecommendations for 6lowpan Applications=E2=80=9D - =E2=80=9C6lowpan Mesh Routing=E2=80=9D - =E2=80=9C6lowpan Security Analysis=E2=80=9D I have attached a proposed new charter for the working group. geoff --=-yTYnbJHe9Y+Vby1AO3t5 Content-Disposition: attachment; filename=recharter.txt Content-Type: text/plain; name=recharter.txt; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by grab.coslabs.com id l5JM2stX000508 Background/Introduction: Well-established fields such as control networks, and burgeoning ones such as "sensor" (or transducer) networks, are increasingly being based on wireless technologies. Most (but certainly not all) of these nodes are amongst the most constrained that have ever been networked wirelessly. Extreme low power (such that they will run potentially for years on batteries) and extreme low cost (total device cost in single digit dollars, and riding Moore's law to continuously reduce that price point) are seen as essential enablers towards their deployment in networks with the following characteristics:=20 * Significantly more devices than current networks * Severely limited code and ram space (e.g., highly desirable to fit the required code--MAC, IP and anything else needed to execute the embedded application-- in, for example, 32K of flash memory, using 8-bit microprocessors) * Unobtrusive but very different user interface for configuration (e.g., using gestures or interactions involving the physical world) * Robustness and simplicity in routing or network fabric A chief component of these devices is wireless communication technology. In particular, the IEEE 802.15.4 standard is very promising for the lower (physical and link) layers. As for higher layer functions, there is considerable interest from non-IETF groups in using IP technology. The working group is expected to coordinate and interact with such groups. The working group has completed a problem statement/requirements RFC and and adaptation layer (IPv6 over 802.15.4) RFC. The working group has as its main objective to complete those topics and areas necessary for successful implmentation interoperability. The required work includes items in the following (incomplete) list: * Addressing schemes and address management * Network management * Routing in dynamically adaptive topologies * Security, including set-up and maintenance * Application programming interface * Discovery (of devices, of services, etc) * Implementation considerations Whereas at least some of the above items are within the purview of the IETF, at this point it is not clear that all of them are. Accordingly, the 6LoWPAN working group will address a reduced, more focused set of objectives. Scope of 6lowpan: 1. Produce =E2=80=9C6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizat= ions=E2=80=9D to define the required optimizations to make IPv6 ND applicable in 6lowpans, given the fact that IPv6 ND is too expensive for the devices of 6lowpan and requires multicast. This document will define how to bootstrap a 6lowpan network and explore ND optimizations such as reusing the 802.15.4 network structure (use the coordinators), and obviate multicast by having devices talk to coordinators without creating a single point-of-failure, and changing the IPv6 ND multicast semantics. This document will be a proposed standard. 2. Produce =E2=80=9CProblem Statement for Stateful Header Compression i= n 6lowpans=E2=80=9D to document the problem of using stateful header compre= ssion (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of stateless header compression given the assumption that stateful header compression may be too complex. This document will determine if the assumption is correct and will be an informational document. 3. Produce =E2=80=9CRecommendations for 6lowpan Applications=E2=80=9D t= o define a set of recommendations of protocols to use for applications. The recommendations will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be an informational document. 4. Produce =E2=80=9C6lowpan Mesh Routing=E2=80=9D to evaluate different= mesh routing protocols for use within 6lowpans. While most routing protocols are defined above the IP layer, 6lowpan requires a mesh routing protocol below the IP layer. =E2=80=9C6lowpan Mesh Routing=E2=80=9D may be several= proposed standard documents. 5. Produce =E2=80=9C6lowpan Security Analysis=E2=80=9D to define the th= reat model of 6lowpans and to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be an informational document. The working group will reuse existing specifications whenever reasonable and possible. The working group will also serve as a venue for ongoing discussions on other topics related to the more complete list outlined above. Additional related milestones may be added in the future via a rechartering operation. Note: As may be obvious from its official name above, this particular working group will not work on IPv4 over IEEE 802.15.4 specifications. Given the limitations of the target devices, dual-stack deployments are not practical. Because of its higher potential for header compression, its support for the huge number of devices expected and of cleanly built-in features such as address autoconfiguration, IPv6 is the exclusive focus of the working group. --=-yTYnbJHe9Y+Vby1AO3t5 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 --=-yTYnbJHe9Y+Vby1AO3t5-- From 6lowpan-bounces@ietf.org Tue Jun 19 20:58: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 1I0oWQ-0000e2-CC; Tue, 19 Jun 2007 20:58:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0oWP-0000dq-9k for 6lowpan@lists.ietf.org; Tue, 19 Jun 2007 20:58:09 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0oWO-0003uk-3b for 6lowpan@lists.ietf.org; Tue, 19 Jun 2007 20:58:09 -0400 Received: by wr-out-0506.google.com with SMTP id 76so23451wra for <6lowpan@lists.ietf.org>; Tue, 19 Jun 2007 17:58:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aHgbgr7nZ0+yt5SP8ZfI3Hj3rI+mG0A1HTMKsqA2FVex+bwsSQkFFZDezDOZW1moMAGa8jLDII7OVLogrZMNYUdJcX7XJSMH71XDHO7iw8e3Vf5VsLGKQROb9+vf43iRMv7j6tJIkfKkA+uocMQBn8ghspSCYHWsy9Xs+GLqVQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=upwROhuNgQj7+uVG8L+1eDnsZ8CA6IA40l/0y4RhfA8ajwtqAue6YzHra3qlVhxmSW0Do1qhZZVQBPtz0W2DTD2jofWWXvxQnIF3eQSqyPZO+8LRHYbtPLZvYWfoQ9fdhTc42NCBFf3aQQfqCuQPkf2JNA/E2N2GsE9RB8GCRZA= Received: by 10.142.107.1 with SMTP id f1mr2205wfc.1182301087394; Tue, 19 Jun 2007 17:58:07 -0700 (PDT) Received: by 10.143.28.13 with HTTP; Tue, 19 Jun 2007 17:58:07 -0700 (PDT) Message-ID: <77f1dba80706191758k39da5774r34051ab22f295f64@mail.gmail.com> Date: Wed, 20 Jun 2007 09:58:07 +0900 From: "Eunsook \"Eunah\" Kim" To: "Geoff Mulligan" In-Reply-To: <1182290840.6218.32.camel@dellx1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <675024.81537.qm@web81902.mail.mud.yahoo.com> <77f1dba80706190139t661114f9q90d1c3e2140652ce@mail.gmail.com> <1182290840.6218.32.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 6lowpan@lists.ietf.org, rsn@ietf.org, "g_e_montenegro@yahoo.com" Subject: [6lowpan] Re: [RSN] The need for RSN 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 Geoff, I'm glad that it seems like we are talking in the same language. :) -eunsook On 6/20/07, Geoff Mulligan wrote: > It was my understanding that while 6lowpan may consider "mesh under" > alternatives (layer 2 routing), it would rely upon a group like RSN to > deal with "route over" (layer 3 routing) and that 6lowpan would provide > requirements to RSN. > > geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 19 21:28: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 1I0ozV-00077N-Ff; Tue, 19 Jun 2007 21:28:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ozT-00076R-Ur for 6lowpan@lists.ietf.org; Tue, 19 Jun 2007 21:28:11 -0400 Received: from an-out-0708.google.com ([209.85.132.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ozR-0006wF-L8 for 6lowpan@lists.ietf.org; Tue, 19 Jun 2007 21:28:11 -0400 Received: by an-out-0708.google.com with SMTP id d31so454020and for <6lowpan@lists.ietf.org>; Tue, 19 Jun 2007 18:28:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f2X7cKaK/jaVNEmkSrN+B1eYC2GsbXAsqKYRZfeLKTQMX8lDxWHHDxn8pfbWG2J3ve3xIEvh3iZjgvYhE2AQVOWTuR7NlCHTpNTTCGlMwbUPF+DGblAyLuEuz1y3tLKoepTymoLkCt8904zwSwDPr6yq6eTAlzOWVbXO61clQl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GudHralP3fsVB+EuEfhFy7l5kRrCOkJQtaRVr1rR+6SiQhb63p70feRAT8FVun9bDhKeXZQYA5tb1aFZsn8BvcIDdjP0as+e+vTyQ2b9uao4ZYdilGAzDa2k/8dWCYH9UZU41GIWa+VNdvW5/FBsQAZvsky/mIYRseROICeTNPs= Received: by 10.143.16.9 with SMTP id t9mr2734wfi.1182302888882; Tue, 19 Jun 2007 18:28:08 -0700 (PDT) Received: by 10.143.28.13 with HTTP; Tue, 19 Jun 2007 18:28:08 -0700 (PDT) Message-ID: <77f1dba80706191828k278e2caej2d6631d8ca513961@mail.gmail.com> Date: Wed, 20 Jun 2007 10:28:08 +0900 From: "Eunsook \"Eunah\" Kim" To: "Geoff Mulligan" Subject: Re: [6lowpan] Rechartering consensus... In-Reply-To: <1182290571.6218.29.camel@dellx1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1182290571.6218.29.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 6lowpan <6lowpan@lists.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 Geoff, It's nice to see the announcement. (You said with the WG hat on, right? ;P) It must be a good start to re-boost 6lowpan work. I'd like to take this opportunity to announce that our new draft on "Design and Application Spaces for 6LoWPANs" has recently become available in the IETF depository. http://tools.ietf.org/wg/6lowpan/draft-ekim-6lowpan-scenarios-00.txt Currently, we start to investigate potential application scenarios and example use cases for 6lowpan. We need to add more details such as discovery, transport, etc. Hopefully, this draft can be a good start point to discuss 6lowpan applications. Please have a look at it. We appreciate your feedback and comments. - eunsook On 6/20/07, Geoff Mulligan wrote: > 6LoWPAN group, > It would appear that we have consensus on the work items for the > working group rechartering - the following 5 topics have been relatively > unchanged for months. > > As I have been working with folks that are implementing 6LoWPAN and from > some of the messages on the list I have realized that we should probably > be focused on those topics that are necessary to resolve for > interoperability between implementations. Some of the 5 items here are > targeted to this and some of the topics mentioned on the list, such as a > standard/defined MIC could fall under one of the topics. > > - "6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations" > - "Problem Statement for Stateful Header Compression in 6lowpans" > - "Recommendations for 6lowpan Applications" > - "6lowpan Mesh Routing" > - "6lowpan Security Analysis" > > I have attached a proposed new charter for the working group. > > geoff > > > > _______________________________________________ > 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 Jun 20 10:03:47 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 1I10mb-0004sE-V7; Wed, 20 Jun 2007 10:03:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lrC-000262-58; Tue, 19 Jun 2007 18:07:26 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lrB-0002Pf-La; Tue, 19 Jun 2007 18:07:26 -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 l5JM7NHk000528; Tue, 19 Jun 2007 16:07:24 -0600 (MDT) From: Geoff Mulligan To: "Eunsook \"Eunah\" Kim" In-Reply-To: <77f1dba80706190139t661114f9q90d1c3e2140652ce@mail.gmail.com> References: <675024.81537.qm@web81902.mail.mud.yahoo.com> <77f1dba80706190139t661114f9q90d1c3e2140652ce@mail.gmail.com> Content-Type: text/plain Date: Tue, 19 Jun 2007 16:07:20 -0600 Message-Id: <1182290840.6218.32.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e X-Mailman-Approved-At: Wed, 20 Jun 2007 10:03:39 -0400 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org, "g_e_montenegro@yahoo.com" Subject: [6lowpan] Re: [RSN] The need for RSN 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 It was my understanding that while 6lowpan may consider "mesh under" alternatives (layer 2 routing), it would rely upon a group like RSN to deal with "route over" (layer 3 routing) and that 6lowpan would provide requirements to RSN. geoff On Tue, 2007-06-19 at 17:39 +0900, Eunsook "Eunah" Kim wrote: > My 2 cents are in line; > > > The slide (see the pdf above) is pretty clear about the scope of the "mesh > > routing" item: in 6lowpan we are not chartered > > to develop a new routing protocol (as in the algorithm, or the engine to > > generate routing tables). We have something > > that looks like consensus (just need the chairs to declare it so) on > > *adapting* routing protocols developed > > elsewhere. 6lowpan cannot develop protocols cuz it's not in the routing > > area. > > /snip/ > > In my understanding, we had some concerns to work routing solutions at > 6lowpan, as you said it's not in the routing area. However, it doesn't > mean that 6lowpan doesn't need to consider routing related issues for > 6lowpan. IMHO, to make a solution and to handle routing related issues > are different. > > If RSN successfully stages in the IETF, surely, RSN would be a good > place to discuss routing issues for sensor networks. However, as you > said below, for 6lowpan, sub-IP operations for multi-hop delivery > should be considered, as RSN considers L3 routing. > > In my understanding, 6lowpan can be one of the applications for RSN. > One way to consider 6lowpan routing issues is to put 6lowpan specific > mesh-under routing requirements to RSN, as RSN is now gathering > various requirements based on different applications. 6lowpan can > discuss its own requirements with RSN, or input the requirements to > RSN. > > -eunsook > > > As I understand it, RSN operates at layer 3, and it is arguing that there is > > room for another multi-hop routing WG in the > > routing area. Perhaps MANET can't really satisfy requirements for wireless > > sensors. Whether this is solved by > > integrating the RSN charter/deliverables into a re-chartered MANET, or by > > starting a new WG, > > from 6lowpan's point of view, 6lowpan can benefit from the resultant > > protocols. > > Of course, adaptation from layer 3 to sub-IP operation will be required, > > along the lines of the > > existing independent submissions in 6lowpan. > > My 2 motes (hopefully one day those will cost 1 cent each...) > > > > -gabriel > > > > > > ----- Original Message ---- > > From: Dominik Kaspar > > To: Geoff Mulligan > > Cc: rsn@ietf.org > > Sent: Sunday, June 10, 2007 9:17:11 PM > > Subject: Re: [RSN] The need for RSN > > > > Geoff, > > > > As far as I know, there has not been any consensus yet to what is in > > the scope of 6lowpan and what is not. But concering the RSN/R2LN > > efforts, it would be favorable to find consensus as soon as possible, > > so that it's clear where to dedicate new work to. > > > > Dominik > > > > On 6/8/07, Geoff Mulligan wrote: > > > I would like to reiterate that I think that the work RSN group has > > > suggested taking on is very important to my working group - 6lowpan. > > > > > > Our working group is looking to recharter and the scope of the work will > > > be focused on issues related to interoperability for 6lowpan networks. > > > This include things like MIC identifiers, alternative mesh headers, > > > security, ... > > > > > > What is not in the scope is routing. I think the RSN concept is > > > important in that the devices we are anticipating have significant > > > constraints (power, memory, processing) and as such the current set of > > > protocols and development is probably not appropriate for these types of > > > devices. > > > > > > geoff > > > > > > > > > > > > _______________________________________________ > > > RSN mailing list > > > RSN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rsn > > > > > > > _______________________________________________ > > RSN mailing list > > RSN@ietf.org > > https://www1.ietf.org/mailman/listinfo/rsn > > > > > > _______________________________________________ > > 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 Thu Jun 21 17:00:58 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 1I1Tlv-0004yF-OF; Thu, 21 Jun 2007 17:00:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Tlu-0004xy-KT for 6lowpan@lists.ietf.org; Thu, 21 Jun 2007 17:00:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1Tlu-00017R-4U for 6lowpan@lists.ietf.org; Thu, 21 Jun 2007 17:00:54 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2007 17:00:53 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPqCekZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,448,1175486400"; d="scan'208"; a="63392984:sNHT95634716" 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 l5LL0rc8007071; Thu, 21 Jun 2007 17:00:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5LL06MF026721; Thu, 21 Jun 2007 21:00:53 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 17:00:52 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 17:00:51 -0400 In-Reply-To: <1182290840.6218.32.camel@dellx1> References: <675024.81537.qm@web81902.mail.mud.yahoo.com> <77f1dba80706190139t661114f9q90d1c3e2140652ce@mail.gmail.com> <1182290840.6218.32.camel@dellx1> 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 Subject: Re: [6lowpan] Re: [RSN] The need for RSN Date: Thu, 21 Jun 2007 17:00:29 -0400 To: Geoff Mulligan X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Jun 2007 21:00:51.0502 (UTC) FILETIME=[40225CE0:01C7B447] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4745; t=1182459653; x=1183323653; 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:=20Re=3A=20[6lowpan]=20Re=3A=20[RSN]=20The=20need=20for=20RSN |Sender:=20 |To:=20Geoff=20Mulligan=20; bh=zj+s7m3mqAITg49J0OXKNh6935ZUE63P2s0XnQ3qgZc=; b=HOhlL/qbPrnmMVbwjPzg3K68K3QEXTsAC3pQ4iFeeWrOA1MRIYeJxS9sEfOVztk5vCw/KlKM Ae8rNH/mptsS/i8uAAqAw675m0XSZBc/oVaN804fpgjeq5f7F2kkn5jE; 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: 93e7fb8fef2e780414389440f367c879 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org, "g_e_montenegro@yahoo.com" 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 Sounds like we are all in sync then ... JP. On Jun 19, 2007, at 6:07 PM, Geoff Mulligan wrote: > It was my understanding that while 6lowpan may consider "mesh under" > alternatives (layer 2 routing), it would rely upon a group like RSN to > deal with "route over" (layer 3 routing) and that 6lowpan would > provide > requirements to RSN. > > geoff > > On Tue, 2007-06-19 at 17:39 +0900, Eunsook "Eunah" Kim wrote: >> My 2 cents are in line; >> >>> The slide (see the pdf above) is pretty clear about the scope of >>> the "mesh >>> routing" item: in 6lowpan we are not chartered >>> to develop a new routing protocol (as in the algorithm, or the >>> engine to >>> generate routing tables). We have something >>> that looks like consensus (just need the chairs to declare it so) on >>> *adapting* routing protocols developed >>> elsewhere. 6lowpan cannot develop protocols cuz it's not in the >>> routing >>> area. >>> /snip/ >> >> In my understanding, we had some concerns to work routing >> solutions at >> 6lowpan, as you said it's not in the routing area. However, it >> doesn't >> mean that 6lowpan doesn't need to consider routing related issues for >> 6lowpan. IMHO, to make a solution and to handle routing related >> issues >> are different. >> >> If RSN successfully stages in the IETF, surely, RSN would be a good >> place to discuss routing issues for sensor networks. However, as you >> said below, for 6lowpan, sub-IP operations for multi-hop delivery >> should be considered, as RSN considers L3 routing. >> >> In my understanding, 6lowpan can be one of the applications for RSN. >> One way to consider 6lowpan routing issues is to put 6lowpan specific >> mesh-under routing requirements to RSN, as RSN is now gathering >> various requirements based on different applications. 6lowpan can >> discuss its own requirements with RSN, or input the requirements to >> RSN. >> >> -eunsook >> >>> As I understand it, RSN operates at layer 3, and it is arguing >>> that there is >>> room for another multi-hop routing WG in the >>> routing area. Perhaps MANET can't really satisfy requirements for >>> wireless >>> sensors. Whether this is solved by >>> integrating the RSN charter/deliverables into a re-chartered >>> MANET, or by >>> starting a new WG, >>> from 6lowpan's point of view, 6lowpan can benefit from the resultant >>> protocols. >>> Of course, adaptation from layer 3 to sub-IP operation will be >>> required, >>> along the lines of the >>> existing independent submissions in 6lowpan. >>> My 2 motes (hopefully one day those will cost 1 cent each...) >>> >>> -gabriel >>> >>> >>> ----- Original Message ---- >>> From: Dominik Kaspar >>> To: Geoff Mulligan >>> Cc: rsn@ietf.org >>> Sent: Sunday, June 10, 2007 9:17:11 PM >>> Subject: Re: [RSN] The need for RSN >>> >>> Geoff, >>> >>> As far as I know, there has not been any consensus yet to what is in >>> the scope of 6lowpan and what is not. But concering the RSN/R2LN >>> efforts, it would be favorable to find consensus as soon as >>> possible, >>> so that it's clear where to dedicate new work to. >>> >>> Dominik >>> >>> On 6/8/07, Geoff Mulligan wrote: >>>> I would like to reiterate that I think that the work RSN group has >>>> suggested taking on is very important to my working group - >>>> 6lowpan. >>>> >>>> Our working group is looking to recharter and the scope of the >>>> work will >>>> be focused on issues related to interoperability for 6lowpan >>>> networks. >>>> This include things like MIC identifiers, alternative mesh headers, >>>> security, ... >>>> >>>> What is not in the scope is routing. I think the RSN concept is >>>> important in that the devices we are anticipating have significant >>>> constraints (power, memory, processing) and as such the current >>>> set of >>>> protocols and development is probably not appropriate for these >>>> types of >>>> devices. >>>> >>>> geoff >>>> >>>> >>>> >>>> _______________________________________________ >>>> RSN mailing list >>>> RSN@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/rsn >>>> >>> >>> _______________________________________________ >>> RSN mailing list >>> RSN@ietf.org >>> https://www1.ietf.org/mailman/listinfo/rsn >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 21 19:07: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 1I1Vk4-00022U-Tf; Thu, 21 Jun 2007 19:07:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Vk3-00020M-6a for 6lowpan@lists.ietf.org; Thu, 21 Jun 2007 19:07:07 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Vk1-0002sC-0w for 6lowpan@lists.ietf.org; Thu, 21 Jun 2007 19:07:07 -0400 Received: from epmmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JK0005V0DJRG5@mailout1.samsung.com> for 6lowpan@lists.ietf.org; Fri, 22 Jun 2007 08:07:03 +0900 (KST) Received: from daniel ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JK000KRADJRJV@mmp1.samsung.com> for 6lowpan@lists.ietf.org; Fri, 22 Jun 2007 08:07:03 +0900 (KST) Date: Fri, 22 Jun 2007 08:06:48 +0900 From: Daniel Park Subject: RE: [6lowpan] Re: [RSN] The need for RSN In-reply-to: <1182290840.6218.32.camel@dellx1> To: 'Geoff Mulligan' , "'Eunsook \"Eunah\" Kim'" Message-id: <0JK000KRBDJRJV@mmp1.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcezQ9dR/IvB/xJERtGPx4Iv+S+K3QBFBNbQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org, g_e_montenegro@yahoo.com 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 > It was my understanding that while 6lowpan may consider "mesh under" > alternatives (layer 2 routing), it would rely upon a group > like RSN to deal with "route over" (layer 3 routing) and that > 6lowpan would provide requirements to RSN. I don't think so Geoff. Originally, this deliverable was for Proposed Standard Document. Are you saying 6lowpan mesh-routing requirement might be Proposed Standard ? Absolutely, NO. I don't care if you as chair are leaning to RSN for this matter based on AD's agreement, but just wanted to clarify your mis-interpretation from 6lowpan perspevtive. Also, IEEE 802.15.5 is already developing L2 mesh routing for IEEE 802.15.4. What alternative means in your mention ? -- Daniel Park _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 21 20:02:06 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 1I1WbD-0006ur-Gr; Thu, 21 Jun 2007 20:02:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1WbC-0006ua-PE for 6lowpan@lists.ietf.org; Thu, 21 Jun 2007 20:02:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1WbC-0004tc-G2 for 6lowpan@lists.ietf.org; Thu, 21 Jun 2007 20:02:02 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2007 20:02:02 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKOtekZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,449,1175486400"; d="scan'208"; a="63405855:sNHT26365878" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5M022ot020883; Thu, 21 Jun 2007 20:02:02 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5M01WLj005356; Fri, 22 Jun 2007 00:01:53 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 20:01:39 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 20:01:38 -0400 In-Reply-To: <0JK000KRBDJRJV@mmp1.samsung.com> References: <0JK000KRBDJRJV@mmp1.samsung.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [6lowpan] Re: [RSN] The need for RSN Date: Thu, 21 Jun 2007 20:01:14 -0400 To: Daniel Park X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Jun 2007 00:01:38.0948 (UTC) FILETIME=[81B74440:01C7B460] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1077; t=1182470522; x=1183334522; c=relaxed/simple; s=rtpdkim1001; 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[6lowpan]=20Re=3A=20[RSN]=20The=20need=20for=20RSN |Sender:=20 |To:=20Daniel=20Park=20; bh=/ttBaBx/f4LDZO7lT3FaHNOmAGBiuC/cYKCgyVKjnyU=; b=UvRpZLFS/jozcv9VFE4ObSn5vgtCf4hscghLjFy8AIyhl2KZOmkXX5K1XnNeUt7CSLXfIYsk 73qIyRHljLzlqHxulGZUd3K31ZZICRhbeaK1XQcZ0jh7FXcSLhL1BeTK; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Geoff Mulligan , rsn@ietf.org, g_e_montenegro@yahoo.com, 6lowpan@lists.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 Jun 21, 2007, at 7:06 PM, Daniel Park wrote: >> It was my understanding that while 6lowpan may consider "mesh under" >> alternatives (layer 2 routing), it would rely upon a group >> like RSN to deal with "route over" (layer 3 routing) and that >> 6lowpan would provide requirements to RSN. > > I don't think so Geoff. Originally, this deliverable was for > Proposed Standard Document. Are you saying 6lowpan > mesh-routing requirement might be Proposed Standard ? > Absolutely, NO. There is no such deliverables ... > > I don't care if you as chair are leaning to RSN for this > matter based on AD's agreement, but just wanted to > clarify your mis-interpretation from 6lowpan perspevtive. > Daniel, as you know 6lowpan is about to recharter ... > Also, IEEE 802.15.5 is already developing L2 mesh > routing for IEEE 802.15.4. What alternative means > in your mention ? > > -- Daniel Park > > > _______________________________________________ > 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 Thu Jun 21 20:37:56 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 1I1X9w-0000lx-5Q; Thu, 21 Jun 2007 20:37:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1X9u-0000ln-DP for 6lowpan@lists.ietf.org; Thu, 21 Jun 2007 20:37:54 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1X9t-0003iM-0Y for 6lowpan@lists.ietf.org; Thu, 21 Jun 2007 20:37:54 -0400 Received: from epmmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JK00006FHR3IU@mailout2.samsung.com> for 6lowpan@lists.ietf.org; Fri, 22 Jun 2007 09:37:51 +0900 (KST) Received: from daniel ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JK000878HR2P0@mmp2.samsung.com> for 6lowpan@lists.ietf.org; Fri, 22 Jun 2007 09:37:51 +0900 (KST) Date: Fri, 22 Jun 2007 09:37:36 +0900 From: Daniel Park Subject: RE: [6lowpan] Re: [RSN] The need for RSN In-reply-to: To: 'JP Vasseur' Message-id: <0JK000879HR3P0@mmp2.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Ace0YJCl5WE2n68jSyG6XtXY58nnEwABABcw X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'Geoff Mulligan' , rsn@ietf.org, g_e_montenegro@yahoo.com, 6lowpan@lists.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 > >> It was my understanding that while 6lowpan may consider > "mesh under" > >> alternatives (layer 2 routing), it would rely upon a group > >> like RSN to deal with "route over" (layer 3 routing) and that > >> 6lowpan would provide requirements to RSN. > > > > I don't think so Geoff. Originally, this deliverable was for > > Proposed Standard Document. Are you saying 6lowpan > > mesh-routing requirement might be Proposed Standard ? > > Absolutely, NO. > There is no such deliverables ... I said: 4. Produce "6lowpan Mesh Routing" to evaluate different mesh routing protocols for use within 6lowpans. While most routing protocols are defined above the IP layer, 6lowpan requires a mesh routing protocol below the IP layer. "6lowpan Mesh Routing" may be several proposed standard documents. So, are you thinking we need both solutions as layer 2 routing by 6lowpan WG and layer 3 routing by RSN for mesh routing ? Or, 6lowpan only work for RSN requirement ? _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 21 20:40: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 1I1XCl-0004lq-G2; Thu, 21 Jun 2007 20:40:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XCl-0004l4-4Z; Thu, 21 Jun 2007 20:40:51 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1XCj-0004et-Ns; Thu, 21 Jun 2007 20:40:51 -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 l5M0ee2D021642; Thu, 21 Jun 2007 18:40:40 -0600 (MDT) Subject: RE: [6lowpan] Re: [RSN] The need for RSN From: Geoff Mulligan To: Daniel Park In-Reply-To: <0JK000KRBDJRJV@mmp1.samsung.com> References: <0JK000KRBDJRJV@mmp1.samsung.com> Content-Type: text/plain Date: Thu, 21 Jun 2007 18:40:50 -0600 Message-Id: <1182472850.6218.126.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org, g_e_montenegro@yahoo.com 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 Daniel, I don't understand what you are saying. On Fri, 2007-06-22 at 08:06 +0900, Daniel Park wrote: > > It was my understanding that while 6lowpan may consider "mesh under" > > alternatives (layer 2 routing), it would rely upon a group > > like RSN to deal with "route over" (layer 3 routing) and that > > 6lowpan would provide requirements to RSN. > > I don't think so Geoff. Originally, this deliverable was for > Proposed Standard Document. Are you saying 6lowpan > mesh-routing requirement might be Proposed Standard ? > Absolutely, NO. What do you mean "this deliverable"? What deliverable, "layer 2 mesh"? Never were we chartered to define a Proposed Standard for layer 2 meshing". If that is what you are saying, then I agree. As originally chartered we were not to write a proposed standard for layer 2 mesh. I stated in my message, as stated in the original charter, that the WG might look at layer 2 routing (mesh under) alternatives, such as those available from manet or 802.15.5. > > I don't care if you as chair are leaning to RSN for this > matter based on AD's agreement, but just wanted to > clarify your mis-interpretation from 6lowpan perspevtive. I don't think that I mis-interpreted our original charter. If you read the WG documents they represent the concept of mesh under (layer 2 routing) and not routing over IP, but either way, it was very clear that routing protocols were never intended to be a part of 6lowpan work. > > Also, IEEE 802.15.5 is already developing L2 mesh > routing for IEEE 802.15.4. What alternative means > in your mention ? I know that 15.5 is working on Layer 2 meshing and the working group should look at that as well as the other proposals that are consistent with MANET. > > -- Daniel Park _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 21 20:49: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 1I1XLU-0006SR-AV; Thu, 21 Jun 2007 20:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XLS-0006SG-B4; Thu, 21 Jun 2007 20:49:50 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1XLI-0006xD-FR; Thu, 21 Jun 2007 20:49:50 -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 l5M0nVpA021679; Thu, 21 Jun 2007 18:49:31 -0600 (MDT) Subject: RE: [6lowpan] Re: [RSN] The need for RSN From: Geoff Mulligan To: Daniel Park In-Reply-To: <0JK000879HR3P0@mmp2.samsung.com> References: <0JK000879HR3P0@mmp2.samsung.com> Content-Type: text/plain Date: Thu, 21 Jun 2007 18:49:41 -0600 Message-Id: <1182473381.6218.137.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rsn@ietf.org, g_e_montenegro@yahoo.com, 6lowpan@lists.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 Daniel, I still don't understand your question. Do you not think that 6lowpan should generate a PS document on L2 routing? This has been in the re-charter proposal for months. I think that there may be networks that will not use L2 mesh and will instead opt for L3 routing. There might well be other networks that will use L3 routing between L2 mesh networks. geoff On Fri, 2007-06-22 at 09:37 +0900, Daniel Park wrote: > > >> It was my understanding that while 6lowpan may consider > > "mesh under" > > >> alternatives (layer 2 routing), it would rely upon a group > > >> like RSN to deal with "route over" (layer 3 routing) and that > > >> 6lowpan would provide requirements to RSN. > > > > > > I don't think so Geoff. Originally, this deliverable was for > > > Proposed Standard Document. Are you saying 6lowpan > > > mesh-routing requirement might be Proposed Standard ? > > > Absolutely, NO. > > There is no such deliverables ... > > I said: > 4. Produce "6lowpan Mesh Routing" to evaluate different mesh routing > protocols for use within 6lowpans. While most routing protocols are > defined above the IP layer, 6lowpan requires a mesh routing protocol > below the IP layer. "6lowpan Mesh Routing" may be several proposed > standard documents. > > So, are you thinking we need both solutions as layer 2 routing > by 6lowpan WG and layer 3 routing by RSN for mesh routing ? > Or, 6lowpan only work for RSN requirement ? > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 21 22:00:04 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 1I1YRQ-0003PI-0g; Thu, 21 Jun 2007 22:00:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1YRN-0003Gg-Qn; Thu, 21 Jun 2007 22:00:01 -0400 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1YRM-0005ur-IX; Thu, 21 Jun 2007 22:00:01 -0400 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1I1YRL-0000cs-1E; Thu, 21 Jun 2007 18:59:59 -0700 In-Reply-To: <20070604153708.E95E316B0001@secure.archedrock.com> References: <20070604153708.E95E316B0001@secure.archedrock.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0DC8E411-0B38-4ABD-8EE6-46065A993316@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Thu, 21 Jun 2007 18:10:36 -0700 To: dculler@archrock.com X-Mailer: Apple Mail (2.752.2) 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: d568c20fab0e2ccae07d583947984559 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rsn@ietf.org, 6lowpan@ietf.org Subject: [6lowpan] Re: [RSN] Update 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 Jun 4, 2007, at 8:36 AM, dculler wrote: > > I think the simplification to "Routing Issues for Low Power Wireless > Networks" is very good. It defines the scope implicitly in a > number of > useful ways. > * There are a whole class of these devices where no routing is > involved > (game controllers, remote controls, wireless keyboard and mouse, ear > pieces). > * It includes portions of sensor networks, embedded networks, > automation, > but it not specifically limited to that. > * It includes 802.15.4 and links in a similar class. > * The technical challenges (loss, variation, multihop) are implied. > * It allows for both light footprint (microcontroller) and more > capable > hosts. > > So now we just need to tweak it to get a good acronym, since RILPWM > doesn't > exactly role off the tongue. How about RLANE Routing in Lossy low power Ad-hoc wireless NEtworks. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 21 23:05:39 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 1I1ZSo-00072b-It; Thu, 21 Jun 2007 23:05:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ZSn-00072S-GH for 6lowpan@lists.ietf.org; Thu, 21 Jun 2007 23:05:33 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ZSl-0000mc-S5 for 6lowpan@lists.ietf.org; Thu, 21 Jun 2007 23:05:33 -0400 Received: from epmmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JK000E67OL607@mailout3.samsung.com> for 6lowpan@lists.ietf.org; Fri, 22 Jun 2007 12:05:30 +0900 (KST) Received: from daniel ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JK000F4LOL529@mmp2.samsung.com> for 6lowpan@lists.ietf.org; Fri, 22 Jun 2007 12:05:30 +0900 (KST) Date: Fri, 22 Jun 2007 12:05:15 +0900 From: Daniel Park Subject: RE: [6lowpan] Re: [RSN] The need for RSN In-reply-to: <1182473381.6218.137.camel@dellx1> To: 'Geoff Mulligan' Message-id: <0JK000F4NOL629@mmp2.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Ace0Zz2Dds7YugYMR9K0PeleWhhZbgAEXExQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: rsn@ietf.org, g_e_montenegro@yahoo.com, 6lowpan@lists.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 Geoff, Clarification to me. L2 mesh routing is made by 6lowpan taking 802.15.5 into consideration, and L3 mesh routing is perhaps made by another WG regardless of MANET WG deliverables such as DYMO/AODV based on 6lowpan L3 mesh routing requirement. -- Daniel Park > -----Original Message----- > From: Geoff Mulligan [mailto:geoff-ietf@mulligan.org] > Sent: Friday, June 22, 2007 9:50 AM > To: Daniel Park > Cc: 'JP Vasseur'; 'Eunsook "Eunah" Kim'; > 6lowpan@lists.ietf.org; rsn@ietf.org; > g_e_montenegro@yahoo.com; 'Mark Townsley' > Subject: RE: [6lowpan] Re: [RSN] The need for RSN > > Daniel, > I still don't understand your question. Do you not think > that 6lowpan > should generate a PS document on L2 routing? This has been in the > re-charter proposal for months. > > I think that there may be networks that will not use L2 mesh and will > instead opt for L3 routing. There might well be other networks that > will use L3 routing between L2 mesh networks. > > geoff > > On Fri, 2007-06-22 at 09:37 +0900, Daniel Park wrote: > > > >> It was my understanding that while 6lowpan may consider > > > "mesh under" > > > >> alternatives (layer 2 routing), it would rely upon a group > > > >> like RSN to deal with "route over" (layer 3 routing) and that > > > >> 6lowpan would provide requirements to RSN. > > > > > > > > I don't think so Geoff. Originally, this deliverable was for > > > > Proposed Standard Document. Are you saying 6lowpan > > > > mesh-routing requirement might be Proposed Standard ? > > > > Absolutely, NO. > > > There is no such deliverables ... > > > > I said: > > 4. Produce "6lowpan Mesh Routing" to evaluate different mesh routing > > protocols for use within 6lowpans. While most routing protocols are > > defined above the IP layer, 6lowpan requires a mesh routing protocol > > below the IP layer. "6lowpan Mesh Routing" may be several proposed > > standard documents. > > > > So, are you thinking we need both solutions as layer 2 routing > > by 6lowpan WG and layer 3 routing by RSN for mesh routing ? > > Or, 6lowpan only work for RSN requirement ? > > > > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jun 22 02:24:06 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 1I1cYo-0007GE-Vk; Fri, 22 Jun 2007 02:23:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1cYn-0007G0-Tv for 6lowpan@lists.ietf.org; Fri, 22 Jun 2007 02:23:57 -0400 Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1cYn-0005NX-L5 for 6lowpan@lists.ietf.org; Fri, 22 Jun 2007 02:23:57 -0400 Received: by nz-out-0506.google.com with SMTP id z6so791057nzd for <6lowpan@lists.ietf.org>; Thu, 21 Jun 2007 23:23:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JHoY3arXYHuHyjKIUPDvzOLITHQ8ll3/aoLl+sMJ88f/hfcseHpBH5WlEcPdpIRElyIWWJsRfVw0/XvlRJ6Kj+Mj5EJsV99mCgp/bB9xVxqg5z/bybqEMhjzZ6/u6qCmPyRFqQLrbsTwAwsGPEfrOdi3ZdCK5BkfMtkeLxKgLFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ya/0ESOBiRqAAc5pXijlLlPbEnM34pnz/MvH3/aM1CDEPoGxCqDr30mnjzZ2fTTpZLWdXh0hMXZZ/th+hPNE5Em+Lq4QSTvxvMdG2kYeyYlktzB//sPkdaeWDONdCKvKSieAjLuFNHVM1TMp1wFSINLIB8hSKUAy6+OyVEQy/Qo= Received: by 10.142.251.9 with SMTP id y9mr60746wfh.1182493437044; Thu, 21 Jun 2007 23:23:57 -0700 (PDT) Received: by 10.143.28.13 with HTTP; Thu, 21 Jun 2007 23:23:57 -0700 (PDT) Message-ID: <77f1dba80706212323l77364169y6438cb86a81b44f0@mail.gmail.com> Date: Fri, 22 Jun 2007 15:23:57 +0900 From: "Eunsook \"Eunah\" Kim" To: "Daniel Park" Subject: Re: [6lowpan] Re: [RSN] The need for RSN In-Reply-To: <0JK000F4NOL629@mmp2.samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1182473381.6218.137.camel@dellx1> <0JK000F4NOL629@mmp2.samsung.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Geoff Mulligan , rsn@ietf.org, g_e_montenegro@yahoo.com, 6lowpan@lists.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'm a bit confused by your discussion. >From Geoff's proposed recharter text, It seemed to be clear for me that so-called "mesh-under routing" is 6lowpan's concern, while L3 routing is RSN's concern. We need to find out if we CAN take exisiting solutions or if we NEED to design a new one. Clearly for me, to find out this answer is 6lowpan's work. -eunsook On 6/22/07, Daniel Park wrote: > Geoff, > > Clarification to me. > > L2 mesh routing is made by 6lowpan taking > 802.15.5 into consideration, and L3 mesh routing > is perhaps made by another WG regardless of > MANET WG deliverables such as DYMO/AODV > based on 6lowpan L3 mesh routing requirement. > > -- Daniel Park > > > -----Original Message----- > > From: Geoff Mulligan [mailto:geoff-ietf@mulligan.org] > > Sent: Friday, June 22, 2007 9:50 AM > > To: Daniel Park > > Cc: 'JP Vasseur'; 'Eunsook "Eunah" Kim'; > > 6lowpan@lists.ietf.org; rsn@ietf.org; > > g_e_montenegro@yahoo.com; 'Mark Townsley' > > Subject: RE: [6lowpan] Re: [RSN] The need for RSN > > > > Daniel, > > I still don't understand your question. Do you not think > > that 6lowpan > > should generate a PS document on L2 routing? This has been in the > > re-charter proposal for months. > > > > I think that there may be networks that will not use L2 mesh and will > > instead opt for L3 routing. There might well be other networks that > > will use L3 routing between L2 mesh networks. > > > > geoff > > > > On Fri, 2007-06-22 at 09:37 +0900, Daniel Park wrote: > > > > >> It was my understanding that while 6lowpan may consider > > > > "mesh under" > > > > >> alternatives (layer 2 routing), it would rely upon a group > > > > >> like RSN to deal with "route over" (layer 3 routing) and that > > > > >> 6lowpan would provide requirements to RSN. > > > > > > > > > > I don't think so Geoff. Originally, this deliverable was for > > > > > Proposed Standard Document. Are you saying 6lowpan > > > > > mesh-routing requirement might be Proposed Standard ? > > > > > Absolutely, NO. > > > > There is no such deliverables ... > > > > > > I said: > > > 4. Produce "6lowpan Mesh Routing" to evaluate different mesh routing > > > protocols for use within 6lowpans. While most routing protocols are > > > defined above the IP layer, 6lowpan requires a mesh routing protocol > > > below the IP layer. "6lowpan Mesh Routing" may be several proposed > > > standard documents. > > > > > > So, are you thinking we need both solutions as layer 2 routing > > > by 6lowpan WG and layer 3 routing by RSN for mesh routing ? > > > Or, 6lowpan only work for RSN requirement ? > > > > > > > > > > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jun 22 11:20:08 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 1I1kve-0007t5-62; Fri, 22 Jun 2007 11:20:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1kvd-0007sw-42 for 6lowpan@lists.ietf.org; Fri, 22 Jun 2007 11:20:05 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1kvc-0007g3-Fm for 6lowpan@lists.ietf.org; Fri, 22 Jun 2007 11:20:05 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jun 2007 11:20:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAH6Fe0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,452,1175486400"; d="scan'208"; a="124326800:sNHT32424512" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5MFK4Hi003012; Fri, 22 Jun 2007 11:20:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5MFJoLv015044; Fri, 22 Jun 2007 15:19:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 11:19:50 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 11:19:49 -0400 In-Reply-To: <77f1dba80706212323l77364169y6438cb86a81b44f0@mail.gmail.com> References: <1182473381.6218.137.camel@dellx1> <0JK000F4NOL629@mmp2.samsung.com> <77f1dba80706212323l77364169y6438cb86a81b44f0@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3AA57709-C2AB-477F-B398-813649DF97AE@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [6lowpan] Re: [RSN] The need for RSN Date: Fri, 22 Jun 2007 11:17:36 -0400 To: "Eunsook \"Eunah\" Kim" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Jun 2007 15:19:49.0810 (UTC) FILETIME=[C66DB120:01C7B4E0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3128; t=1182525604; x=1183389604; c=relaxed/simple; s=rtpdkim1001; 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[6lowpan]=20Re=3A=20[RSN]=20The=20need=20for=20RSN |Sender:=20 |To:=20=22Eunsook=20\=22Eunah\=22=20Kim=22=20; bh=uHn+jcdMdU2xo4DuqT3UEXF/SUQR3curZIac7vmbICA=; b=KFKMRJ0SPebUk3gkIEHYf5qbe2OE1J2x5t3hZgMeHlsVVrvJpsm2NzphN9edskXR/vrt7k7K 2NA4V0VHunfQZ0cZzY6TvIpqKnWmuytPBJZhzeBvwn2vaBpvyI6cVQpb; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Geoff Mulligan , rsn@ietf.org, g_e_montenegro@yahoo.com, 6lowpan@lists.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 Jun 22, 2007, at 2:23 AM, Eunsook "Eunah" Kim wrote: > Hmm.. > I'm a bit confused by your discussion. > From Geoff's proposed recharter text, It seemed to be clear for me > that so-called "mesh-under routing" is 6lowpan's concern, while L3 > routing is RSN's concern. Quite right. > > We need to find out if we CAN take exisiting solutions or if we NEED > to design a new one. Clearly for me, to find out this answer is > 6lowpan's work. > As far as L3 routing is concerned, that task WOULD be the one of the POTENTIAL new WG work. If everybody agrees, it would be nice to go back to the technical work. Cheers. JP. > -eunsook > > > On 6/22/07, Daniel Park wrote: >> Geoff, >> >> Clarification to me. >> >> L2 mesh routing is made by 6lowpan taking >> 802.15.5 into consideration, and L3 mesh routing >> is perhaps made by another WG regardless of >> MANET WG deliverables such as DYMO/AODV >> based on 6lowpan L3 mesh routing requirement. >> >> -- Daniel Park >> >> > -----Original Message----- >> > From: Geoff Mulligan [mailto:geoff-ietf@mulligan.org] >> > Sent: Friday, June 22, 2007 9:50 AM >> > To: Daniel Park >> > Cc: 'JP Vasseur'; 'Eunsook "Eunah" Kim'; >> > 6lowpan@lists.ietf.org; rsn@ietf.org; >> > g_e_montenegro@yahoo.com; 'Mark Townsley' >> > Subject: RE: [6lowpan] Re: [RSN] The need for RSN >> > >> > Daniel, >> > I still don't understand your question. Do you not think >> > that 6lowpan >> > should generate a PS document on L2 routing? This has been in the >> > re-charter proposal for months. >> > >> > I think that there may be networks that will not use L2 mesh and >> will >> > instead opt for L3 routing. There might well be other networks >> that >> > will use L3 routing between L2 mesh networks. >> > >> > geoff >> > >> > On Fri, 2007-06-22 at 09:37 +0900, Daniel Park wrote: >> > > > >> It was my understanding that while 6lowpan may consider >> > > > "mesh under" >> > > > >> alternatives (layer 2 routing), it would rely upon a group >> > > > >> like RSN to deal with "route over" (layer 3 routing) and >> that >> > > > >> 6lowpan would provide requirements to RSN. >> > > > > >> > > > > I don't think so Geoff. Originally, this deliverable was for >> > > > > Proposed Standard Document. Are you saying 6lowpan >> > > > > mesh-routing requirement might be Proposed Standard ? >> > > > > Absolutely, NO. >> > > > There is no such deliverables ... >> > > >> > > I said: >> > > 4. Produce "6lowpan Mesh Routing" to evaluate different mesh >> routing >> > > protocols for use within 6lowpans. While most routing >> protocols are >> > > defined above the IP layer, 6lowpan requires a mesh routing >> protocol >> > > below the IP layer. "6lowpan Mesh Routing" may be several >> proposed >> > > standard documents. >> > > >> > > So, are you thinking we need both solutions as layer 2 routing >> > > by 6lowpan WG and layer 3 routing by RSN for mesh routing ? >> > > Or, 6lowpan only work for RSN requirement ? >> > > >> > >> > >> > >> >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Jun 24 19:51:36 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 1I2brb-0005z5-UJ; Sun, 24 Jun 2007 19:51:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2bra-0005yq-3F for 6lowpan@lists.ietf.org; Sun, 24 Jun 2007 19:51:26 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2brY-00013Z-TX for 6lowpan@lists.ietf.org; Sun, 24 Jun 2007 19:51:26 -0400 Received: by py-out-1112.google.com with SMTP id u77so1438179pyb for <6lowpan@lists.ietf.org>; Sun, 24 Jun 2007 16:51:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cJGY7HEW4ZD1XRCj5uGySsiYhYOsV5pgZkTfy7QhLZRsA4ELvy81kaHCATedMpbSpXU0FEGlNB+ZnDtIWO3IUQOY9XwWaH/2SvgKCaw9jvkNGtOIjpeUAI+UY6eS5NA6vIYWXa2cd+xUoXVxsPa54oZa9Q/vXRceyEkepSzwGGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ouac64lGzE+60YSctnSt5YghWj7UGeyreKXmJ86RWqM2JYuWLSeaZ5iz+KAdiJtSPV6uLbY73QdJ5B9ItdDFmUwPo1sRMB7TmeO2r6rjqCL2Rrfq6ILKlu6jDfYAOK8a9ndVFMzZ59nRnlxg6s47x3T2P2IeNqJmqbtmZnAcJ6E= Received: by 10.115.49.16 with SMTP id b16mr4931506wak.1182729083896; Sun, 24 Jun 2007 16:51:23 -0700 (PDT) Received: by 10.115.94.7 with HTTP; Sun, 24 Jun 2007 16:51:23 -0700 (PDT) Message-ID: Date: Mon, 25 Jun 2007 08:51:23 +0900 From: "Daniel Park" To: "JP Vasseur" Subject: Re: [6lowpan] Re: [RSN] The need for RSN In-Reply-To: <3AA57709-C2AB-477F-B398-813649DF97AE@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1182473381.6218.137.camel@dellx1> <0JK000F4NOL629@mmp2.samsung.com> <77f1dba80706212323l77364169y6438cb86a81b44f0@mail.gmail.com> <3AA57709-C2AB-477F-B398-813649DF97AE@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 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 > > We need to find out if we CAN take exisiting solutions or if we NEED > > to design a new one. Clearly for me, to find out this answer is > > 6lowpan's work. > > > > As far as L3 routing is concerned, that task WOULD be the one of the > POTENTIAL > new WG work. Well, those kinds of work can be taken place at the relevant WG in advance. For example, one of MANET WG sessions for this issue. Than, IETF can move it on if we can see any EXPLICIT _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 25 17:35:33 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 1I2wDc-0002Vy-4Y; Mon, 25 Jun 2007 17:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2wDb-0002UU-LM for 6lowpan@lists.ietf.org; Mon, 25 Jun 2007 17:35:31 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2wDa-0003VQ-VB for 6lowpan@lists.ietf.org; Mon, 25 Jun 2007 17:35:31 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2007 14:35:30 -0700 X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208"; a="171819376:sNHT57914091" 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 l5PLZUNq002421; Mon, 25 Jun 2007 14:35:30 -0700 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5PLZUka002902; Mon, 25 Jun 2007 21:35:30 GMT Received: from [128.107.113.79] (dhcp-128-107-113-79.cisco.com [128.107.113.79]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id l5PLZT724192; Mon, 25 Jun 2007 14:35:29 -0700 (PDT) Message-ID: <467FFF42.9010402@cisco.com> Date: Mon, 25 Jun 2007 19:45:38 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Geoff Mulligan Subject: Re: [6lowpan] Rechartering consensus... References: <1182290571.6218.29.camel@dellx1> In-Reply-To: <1182290571.6218.29.camel@dellx1> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9230; t=1182807330; x=1183671330; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[6lowpan]=20Rechartering=20consensus... |Sender:=20; bh=TZZkH4cbHshOpoJVe5uIzwS1fUublJis4sl/R01TLGI=; b=f8PXvfGbDUIWyVeEL4YCivArZRY474HlFlmH328+hcrOO+h6SfG//hjmVfuSGtfa3wQwbUXX 3cqhoZ4sw7DBEwG4k/5yLls2wxCO2hPfK9F9i/X+4C8zy87QjIDm66ZF; Authentication-Results: sj-dkim-4; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: 6lowpan <6lowpan@lists.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 Geoff Mulligan wrote: > 6LoWPAN group, > It would appear that we have consensus on the work items for the > working group rechartering - the following 5 topics have been relatively > unchanged for months. > > As I have been working with folks that are implementing 6LoWPAN and from > some of the messages on the list I have realized that we should probably > be focused on those topics that are necessary to resolve for > interoperability between implementations. Some of the 5 items here are > targeted to this and some of the topics mentioned on the list, such as a > standard/defined MIC could fall under one of the topics. > > - “6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations” > - “Problem Statement for Stateful Header Compression in 6lowpans” > - “Recommendations for 6lowpan Applications” > - “6lowpan Mesh Routing” > - “6lowpan Security Analysis” > > I have attached a proposed new charter for the working group. > > geoff > > > > ------------------------------------------------------------------------ > > Background/Introduction: > > Well-established fields such as control networks, and burgeoning ones > such as "sensor" (or transducer) networks, are increasingly being > based on wireless technologies. Most (but certainly not all) of these > nodes are amongst the most constrained that have ever been networked > wirelessly. Extreme low power (such that they will run potentially for > years on batteries) and extreme low cost (total device cost in single > digit dollars, and riding Moore's law to continuously reduce that > price point) are seen as essential enablers towards their deployment > in networks with the following characteristics: > > * Significantly more devices than current networks > This statement seems a bit dubious to me. More devices than what "current" networks? And, what exactly is the limit of a "network" in this statement (the Internet is a network, for example, and I don't think you are building anything larger than the Internet itself). > * Severely limited code and ram space (e.g., highly desirable to > fit the required code--MAC, IP and anything else needed to > execute the embedded application-- in, for example, 32K of flash > memory, using 8-bit microprocessors) > > * Unobtrusive but very different user interface for configuration > (e.g., using gestures or interactions involving the physical > world) > > * Robustness and simplicity in routing or network fabric > This is a bit of a platitude, and why *or* here? > A chief component of these devices is wireless communication > technology. In particular, the IEEE 802.15.4 standard is very > promising for the lower (physical and link) layers. As for higher > layer functions, there is considerable interest from non-IETF groups > in using IP technology. The working group is expected to coordinate > and interact with such groups. > > The working group has completed a problem statement/requirements RFC > and and adaptation layer (IPv6 over 802.15.4) RFC. The working group > Double "and" > has as its main objective to complete those topics and areas necessary > for successful implmentation interoperability. > What do you mean by "complete those topics"? Continue to advance on the standards track? > The required work includes items in the following (incomplete) list: > > * Addressing schemes and address management > * Network management > * Routing in dynamically adaptive topologies > * Security, including set-up and maintenance > * Application programming interface > * Discovery (of devices, of services, etc) > * Implementation considerations > > Whereas at least some of the above items are within the purview of the > IETF, at this point it is not clear that all of them are. Accordingly, > the 6LoWPAN working group will address a reduced, more focused set of > objectives. > I think the above list raises more questions than it answers. When I read it, I immediately ask "who is doing all this work? Should we liaise with someone on it? is it possible to have interoperable implementations without addressing all of these items? What else is left? etc." Rather than try and capture the entire landscape in an incomplete list, let's focus the charter on two things (1) What the 6lowpan group is going to do, and (2) any *important* things that this WG is *not* going to do. For the latter, any pointers to other WGs, SDOs, etc. would be welcome. > Scope of 6lowpan: > > 1. Produce “6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations” > to define the required optimizations to make IPv6 ND applicable in > 6lowpans, given the fact that IPv6 ND is too expensive for the devices > of 6lowpan and requires multicast. Do we have consensus that ND is too expensive? If so, great, but I want to be sure. Secondly, do we have consensus that ND is required? If 6lowpans have their own built-in address resolution due to the way addresses are managed, what aspects of ND are necessary? > This document will define how to > bootstrap a 6lowpan network and explore ND optimizations such as > reusing the 802.15.4 network structure (use the coordinators), and > obviate multicast by having devices talk to coordinators without > creating a single point-of-failure, and changing the IPv6 ND multicast > semantics. This document will be a proposed standard. > This work item needs to be a little more crisp. Is this "Bootstrapping" or "ND" or both? If both, are we making the assumption that ND is the Bootstrapping method, but that it needs to be changed to work in a lowpan? > 2. Produce “Problem Statement for Stateful Header Compression in > 6lowpans” to document the problem of using stateful header compression > (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of > stateless header compression given the assumption that stateful header > compression may be too complex. This document will determine if the > assumption is correct and will be an informational document. > For the last sentence "The WG will determine if the assumption is correct at this time and record the findings in this informational document." > 3. Produce “Recommendations for 6lowpan Applications” to define a > set of recommendations of protocols to use for applications. The > recommendations will cover protocols for transport, application layer, > discovery, configuration and commissioning. This document will be an > informational document. > Can we be specific as to which protocols will be covered? This seems very open-ended. > 4. Produce “6lowpan Mesh Routing” to evaluate different mesh routing > protocols for use within 6lowpans. While most routing protocols are > defined above the IP layer, 6lowpan requires a mesh routing protocol > below the IP layer. “6lowpan Mesh Routing” may be several proposed > standard documents. > I think we need to be sure that the line between this and the "RSN" effort that is spinning up is clear. Also, nailing down which PS documents will be necessary would be a very nice thing to do. > 5. Produce “6lowpan Security Analysis” to define the threat model of > 6lowpans and to document suitability of existing key management > schemes and to discuss bootstrapping/installation/commissioning/setup > issues. This document will be an informational document. > And you will need a security area adviser appointed for this. When the time comes we will need to ask the secdir to appoint someone. > The working group will reuse existing specifications whenever > reasonable and possible. > s/specifications/protocols and mechanisms > The working group will also serve as a venue for ongoing discussions > on other topics related to the more complete list outlined above. > Additional related milestones may be added in the future via a > rechartering operation. > Not sure this is good advice. You already have a big chunk of work to chew on. If discussion naturally ends up on this list for other work, that's fine, but I don't see why it needs to be listed in the charter as specifically allowed. > Note: As may be obvious from its official name above, this particular > working group will not work on IPv4 over IEEE 802.15.4 specifications. > Given the limitations of the target devices, dual-stack deployments > are not practical. Because of its higher potential for header > compression, its support for the huge number of devices expected and > of cleanly built-in features such as address autoconfiguration, IPv6 > is the exclusive focus of the working group. > I understand keeping IPv4 out of scope for within the lowpan, but I do think it is important to write a recommendation for the 6lowpan communicating on the Internet at large, in particular the IPv4 Internet. Thoughts on this? Thanks, - Mark > ------------------------------------------------------------------------ > > _______________________________________________ > 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