From 6lowpan-bounces@ietf.org Tue Jul 1 09:10:01 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814033A6A76; Tue, 1 Jul 2008 09:10:01 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974283A6A76 for <6lowpan@core3.amsl.com>; Tue, 1 Jul 2008 09:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTxdR0An4txE for <6lowpan@core3.amsl.com>; Tue, 1 Jul 2008 09:09:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5DFCB3A69B9 for <6lowpan@ietf.org>; Tue, 1 Jul 2008 09:09:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,732,1204498800"; d="scan'208";a="13194925" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Jul 2008 18:10:01 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m61GA1SZ009474; Tue, 1 Jul 2008 18:10:01 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m61GA0gJ017463; Tue, 1 Jul 2008 16:10:00 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jul 2008 18:09:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Jul 2008 18:08:29 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05E78DC3@xmb-ams-337.emea.cisco.com> In-Reply-To: <00d301c8d57f$779a1a50$7500a8c0@KDDILAB> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] revised new new charter text Thread-Index: AcjSHZejG45WABVzS7+eWklHUAchyQDYYT+QAYU5XAA= References: <1213823561.6003.88.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D6F6B6@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05D6F815@xmb-ams-337.emea.cisco.com><485A7501.7010803@cisco.com> <00d301c8d57f$779a1a50$7500a8c0@KDDILAB> From: "Pascal Thubert (pthubert)" To: "carl williams" , "Mark Townsley (townsley)" , "Carsten Bormann" X-OriginalArrivalTime: 01 Jul 2008 16:09:08.0325 (UTC) FILETIME=[CABF8150:01C8DB94] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3211; t=1214928601; x=1215792601; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20revised=20new=20new=20chart er=20text |Sender:=20; bh=oJRABjnjLLs94JbR3Hxds81fyFLPkvR3vl7lPwiO1uQ=; b=YHlCThoKmUFZzMHYxOXKFFjP3gLSbToRJstHBKzKoT9fiw/yIp1FwhoZFp JARvV5qXdQB1mJvBdqpRRzt2FJh+I3BAKbmqXn9r8tCCcq9Q7ymI1Dqd4gAs rg3/t4aZR+; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] revised new new charter text X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Mark and all I concur with Carl on this all the way through. What does it take now to move forward with this charter? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of carl williams >Sent: mardi 24 juin 2008 00:21 >To: Mark Townsley (townsley); 'Carsten Bormann' >Cc: '6lowpan' >Subject: Re: [6lowpan] revised new new charter text > > > >Hi Mark and Carsten, > > I agree with the current charter. There was an item that Geoff Mulligan >presented on mobility and sensors at the last IETF 6lowpan meeting. It is >not a priority currently but will be in the future. So it is good that >while the working group keeps on track with current work items that we may >continue to discuss the subject that Geoff raised at the last meeting if >time permits (and we continue to make progress on current agenda items). > > I agree with your proposal for discussing work and thanks for the hard >work on the getting a new charter. > > Carl > > >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf >Of Mark Townsley >Sent: Thursday, June 19, 2008 8:02 AM >To: Carsten Bormann >Cc: 6lowpan >Subject: Re: [6lowpan] revised new new charter text > >Carsten Bormann wrote: >> On Jun 19 2008, at 15:00, Pascal Thubert (pthubert) wrote: >> >> >>> The way the charter is worded we can do nothing on these issues >>> because >>> we are not chartered to and that would be distraction to the chartered >>> items. >>> >As long as they are not a distraction, then you can work on whatever you >would like :-) > >In the past (2 or 3 years ago?) I did slap a mandate on this group to >stop talking about unchartered work before the most basic deliverables >were achieved. That time has passed, and the floodgates are open again. >Please contribute and do work on whatever you think is important. I'd >like to take the current charter to the IESG as is if there is consensus >to do so, keeping in mind that as long as you stay on track as a WG, and >as long as the discussion of unchartered work isn't seemingly holding up >progress on chartered work, you can discuss and work on whatever you >wish on this list and in the WG meetings. > >Thanks, > >- Mark >> Pascal, >> >> this is not the way we want to work here -- the charter items are the >> ones we *promise* to deliver; but we do have a maintenance item in >> there, and we can use that to build problem statements and even >> solutions. >> >> In other words, I would look forward to a session slot in Dublin where >> we can make progress on this. >> But I don't want to hold up the charter now. >> >> Gruesse, Carsten >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 2 14:55:47 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6773A6897; Wed, 2 Jul 2008 14:55:47 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3C83A6897 for <6lowpan@core3.amsl.com>; Wed, 2 Jul 2008 14:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vpg5bbsSKx-Z for <6lowpan@core3.amsl.com>; Wed, 2 Jul 2008 14:55:45 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 4718C3A6880 for <6lowpan@ietf.org>; Wed, 2 Jul 2008 14:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m626xZh4007188; Wed, 2 Jul 2008 08:59:39 +0200 (CEST) Message-Id: From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 2 Jul 2008 08:59:35 +0200 References: <20080702065402.2FE973A69F4@core3.amsl.com> X-Mailer: Apple Mail (2.924) Cc: Carsten Bormann Subject: [6lowpan] Extension headers for 6lowpan packets X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Lowpanners, I have just submitted a new I-D, draft-bormann-6lowpan-ext-hdr-00.txt Title: Extension headers for 6lowpan Abstract: 6lowpan applications sometimes need to include application-specific information in layer 2 packets that are intended to be processed as 6lowpan packets. This document specifies a way to include this information in a 6lowpan packet in such a way that it can be ignored by implementations that don't care for it. Looking forward to any comments. Are these kind of extension headers a useful thing to have? Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 3 03:01:59 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67A2A3A6975; Thu, 3 Jul 2008 03:01:59 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA34A3A6D04 for <6lowpan@core3.amsl.com>; Thu, 3 Jul 2008 03:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd3shWW22UDA for <6lowpan@core3.amsl.com>; Thu, 3 Jul 2008 03:01:58 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id C34BC3A6D16 for <6lowpan@ietf.org>; Thu, 3 Jul 2008 03:01:42 -0700 (PDT) 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 m63A1kuN004078; Thu, 3 Jul 2008 04:01:47 -0600 (MDT) From: Geoff Mulligan To: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Date: Thu, 03 Jul 2008 04:01:47 -0600 Message-Id: <1215079307.27863.24.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: [6lowpan] draft-bormann-6lowpan-ext-hdr-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Carsten, I think that this is a neat idea. As you state there may be many layer 2 mesh implementations that need some sort of intermediate header and for them all to use NALP seems like a bad idea. When we talked about this I thought we considered using the reserved bits of NALP to carry the length value so that 0010xxxx would be the extension header identifier and length. I'm not opposed to use 1101xxxx, I was just wondering about the change. I'm not sure I like the idea of splitting headers greater than 16 bytes into two pieces with two extension headers. What about again using an escape value of 1111 to indicate the length is 15 plus the next byte. This has the advantage that the headers don't have to be broken into artificial pieces. If we don't use the NALP reserved space, has anyone considered allowing addresses in this space to be registered for specific layer 2 mesh protocols and to extend it to another byte if the 6 lower bits are all 1 - 00111111 Unfortunately, it seems though that at the last meeting in Nice ISA100 decided NOT to utilize this idea that we had worked out and plan to continue to just use NALP. Oh well, I think that this is still an excellent extension to 4944 and may be used by others. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 3 05:43:18 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780143A68BD; Thu, 3 Jul 2008 05:43:18 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2B83A6900 for <6lowpan@core3.amsl.com>; Thu, 3 Jul 2008 05:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqcyoWA6+rjT for <6lowpan@core3.amsl.com>; Thu, 3 Jul 2008 05:43:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9F5973A68BD for <6lowpan@ietf.org>; Thu, 3 Jul 2008 05:43:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,742,1204502400"; d="scan'208";a="13391501" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2008 12:43:23 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m63ChNWn026820; Thu, 3 Jul 2008 14:43:23 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m63ChNdO010170; Thu, 3 Jul 2008 12:43:23 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jul 2008 14:43:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Jul 2008 14:42:43 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05E795F1@xmb-ams-337.emea.cisco.com> In-Reply-To: <1215079307.27863.24.camel@dellx1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] draft-bormann-6lowpan-ext-hdr-00.txt Thread-Index: Acjc8+ISjhb8jdKgRMGgQ5hDXZhhgQAFG0xA References: <1215079307.27863.24.camel@dellx1> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" , "Carsten Bormann" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 03 Jul 2008 12:43:23.0298 (UTC) FILETIME=[615D6020:01C8DD0A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2772; t=1215089003; x=1215953003; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20draft-bormann-6lowpan-ext-h dr-00.txt |Sender:=20; bh=GgcaPcU3G9yQWWE9xrFLnuiEC+i11BVKWngbYu9rpE0=; b=jcDZW80/jKMDTVoGN53kS0E1l16NQw6CHUaRh+l4sumjX/yjnuTyA/tRFj 5EIuZOSWoyVkr4ldkeEPWnFwNfEsf0EFKw3L0blBfPTW6gt1LpFwFX+TOSqx eMGR/hghUn; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "Polyzois, Christos A" , Jay Werb , Jose.Gutierrez@emerson.com Subject: Re: [6lowpan] draft-bormann-6lowpan-ext-hdr-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Geoff and Carsten: I agree with Geoff it's a great idea and we need to move forward with it and work out the details. In particular we need to be consistent with the possibilities that can be encoded of destination options in IPv6 headers and specify whether the unrecognized option can be skipped or not. What was decided at the ISA meeting in Nice is that 6LoWPAN is applied within the ISA100.11a Data Link as opposed to flat over 802.15.4 MAC. As a result 6LowPAN does not apply to the DL headers themselves so NaLP is not used there. There is no way for a node that does not have a DL layer to decrypt and parse the DL frames anyway. But ISA100.11a wishes to maintain the capability to relay a 6LowPAN packet between an ISA DL link and a plain 802.15.4 link. So ISA100.11a still wishes to converge with 6LoWPAN for the content of the frames. The new format can still be very useful for ISA100.11a, in particular to optimize the compression of the flow label which is still based on NaLP at this stage of the specification. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Geoff Mulligan >Sent: jeudi 3 juillet 2008 12:02 >To: Carsten Bormann; 6lowpan >Subject: [6lowpan] draft-bormann-6lowpan-ext-hdr-00.txt > >Carsten, > I think that this is a neat idea. As you state there may be many >layer 2 mesh implementations that need some sort of intermediate header >and for them all to use NALP seems like a bad idea. > >When we talked about this I thought we considered using the reserved >bits of NALP to carry the length value so that 0010xxxx would be the >extension header identifier and length. I'm not opposed to use >1101xxxx, I was just wondering about the change. > >I'm not sure I like the idea of splitting headers greater than 16 bytes >into two pieces with two extension headers. What about again using an >escape value of 1111 to indicate the length is 15 plus the next byte. >This has the advantage that the headers don't have to be broken into >artificial pieces. > >If we don't use the NALP reserved space, has anyone considered allowing >addresses in this space to be registered for specific layer 2 mesh >protocols and to extend it to another byte if the 6 lower bits are all 1 >- 00111111 > >Unfortunately, it seems though that at the last meeting in Nice ISA100 >decided NOT to utilize this idea that we had worked out and plan to >continue to just use NALP. Oh well, I think that this is still an >excellent extension to 4944 and may be used by others. > > geoff > > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 3 14:08:22 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F88E3A692A; Thu, 3 Jul 2008 14:08:22 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862773A692A for <6lowpan@core3.amsl.com>; Thu, 3 Jul 2008 14:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXKhjGkND8Ng for <6lowpan@core3.amsl.com>; Thu, 3 Jul 2008 14:08:20 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id E02D03A68B4 for <6lowpan@ietf.org>; Thu, 3 Jul 2008 14:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m63ArrpR008296; Thu, 3 Jul 2008 12:53:56 +0200 (CEST) Message-Id: <9A8C43AC-F666-4DE2-925B-D24C5A944427@tzi.org> From: Carsten Bormann To: Geoff Mulligan In-Reply-To: <1215079307.27863.24.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 3 Jul 2008 12:53:53 +0200 References: <1215079307.27863.24.camel@dellx1> X-Mailer: Apple Mail (2.926) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] draft-bormann-6lowpan-ext-hdr-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Jul 03 2008, at 12:01, Geoff Mulligan wrote: > Carsten, > I think that this is a neat idea. As you state there may be many > layer 2 mesh implementations that need some sort of intermediate > header > and for them all to use NALP seems like a bad idea. > > When we talked about this I thought we considered using the reserved > bits of NALP to carry the length value so that 0010xxxx would be the > extension header identifier and length. I'm not opposed to use > 1101xxxx, I was just wondering about the change. Well, I thought NALP was "Not a Lowpan", so given that this packet *is* a Lowpan packet, the number space sounded inappropriate. > > I'm not sure I like the idea of splitting headers greater than 16 > bytes > into two pieces with two extension headers. What about again using an > escape value of 1111 to indicate the length is 15 plus the next byte. > This has the advantage that the headers don't have to be broken into > artificial pieces. The pieces may not at all be artificial, though. Having an escape value to use more than 16 bytes out of ~80 does sound like unneeded complexity to me. > If we don't use the NALP reserved space, has anyone considered > allowing > addresses in this space to be registered for specific layer 2 mesh > protocols and to extend it to another byte if the 6 lower bits are > all 1 > - 00111111 Let's do that when that other mesh protocol rings at the front door... > Unfortunately, it seems though that at the last meeting in Nice ISA100 > decided NOT to utilize this idea that we had worked out and plan to > continue to just use NALP. Oh well, I think that this is still an > excellent extension to 4944 and may be used by others. ISA100 might still be able to use new input like this, if we agree that this is the way forward. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 4 03:26:37 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCED3A6B68; Fri, 4 Jul 2008 03:26:37 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16C713A6B6B for <6lowpan@core3.amsl.com>; Fri, 4 Jul 2008 03:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7+S+flb8kvq for <6lowpan@core3.amsl.com>; Fri, 4 Jul 2008 03:26:35 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A84363A6B63 for <6lowpan@ietf.org>; Fri, 4 Jul 2008 03:26:33 -0700 (PDT) Received: from h14524.gprs.dnafinland.fi (h14524.gprs.dnafinland.fi [87.93.145.24]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m64AQO7J015028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jul 2008 13:26:25 +0300 Message-ID: <486DFA12.9000602@sensinode.com> Date: Fri, 04 Jul 2008 13:23:14 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4856A7F7.4060407@sun.com> <7892795E1A87F04CADFCCF41FADD00FC05D6EFA5@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05D6EFA5@xmb-ams-337.emea.cisco.com> Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification fordraft-nordmark-6lowpan-reg-00] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi, IMHO Erik has the model right regarding multiple routers. In dynamic radio environments or in applications with any kind of mobility (e.g. Asset Management) the ability to register with multiple routers is useful. I also like the new registration message, a clean solution. - Zach Pascal Thubert (pthubert) wrote: > Hi Erik: > > I like very much your idea of a new registration message, that's cleaner > than changing NS like I do in the BbR proposal. > > OTOH, we do not seem to have the same model for the LoWPAN. In > particular, your draft seems to assume that the host would want to > reach numerous routers and register to them all. > > For instance, if you have an oil plant or a factory, it makes little > sense for a sensor node to go all across the factory across numerous > LoWPAN hops to register to a router that the node will never use. > > In my mind, the LoWPAN nodes form dynamic clusters around the nearest > router and use it. Routers might share a faster, powered network that is > called a backbone in ISA parlance, to discover and reach one another. > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Erik Nordmark >> Sent: lundi 16 juin 2008 19:51 >> To: 6lowpan@ietf.org >> Subject: [6lowpan] [Fwd: New Version Notification > fordraft-nordmark-6lowpan-reg-00] >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-nordmark-6lowpan-reg-00 >> Date: Mon, 16 Jun 2008 10:44:02 -0700 (PDT) >> From: IETF I-D Submission Tool >> To: Erik.Nordmark@sun.com >> CC: Erik.Nordmark@sun.com >> >> >> A new version of I-D, draft-nordmark-6lowpan-reg-00.txt has been >> successfuly submitted by Erik Nordmark and posted to the IETF > repository. >> Filename: draft-nordmark-6lowpan-reg >> Revision: 00 >> Title: Neighbor Discovery Registration Extension >> Creation_date: 2008-06-16 >> WG ID: Independent Submission >> Number_of_pages: 9 >> >> Abstract: >> In order to reduce Neighbor Discovery multicast messages it is useful >> if the routers on a link can maintain an authoritative list of the >> IPv6 and layer 2 addresses for all the hosts on the link. >> >> This draft specifies an extension to the Router Advertisement >> messages which trigger to hosts to send periodic registration >> messages which can be either unicast, multicast, or anycast. The >> protocol uses a soft-state approach to gather registration >> information. >> >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 4 09:04:43 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A403A6BA2; Fri, 4 Jul 2008 09:04:43 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1731F3A6BA6 for <6lowpan@core3.amsl.com>; Fri, 4 Jul 2008 09:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTzGLM6i08oo for <6lowpan@core3.amsl.com>; Fri, 4 Jul 2008 09:04:41 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by core3.amsl.com (Postfix) with ESMTP id 2D4583A6B4D for <6lowpan@ietf.org>; Fri, 4 Jul 2008 09:04:41 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so173966tib.25 for <6lowpan@ietf.org>; Fri, 04 Jul 2008 09:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=0lj9EYAbWd4fV/3dgWLqC5ey7r8jOdSEpCzpkWdezO8=; b=T9ZIdE3uTLXzeuRWtYmk8auf2/tkWIN18Gjj3pjcEfkHBJsArAcVRxtD2FXaEP3CuH xUWJ9YsfiUW+A6Vd297T6s30lqW9vhWrW3w42xFi6SDQnVaIBaAWSPVolw7Bg8SiavIj psRZsONC6z1EOnU1eKt/NaQ2w/8Itm/Y2IytM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=aAhWBJgIqqlvDArqdpaKqCPlVnDOb5ZKqNhMzMXikQAJwIrEOb9yoEn/uQJiSlIY3P 2oskAdwiE43eINLlwB/ZrDRJgeYH7WYMD4xPLkSRv6+6lHH0kYtnWR5tyTcMwHWo+GY3 okl5HSD1TCyuKw7TZLE8dzij6tiY4EKAp7Kfs= Received: by 10.110.5.18 with SMTP id 18mr312149tie.43.1215187483872; Fri, 04 Jul 2008 09:04:43 -0700 (PDT) Received: by 10.110.60.20 with HTTP; Fri, 4 Jul 2008 09:04:43 -0700 (PDT) Message-ID: <66df4faf0807040904v62e9e89ay394f326b9402535d@mail.gmail.com> Date: Fri, 4 Jul 2008 09:04:43 -0700 From: "Mustafa Hasan" To: 6lowpan@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [6lowpan] Regarding coexistence with 802.11n X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Dear 6lowpaner, I need little help regarding the coexistence issue of ISM Band with other ISM, especially with the 802.11n, 802.11b. I want to know what are the factor is going to save the 802.15.4 fighting with others frequency. Thanks in Advance... Regards M. Hasan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Jul 6 23:54:52 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EFD3A69F8; Sun, 6 Jul 2008 23:54:52 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F883A69F8 for <6lowpan@core3.amsl.com>; Sun, 6 Jul 2008 23:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUgX6W7lxU7o for <6lowpan@core3.amsl.com>; Sun, 6 Jul 2008 23:54:49 -0700 (PDT) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by core3.amsl.com (Postfix) with ESMTP id 2E4813A69CA for <6lowpan@ietf.org>; Sun, 6 Jul 2008 23:54:48 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id m676sU8T007466; Mon, 7 Jul 2008 09:54:30 +0300 Received: from smtp-2.hut.fi ([130.233.228.92]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 07267-23-15; Mon, 7 Jul 2008 09:54:30 +0300 (EEST) Received: from [NON-IPv4] (vipunen.hut.fi [130.233.228.9]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id m676rU5u007134; Mon, 7 Jul 2008 09:53:30 +0300 Date: Mon, 7 Jul 2008 09:53:30 +0300 (EEST) From: Jukka MJ Manner To: "Pascal Thubert (pthubert)" In-Reply-To: <0K3F0099OKSXUO@smtp02.hut-mail> Message-ID: References: <1215079307.27863.24.camel@dellx1> <0K3F0099OKSXUO@smtp02.hut-mail> MIME-Version: 1.0 X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: Jay Werb , "Polyzois, Christos A" , Carsten Bormann , 6lowpan <6lowpan@ietf.org>, Jose.Gutierrez@emerson.com Subject: Re: [6lowpan] draft-bormann-6lowpan-ext-hdr-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi, About the skipping of extension headers, in the NSIS protocol work we used two flag bits (A&B) that tell a receiving node what to do when it parses through a header and finds an unrecognized header: AB=00 ("Mandatory"): If the object is not understood, the entire message containing it MUST be rejected, and an error message sent back. AB=01 ("Ignore"): If the object is not understood, it MUST be deleted and the rest of the message processed as usual. AB=10 ("Forward"): If the object is not understood, it MUST be retained unchanged in any message forwarded as a result of message processing, but not stored locally. I wonder if something similar could be used in 6lowpan? Cheers, Jukka On Thu, 3 Jul 2008, Pascal Thubert (pthubert) wrote: > Hi Geoff and Carsten: > > I agree with Geoff it's a great idea and we need to move forward with it > and work out the details. > In particular we need to be consistent with the possibilities that can > be encoded of destination options in IPv6 headers and specify whether > the unrecognized option can be skipped or not. > > What was decided at the ISA meeting in Nice is that 6LoWPAN is applied > within the ISA100.11a Data Link as opposed to flat over 802.15.4 MAC. As > a result 6LowPAN does not apply to the DL headers themselves so NaLP is > not used there. There is no way for a node that does not have a DL layer > to decrypt and parse the DL frames anyway. > > But ISA100.11a wishes to maintain the capability to relay a 6LowPAN > packet between an ISA DL link and a plain 802.15.4 link. So ISA100.11a > still wishes to converge with 6LoWPAN for the content of the frames. > > The new format can still be very useful for ISA100.11a, in particular to > optimize the compression of the flow label which is still based on NaLP > at this stage of the specification. > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Geoff Mulligan >> Sent: jeudi 3 juillet 2008 12:02 >> To: Carsten Bormann; 6lowpan >> Subject: [6lowpan] draft-bormann-6lowpan-ext-hdr-00.txt >> >> Carsten, >> I think that this is a neat idea. As you state there may be many >> layer 2 mesh implementations that need some sort of intermediate header >> and for them all to use NALP seems like a bad idea. >> >> When we talked about this I thought we considered using the reserved >> bits of NALP to carry the length value so that 0010xxxx would be the >> extension header identifier and length. I'm not opposed to use >> 1101xxxx, I was just wondering about the change. >> >> I'm not sure I like the idea of splitting headers greater than 16 bytes >> into two pieces with two extension headers. What about again using an >> escape value of 1111 to indicate the length is 15 plus the next byte. >> This has the advantage that the headers don't have to be broken into >> artificial pieces. >> >> If we don't use the NALP reserved space, has anyone considered allowing >> addresses in this space to be registered for specific layer 2 mesh >> protocols and to extend it to another byte if the 6 lower bits are all > 1 >> - 00111111 >> >> Unfortunately, it seems though that at the last meeting in Nice ISA100 >> decided NOT to utilize this idea that we had worked out and plan to >> continue to just use NALP. Oh well, I think that this is still an >> excellent extension to 4944 and may be used by others. >> >> geoff >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 7 00:56:09 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A273A6A53; Mon, 7 Jul 2008 00:56:09 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D0F3A6A53 for <6lowpan@core3.amsl.com>; Mon, 7 Jul 2008 00:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPc4j3nKMHcx for <6lowpan@core3.amsl.com>; Mon, 7 Jul 2008 00:56:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6410C3A6A4C for <6lowpan@ietf.org>; Mon, 7 Jul 2008 00:56:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,314,1212364800"; d="scan'208";a="13609869" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2008 07:56:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m677u5Ee007881; Mon, 7 Jul 2008 09:56:05 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m677u5eQ015384; Mon, 7 Jul 2008 07:56:05 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 09:56:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 09:55:26 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05EC12E8@xmb-ams-337.emea.cisco.com> In-Reply-To: <486DFA12.9000602@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Fwd: New Version Notification fordraft-nordmark-6lowpan-reg-00] Thread-Index: Acjdw/WTIiohp4mfSvWBSVXfkiurXwCPyJsw References: <4856A7F7.4060407@sun.com> <7892795E1A87F04CADFCCF41FADD00FC05D6EFA5@xmb-ams-337.emea.cisco.com> <486DFA12.9000602@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" X-OriginalArrivalTime: 07 Jul 2008 07:56:05.0677 (UTC) FILETIME=[E89825D0:01C8E006] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4948; t=1215417365; x=1216281365; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20[Fwd=3A=20New=20Version=20N otification=09fordraft-nordmark-6lowpan-reg-00] |Sender:=20; bh=Dac1Y0GD9zZSqSvgRs0cmAP9HYfY1GEwMbs+MTWBMxM=; b=nJkF+86ySCuPuYyCH11p9HltKS0rqTUZ5Y4KHFL0uSg7L8xQMBJStMYXMR nIsaBw1CBwLmoaNXbkpCBIPbI6DmgZuOzLDfklrz++Judj1LZodaFM37GWpb 75rhemAkEg; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification fordraft-nordmark-6lowpan-reg-00] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Zach: There are already a number of industrial solutions that are designed or being designed to use multiple routers, and that covers not only the registration by forwarding capabilities such as bi-(pluri)-casting. What I'm saying is that there is a difference between binding to one or more routers that are closeby and all the routers across a factory plant. IOW 802.15.4 is not Ethernet. Considering the cost of maintaining each binding, I'd suggest that a LoWPAN node binds to one or very few routers that it selects based on the signals (L2-3 triggers) it gets from those routers. I can see that a router suggests alternate routers in the vincinity (maybe using alternate radios) but there a point where other protocols, 802.21 in this specific case, are already available for the job. The router, though, is not necessarily in a good position to suggest the alternate routers that would be close to the node in terms of energy. When digging into the gory details, one has to figure which backbone router terminates the 6LoWPAN shim and in particular the fragmentation. There must be one router somewhere that owns the buffers where a given packet gets recomposed and expanded. This is one reason why the BbR draft has a primary router. When you keep digging, you find value in including the backbone in the scope of the node's link local address. We can expand that in a separate thread if you wish. In any case, this is the rationale behind the primary router defending the node's address on the backbone using proxy ND. Pascal >-----Original Message----- >From: Zach Shelby [mailto:zach@sensinode.com] >Sent: vendredi 4 juillet 2008 12:23 >To: Pascal Thubert (pthubert) >Cc: Erik Nordmark; 6lowpan@ietf.org >Subject: Re: [6lowpan] [Fwd: New Version Notification fordraft-nordmark-6lowpan-reg-00] > >Hi, > >IMHO Erik has the model right regarding multiple routers. In dynamic >radio environments or in applications with any kind of mobility (e.g. >Asset Management) the ability to register with multiple routers is >useful. I also like the new registration message, a clean solution. > >- Zach > >Pascal Thubert (pthubert) wrote: >> Hi Erik: >> >> I like very much your idea of a new registration message, that's cleaner >> than changing NS like I do in the BbR proposal. >> >> OTOH, we do not seem to have the same model for the LoWPAN. In >> particular, your draft seems to assume that the host would want to >> reach numerous routers and register to them all. >> >> For instance, if you have an oil plant or a factory, it makes little >> sense for a sensor node to go all across the factory across numerous >> LoWPAN hops to register to a router that the node will never use. >> >> In my mind, the LoWPAN nodes form dynamic clusters around the nearest >> router and use it. Routers might share a faster, powered network that is >> called a backbone in ISA parlance, to discover and reach one another. >> >> Pascal >> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Erik Nordmark >>> Sent: lundi 16 juin 2008 19:51 >>> To: 6lowpan@ietf.org >>> Subject: [6lowpan] [Fwd: New Version Notification >> fordraft-nordmark-6lowpan-reg-00] >>> >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-nordmark-6lowpan-reg-00 >>> Date: Mon, 16 Jun 2008 10:44:02 -0700 (PDT) >>> From: IETF I-D Submission Tool >>> To: Erik.Nordmark@sun.com >>> CC: Erik.Nordmark@sun.com >>> >>> >>> A new version of I-D, draft-nordmark-6lowpan-reg-00.txt has been >>> successfuly submitted by Erik Nordmark and posted to the IETF >> repository. >>> Filename: draft-nordmark-6lowpan-reg >>> Revision: 00 >>> Title: Neighbor Discovery Registration Extension >>> Creation_date: 2008-06-16 >>> WG ID: Independent Submission >>> Number_of_pages: 9 >>> >>> Abstract: >>> In order to reduce Neighbor Discovery multicast messages it is useful >>> if the routers on a link can maintain an authoritative list of the >>> IPv6 and layer 2 addresses for all the hosts on the link. >>> >>> This draft specifies an extension to the Router Advertisement >>> messages which trigger to hosts to send periodic registration >>> messages which can be either unicast, multicast, or anycast. The >>> protocol uses a soft-state approach to gather registration >>> information. >>> >>> >>> >>> >>> The IETF Secretariat. >>> >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > >-- >Zach Shelby | Head of Research | +358 40 7796297 >Sensinode Ltd. www.sensinode.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 7 06:24:42 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 493B73A6A4C; Mon, 7 Jul 2008 06:24:42 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27FB3A6A4C for <6lowpan@core3.amsl.com>; Mon, 7 Jul 2008 06:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NdveWASZgTi for <6lowpan@core3.amsl.com>; Mon, 7 Jul 2008 06:24:40 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 8F7613A6A48 for <6lowpan@ietf.org>; Mon, 7 Jul 2008 06:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m677An9T029170; Mon, 7 Jul 2008 09:10:52 +0200 (CEST) Message-Id: From: Carsten Bormann To: Jukka MJ Manner In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 7 Jul 2008 09:10:48 +0200 References: <1215079307.27863.24.camel@dellx1> <0K3F0099OKSXUO@smtp02.hut-mail> X-Mailer: Apple Mail (2.926) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] draft-bormann-6lowpan-ext-hdr-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jukka, > unrecognized header indeed, this would normally be a consideration for an extension header, together with a regime for administration of an extension number space. However, running the full gamut of protocol design considerations explicitly wasn't my objective here. My assumption was that management of extensions and their semantics was part of setting up the network. Specifically: > AB=00 ("Mandatory"): If the object is not understood, the entire > message containing it MUST be rejected, and an error message sent > back. If that is the objective, you might as well use NALP. > AB=01 ("Ignore"): If the object is not understood, it MUST be > deleted > and the rest of the message processed as usual. This is the assumption here. > AB=10 ("Forward"): If the object is not understood, it MUST be > retained unchanged in any message forwarded as a result of message > processing, but not stored locally. I'm not sure that is needed (or even possible, without imposing way more structure on the extension headers). So my question to the list would be: Is the minimal extension header I proposed the right approach or do we really have a requirement for the full benefits of extensibility and composability that a full-blown extension header approach would bring? Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 7 15:32:28 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C5028C308; Mon, 7 Jul 2008 15:32:28 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9AC28C28D for <6lowpan@core3.amsl.com>; Mon, 7 Jul 2008 15:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id we5UyH7c85tK for <6lowpan@core3.amsl.com>; Mon, 7 Jul 2008 15:32:26 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id 7E2FF28C31D for <6lowpan@ietf.org>; Mon, 7 Jul 2008 15:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m67MVc67007721; Tue, 8 Jul 2008 00:31:41 +0200 (CEST) Message-Id: <7FC89E1C-CA79-45A1-9E08-4D30F4128FC2@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 8 Jul 2008 00:31:37 +0200 References: <20080707222356.1CC263A69D6@core3.amsl.com> X-Mailer: Apple Mail (2.926) Cc: Carsten Bormann Subject: [6lowpan] Context-based header compression X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Lowpanners, I submitted a short draft on a simple header compression scheme. > Filename: draft-bormann-6lowpan-cbhc-00.txt > Title: Context-based Header Compression for 6lowpan > > Abstract: > 6lowpan (RFC 4944) so far has only defined stateless forms of header > compression. This document specifies how a node and a router can > agree on state that will allow much better header compression of > global addresses. I think this could combine well with draft-hui-6lowpan-hc-00.txt, but I haven't really done the integration work. This draft is still in a very early stage. Looking forward to comments. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 7 19:12:22 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C17828C3B9; Mon, 7 Jul 2008 19:12:22 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03ED28C3B9 for <6lowpan@core3.amsl.com>; Mon, 7 Jul 2008 19:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM7ju7haFEwt for <6lowpan@core3.amsl.com>; Mon, 7 Jul 2008 19:12:20 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id D962128C3AB for <6lowpan@ietf.org>; Mon, 7 Jul 2008 19:12:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id F28F8AF87D; Mon, 7 Jul 2008 19:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJy8K9se3bDe; Mon, 7 Jul 2008 19:12:28 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-88-226.dsl.pltn13.pacbell.net [71.142.88.226]) by mail.sf.archrock.com (Postfix) with ESMTP id 4A840AF86C; Mon, 7 Jul 2008 19:12:28 -0700 (PDT) Message-Id: From: Jonathan Hui To: Carsten Bormann In-Reply-To: <7FC89E1C-CA79-45A1-9E08-4D30F4128FC2@tzi.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 7 Jul 2008 19:12:25 -0700 References: <20080707222356.1CC263A69D6@core3.amsl.com> <7FC89E1C-CA79-45A1-9E08-4D30F4128FC2@tzi.org> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Context-based header compression X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten, I'm supportive of this effort and have been working on similar improvements to the HC draft based on feedback from the last WG meeting. Support for different context IDs makes setup and teardown of context clean, as mentioned in your I.D. RAs are a natural place to advertise context information. Let me put some thoughts out on the encoding. HC would benefit greatly by expanding the encoding to two bytes. For each address, 2 bits are already used to indicate the compressed address mode (0-bit, 16-bit, 64-bit, and full 128-bit). We can augment the encoding by adding another 2 bits for each address to carry the context ID. This approach is similar to yours, but differs in that it explicitly separates the context ID space from the address compression mode. In my mind, the compression prefix and address compression mode are orthogonal concepts. A single context ID can be used to support different address compression modes. For example, a single /64 prefix could be used along with 64-bit, 16-bit, or 0-bit compressed addresses. We could even reserve context ID 0 to be the link-local prefix. Using the same encoding for link-local and global addresses reduces encoding/decoding requirements. Here's a proposed encoding format that incorporates the context ID mechanism, as well as a couple other improvements. Specifically, I've added a bit to HLIM based on past discussions within the WG. I've also used separate bits for Traffic Class and Flow Label. There's 3 extra bits, so there's still room to play with it a bit. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | T |VF |NH | HLIM | rsv | SC | SCtxt | DC | DCtxt | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ -- Jonathan Hui On Jul 7, 2008, at 3:31 PM, Carsten Bormann wrote: > Lowpanners, > > I submitted a short draft on a simple header compression scheme. > >> Filename: draft-bormann-6lowpan-cbhc-00.txt >> Title: Context-based Header Compression for 6lowpan >> >> Abstract: >> 6lowpan (RFC 4944) so far has only defined stateless forms of header >> compression. This document specifies how a node and a router can >> agree on state that will allow much better header compression of >> global addresses. > > I think this could combine well with draft-hui-6lowpan-hc-00.txt, > but I haven't really done the integration work. > > This draft is still in a very early stage. Looking forward to > comments. > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 8 03:41:51 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB15A3A68A3; Tue, 8 Jul 2008 03:41:51 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393933A68A3 for <6lowpan@core3.amsl.com>; Tue, 8 Jul 2008 03:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQGDUdjgcbhN for <6lowpan@core3.amsl.com>; Tue, 8 Jul 2008 03:41:46 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 043D23A6780 for <6lowpan@ietf.org>; Tue, 8 Jul 2008 03:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m68AVJAZ013732; Tue, 8 Jul 2008 12:31:22 +0200 (CEST) Message-Id: From: Carsten Bormann To: Jonathan Hui In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 8 Jul 2008 12:31:15 +0200 References: <20080707222356.1CC263A69D6@core3.amsl.com> <7FC89E1C-CA79-45A1-9E08-4D30F4128FC2@tzi.org> X-Mailer: Apple Mail (2.926) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Context-based header compression X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan, thanks for the comments. On Jul 08 2008, at 04:12, Jonathan Hui wrote: > it explicitly separates the context ID space from the address > compression mode. In my mind, the compression prefix and address > compression mode are orthogonal concepts. A single context ID can be > used to support different address compression modes. For example, a > single /64 prefix could be used along with 64-bit, 16-bit, or 0-bit > compressed addresses. Do you have an example how that would work in practice? I tried to separate out the contexts for the different prefix lengths because I couldn't quite imagine a useful case where you would use the same prefix bits at different lengths. The separation allows a larger number of contexts to be available (while spending the same small number of per-packet bits), which helps with transitions between different context settings. If I correctly read your diagram, you would only have four contexts; given that half of them might be tied up in a transition, this would leave about two, one for the prefix of the local link and one for exactly one potential correspondent. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 8 09:12:26 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8593A6810; Tue, 8 Jul 2008 09:12:26 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04EC3A6810 for <6lowpan@core3.amsl.com>; Tue, 8 Jul 2008 09:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13SDx003oNAC for <6lowpan@core3.amsl.com>; Tue, 8 Jul 2008 09:12:25 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 3035A3A6803 for <6lowpan@ietf.org>; Tue, 8 Jul 2008 09:12:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id EC5A4AF8A4; Tue, 8 Jul 2008 09:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNGo8+YOpdhP; Tue, 8 Jul 2008 09:12:34 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archedrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 41542AF897; Tue, 8 Jul 2008 09:12:34 -0700 (PDT) Message-Id: From: Jonathan Hui To: Carsten Bormann In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 8 Jul 2008 09:12:33 -0700 References: <20080707222356.1CC263A69D6@core3.amsl.com> <7FC89E1C-CA79-45A1-9E08-4D30F4128FC2@tzi.org> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Context-based header compression X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten, On Jul 8, 2008, at 3:31 AM, Carsten Bormann wrote: > On Jul 08 2008, at 04:12, Jonathan Hui wrote: >> it explicitly separates the context ID space from the address >> compression mode. In my mind, the compression prefix and address >> compression mode are orthogonal concepts. A single context ID can >> be used to support different address compression modes. For >> example, a single /64 prefix could be used along with 64-bit, 16- >> bit, or 0-bit compressed addresses. > > Do you have an example how that would work in practice? Consider a::b where a is a /64 prefix and b is the 64-bit IID. 1) all 64-bits of b carried in-line in the compressed IPv6 header. 2) lower 16-bits of b carried in-line in the compressed IPv6 header. Other 48-bits are derived using the PAN ID (if we follow the IID generation guidelines of RFC 4944). 3) 0-bits of b carried in-line in compressed IPv6 header. b is derived from either the 6lowpan mesh header or the 802.15.4 link header. I don't think we should be coupling the context ID with the address compression mode. Am I missing something? Or is this a plausible scenario? -- Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 8 09:23:45 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC3728C14D; Tue, 8 Jul 2008 09:23:45 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC5328C14D for <6lowpan@core3.amsl.com>; Tue, 8 Jul 2008 09:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rg3absodaZL for <6lowpan@core3.amsl.com>; Tue, 8 Jul 2008 09:23:43 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 189D628C148 for <6lowpan@ietf.org>; Tue, 8 Jul 2008 09:23:43 -0700 (PDT) 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 m68GNhuH016049; Tue, 8 Jul 2008 10:23:43 -0600 (MDT) From: Geoff Mulligan To: Carsten Bormann In-Reply-To: References: <1215079307.27863.24.camel@dellx1> <0K3F0099OKSXUO@smtp02.hut-mail> Date: Tue, 08 Jul 2008 10:23:39 -0600 Message-Id: <1215534219.5878.54.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] draft-bormann-6lowpan-ext-hdr-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org I think the minimal extension header you proposed is right, though I'm still not convinced about breaking larger headers into pieces on 16 byte boundaries. geoff On Mon, 2008-07-07 at 09:10 +0200, Carsten Bormann wrote: > Hi Jukka, > > > unrecognized header > > indeed, this would normally be a consideration for an extension > header, together with a regime for administration of an extension > number space. > However, running the full gamut of protocol design considerations > explicitly wasn't my objective here. > My assumption was that management of extensions and their semantics > was part of setting up the network. > > Specifically: > > > AB=00 ("Mandatory"): If the object is not understood, the entire > > message containing it MUST be rejected, and an error message sent > > back. > > If that is the objective, you might as well use NALP. > > > AB=01 ("Ignore"): If the object is not understood, it MUST be > > deleted > > and the rest of the message processed as usual. > > This is the assumption here. > > > AB=10 ("Forward"): If the object is not understood, it MUST be > > retained unchanged in any message forwarded as a result of message > > processing, but not stored locally. > > I'm not sure that is needed (or even possible, without imposing way > more structure on the extension headers). > > So my question to the list would be: > Is the minimal extension header I proposed the right approach or do we > really have a requirement for the full benefits of extensibility and > composability that a full-blown extension header approach would bring? > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 8 16:47:08 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE9F28C378; Tue, 8 Jul 2008 16:47:08 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D92B28C3A1 for <6lowpan@core3.amsl.com>; Tue, 8 Jul 2008 16:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et8IpLjocy0d for <6lowpan@core3.amsl.com>; Tue, 8 Jul 2008 16:47:06 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id CC9D828C3A6 for <6lowpan@ietf.org>; Tue, 8 Jul 2008 16:46:02 -0700 (PDT) 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 m68NkCJ6019274; Tue, 8 Jul 2008 17:46:12 -0600 (MDT) From: Geoff Mulligan To: cabo@tzi.org, 6lowpan <6lowpan@ietf.org> In-Reply-To: <20080708231329.E83B728C29F@core3.amsl.com> References: <20080708231329.E83B728C29F@core3.amsl.com> Date: Tue, 08 Jul 2008 17:46:11 -0600 Message-Id: <1215560771.5878.89.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: Re: [6lowpan] WG Action: RECHARTER: IPv6 over Low power WPAN (6lowpan) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org YEAH!!!!! Now we really have to work! geoff On Tue, 2008-07-08 at 16:13 -0700, IESG Secretary wrote: > The charter of the IPv6 over Low power WPAN (6lowpan) working group in the > Internet Area of the IETF has been updated. For additional information, > please contact the Area Directors or the working group Chairs. > > IPv6 over Low power WPAN (6lowpan) > ---------------------------------- > Last Modified: 2008-06-26 > > Current Status: Active Working Group > > Chair(s): > Geoff Mulligan > Carsten Bormann > > Internet Area Director(s): > Jari Arkko > Mark Townsley > > Internet Area Advisor: > Mark Townsley > > Secretary(ies): > Christian Schumacher > > Mailing Lists: > > General Discussion: 6lowpan@lists.ietf.org > To Subscribe: 6lowpan-request@lists.ietf.org > In Body: subscribe > List Info: https://www1.ietf.org/mailman/listinfo/6lowpan > > 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 local area 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) > > 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 IEEE 1451.5 standard for wireless > transducers has a chapter for 6LoWPAN and the ISA SP100 standard for > wireless industrial networks has adopted 6LoWPAN for their network > layer. This working group is expected to coordinate and interact with > such groups. > > Description of Working Group: > ----------------------------- > > The Working Group has completed two RFCs: "IPv6 over Low-Power > Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, > Problem Statement, and Goals" (RFC4919) that documents and discusses > the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 > Networks" (RFC4944) which defines the format for the adaptation > between IPv6 and 802.15.4. > > The Working Group will generate the necessary documents to ensure > interoperable implementations of 6LoWPAN networks and will define the > necessary security and management protocols and constructs for > building 6LoWPAN networks, paying particular attention to protocols > already available. > > 6lowpan will work closely with the Routing Over Low power and Lossy > networks (roll) working group which is developing IPv6 routing > solutions for low power and lossy networks (LLNs). > > Work Items: > ----------- > > 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" > to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for > use specifically in low-power networks. This document (or documents) > will define how to bootstrap a 6LoWPAN network and explore ND > optimizations such as reusing the structure of the 802.15.4 network > (e.g., by using the coordinators), and reduce the need for multicast > by having devices talk to coordinators (without creating a single > point-of-failure, or changing the semantics of the IPv6 ND > multicasts). > This document or documents will be a proposed standard. > > 2. Produce "6LoWPAN Improved Header Compression" to describe mechanisms > to allow enhancements to the 6LoWPAN headers. Specifically this document > will > describe compression of addresses that are not link-local. Additionally > this document > may include other enhancements or optimizations of the HC1 or HC2 6LoWPAN > headers. > This document will be a proposed standard. > > 3. Produce "6LoWPAN Architecture" to describe the design and > implementation of 6LoWPAN networks. This document will cover the > concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such > as operation with sleeping nodes, network components (both battery- > and line-powered), addressing, and IPv4/IPv6 network connections. > This document will be informational. > > 4. As a separate Internet Draft, "6LoWPAN Routing Requirements" will > describe 6LoWPAN-specific requirements on routing protocols used in > 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. This > document will be created and owned by this working group but is expected > to > be reviewed by the ROLL WG. > This document will be informational. > > 5. Produce "Use Cases for 6LoWPAN" to define, for a small set of > applications with sufficiently unique requirements, how 6LoWPANs can > solve those requirements, and which protocols and configuration > variants can be used for these scenarios. The use cases will cover > protocols for transport, application layer, discovery, configuration > and commissioning. > This document will be informational. > > 6. Produce "6LoWPAN Security Analysis" to define the threat model of > 6LoWPANs, to document suitability of existing key management > schemes and to discuss bootstrapping/installation/commissioning/setup > issues. This document will be referenced from the "security > considerations" of the other 6LoWPAN documents. > This document will be informational. > > The working group will continue to reuse existing protocols and > mechanisms whenever reasonable and possible. > > Non-milestone work items: > ------------------------- > > The Working Group will keep two running, often-respun documents: > -- implementers guide, collecting clarifying information based on > input from implementers, in particular as it becomes available from > interoperability events. > -- interoperability guide, providing information for interoperability > events, such as temporary interoperability testing strategies or > information about test harnesses used for interoperability testing. > > Both documents will be WG documents, but their disposition is not > decided at this point (one example for such a document became RFC 4815 > after five years of maintenance and 22 revisions). > > Goals and Milestones: > --------------------- > > Aug 2008 Submit Improved Header Compression document to IESG for > consideration as a proposed standard > Aug 2008 Submit Security Analysis document to IESG for consideration as > an Informational RFC > Sep 2008 Submit Architecture document to IESG for consideration as an > Informational RFC > Sep 2008 Submit Routing Requirements document to IESG for consideration > as an Informational RFC > Nov 2008 Submit Bootstrapping and ND Optimizations document to IESG to be > > considered as a Proposed Standard > Dec 2008 Submit Use Case document to IESG as an Informational RFC _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 8 22:27:26 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4EB3A67A6; Tue, 8 Jul 2008 22:27:26 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284523A67A6 for <6lowpan@core3.amsl.com>; Tue, 8 Jul 2008 22:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.66 X-Spam-Level: X-Spam-Status: No, score=-5.66 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkC7u9-O+Jfa for <6lowpan@core3.amsl.com>; Tue, 8 Jul 2008 22:27:23 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 841403A6780 for <6lowpan@ietf.org>; Tue, 8 Jul 2008 22:27:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,329,1212364800"; d="scan'208";a="13608552" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Jul 2008 05:27:33 +0000 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 m695RXQD005084 for <6lowpan@ietf.org>; Wed, 9 Jul 2008 01:27:33 -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.13.8/8.13.8) with ESMTP id m695RXi3025923 for <6lowpan@ietf.org>; Wed, 9 Jul 2008 05:27:33 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 01:27:33 -0400 Received: from 10.21.124.38 ([10.21.124.38]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Jul 2008 05:26:33 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 09 Jul 2008 07:26:31 +0200 From: JP Vasseur To: <6lowpan@ietf.org> Message-ID: Thread-Topic: WG Action: RECHARTER: IPv6 over Low power WPAN (6lowpan) Thread-Index: AcjhhFgY2UvERcd35UaJhOh6DH4UMw== In-Reply-To: <20080708231329.E83B728C29F@core3.amsl.com> Mime-version: 1.0 X-OriginalArrivalTime: 09 Jul 2008 05:27:33.0223 (UTC) FILETIME=[7D2F1770:01C8E184] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7863; t=1215581253; x=1216445253; 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:=20FW=3A=20WG=20Action=3A=20RECHARTER=3A=20IPv6=20 over=20Low=20power=20WPAN=20(6lowpan)=20 |Sender:=20 |To:=20<6lowpan@ietf.org>; bh=AKntS8QM5UFwOV02Fx3m2JE+A/Nw0yJgTsq3pMr0KDo=; b=RoEory69DxBn2aJOAj9Ab0vs+Er3q+I5B48dK2rsyDrMzbbIIrE/wFfAzd UPqyB66onqlCInHZXNcEC5WYuITRo2QXTUDvjHwgYcjGHHPaumJ4MKbV6dPz jTPck0LLQG; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [6lowpan] FW: WG Action: RECHARTER: IPv6 over Low power WPAN (6lowpan) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org ------ Forwarded Message From: IESG Secretary Date: Tue, 8 Jul 2008 16:13:29 -0700 (PDT) To: IETF Announcement list Cc: <6lowpan@lists.ietf.org>, , Subject: WG Action: RECHARTER: IPv6 over Low power WPAN (6lowpan) The charter of the IPv6 over Low power WPAN (6lowpan) working group in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. IPv6 over Low power WPAN (6lowpan) ---------------------------------- Last Modified: 2008-06-26 Current Status: Active Working Group Chair(s): Geoff Mulligan Carsten Bormann Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley Secretary(ies): Christian Schumacher Mailing Lists: General Discussion: 6lowpan@lists.ietf.org To Subscribe: 6lowpan-request@lists.ietf.org In Body: subscribe List Info: https://www1.ietf.org/mailman/listinfo/6lowpan 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 local area 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) 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 IEEE 1451.5 standard for wireless transducers has a chapter for 6LoWPAN and the ISA SP100 standard for wireless industrial networks has adopted 6LoWPAN for their network layer. This working group is expected to coordinate and interact with such groups. Description of Working Group: ----------------------------- The Working Group has completed two RFCs: "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" (RFC4919) that documents and discusses the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" (RFC4944) which defines the format for the adaptation between IPv6 and 802.15.4. The Working Group will generate the necessary documents to ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available. 6lowpan will work closely with the Routing Over Low power and Lossy networks (roll) working group which is developing IPv6 routing solutions for low power and lossy networks (LLNs). Work Items: ----------- 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for use specifically in low-power networks. This document (or documents) will define how to bootstrap a 6LoWPAN network and explore ND optimizations such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts). This document or documents will be a proposed standard. 2. Produce "6LoWPAN Improved Header Compression" to describe mechanisms to allow enhancements to the 6LoWPAN headers. Specifically this document will describe compression of addresses that are not link-local. Additionally this document may include other enhancements or optimizations of the HC1 or HC2 6LoWPAN headers. This document will be a proposed standard. 3. Produce "6LoWPAN Architecture" to describe the design and implementation of 6LoWPAN networks. This document will cover the concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. This document will be informational. 4. As a separate Internet Draft, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. This document will be created and owned by this working group but is expected to be reviewed by the ROLL WG. This document will be informational. 5. Produce "Use Cases for 6LoWPAN" to define, for a small set of applications with sufficiently unique requirements, how 6LoWPANs can solve those requirements, and which protocols and configuration variants can be used for these scenarios. The use cases will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be informational. 6. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Non-milestone work items: ------------------------- The Working Group will keep two running, often-respun documents: -- implementers guide, collecting clarifying information based on input from implementers, in particular as it becomes available from interoperability events. -- interoperability guide, providing information for interoperability events, such as temporary interoperability testing strategies or information about test harnesses used for interoperability testing. Both documents will be WG documents, but their disposition is not decided at this point (one example for such a document became RFC 4815 after five years of maintenance and 22 revisions). Goals and Milestones: --------------------- Aug 2008 Submit Improved Header Compression document to IESG for consideration as a proposed standard Aug 2008 Submit Security Analysis document to IESG for consideration as an Informational RFC Sep 2008 Submit Architecture document to IESG for consideration as an Informational RFC Sep 2008 Submit Routing Requirements document to IESG for consideration as an Informational RFC Nov 2008 Submit Bootstrapping and ND Optimizations document to IESG to be considered as a Proposed Standard Dec 2008 Submit Use Case document to IESG as an Informational RFC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ------ End of Forwarded Message _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 9 06:56:14 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8314D3A6A42; Wed, 9 Jul 2008 06:56:14 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674603A686C for <6lowpan@core3.amsl.com>; Tue, 8 Jul 2008 08:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbjDUXOjLF64 for <6lowpan@core3.amsl.com>; Tue, 8 Jul 2008 08:02:15 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 5736D3A694D for <6lowpan@ietf.org>; Tue, 8 Jul 2008 08:02:15 -0700 (PDT) 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 m67FUhEx006939; Mon, 7 Jul 2008 09:30:43 -0600 (MDT) From: Geoff Mulligan To: Mustafa Hasan In-Reply-To: <66df4faf0807040904v62e9e89ay394f326b9402535d@mail.gmail.com> References: <66df4faf0807040904v62e9e89ay394f326b9402535d@mail.gmail.com> Date: Mon, 07 Jul 2008 09:30:38 -0600 Message-Id: <1215444638.5878.6.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 X-Mailman-Approved-At: Wed, 09 Jul 2008 06:56:12 -0700 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Regarding coexistence with 802.11n X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Appendix E of the 802.15.4 standard goes into detail on co-existence. On Fri, 2008-07-04 at 09:04 -0700, Mustafa Hasan wrote: > Dear 6lowpaner, > > I need little help regarding the coexistence issue of ISM Band with > other ISM, especially with the 802.11n, 802.11b. > > I want to know what are the factor is going to save the 802.15.4 > fighting with others frequency. > > > Thanks in Advance... > > > Regards > > M. Hasan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 10 00:33:17 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D97A3A687C; Thu, 10 Jul 2008 00:33:17 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067E43A687C for <6lowpan@core3.amsl.com>; Thu, 10 Jul 2008 00:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCK7X2UzCbZl for <6lowpan@core3.amsl.com>; Thu, 10 Jul 2008 00:33:14 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 91B603A67F2 for <6lowpan@ietf.org>; Thu, 10 Jul 2008 00:33:14 -0700 (PDT) Received: from dialtutka.bogus (line-5832.dyn.kponet.fi [85.29.69.30]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m6A7XBA9024450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2008 10:33:11 +0300 Message-ID: <487478C5.5080705@sensinode.com> Date: Wed, 09 Jul 2008 11:37:25 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4856A7F7.4060407@sun.com> <7892795E1A87F04CADFCCF41FADD00FC05D6EFA5@xmb-ams-337.emea.cisco.com> <486DFA12.9000602@sensinode.com> <7892795E1A87F04CADFCCF41FADD00FC05EC12E8@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05EC12E8@xmb-ams-337.emea.cisco.com> Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification fordraft-nordmark-6lowpan-reg-00] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Pascal, Pascal Thubert (pthubert) wrote: > Hi Zach: > > There are already a number of industrial solutions that are designed or > being designed to use multiple routers, and that covers not only the > registration by forwarding capabilities such as bi-(pluri)-casting. > > What I'm saying is that there is a difference between binding to one or > more routers that are closeby and all the routers across a factory > plant. IOW 802.15.4 is not Ethernet. Considering the cost of maintaining > each binding, I'd suggest that a LoWPAN node binds to one or very few > routers that it selects based on the signals (L2-3 triggers) it gets > from those routers. We agree completely then. My point was also that limited use of maintenance to one router in cases of no mobility or small networks and a few routers in order to speed up mobility between them or otherwise improve performance. Now there is the practical issue whether having multiple bindings actually improves performance when a node switches its point of attachment. > I can see that a router suggests alternate routers in the vincinity > (maybe using alternate radios) but there a point where other protocols, > 802.21 in this specific case, are already available for the job. The > router, though, is not necessarily in a good position to suggest the > alternate routers that would be close to the node in terms of energy. In my opinion the node is a better place to track candidate routers. > When digging into the gory details, one has to figure which backbone > router terminates the 6LoWPAN shim and in particular the fragmentation. > There must be one router somewhere that owns the buffers where a given > packet gets recomposed and expanded. This is one reason why the BbR > draft has a primary router. Primary router is definitely a must feature. > When you keep digging, you find value in including the backbone in the > scope of the node's link local address. We can expand that in a separate > thread if you wish. In any case, this is the rationale behind the > primary router defending the node's address on the backbone using proxy > ND. I definitely see the value in this and believe this will be the way to go for many applications. I'll pick your brain more about some BbR issues in Dublin. > Pascal - Zach >> -----Original Message----- >> From: Zach Shelby [mailto:zach@sensinode.com] >> Sent: vendredi 4 juillet 2008 12:23 >> To: Pascal Thubert (pthubert) >> Cc: Erik Nordmark; 6lowpan@ietf.org >> Subject: Re: [6lowpan] [Fwd: New Version Notification > fordraft-nordmark-6lowpan-reg-00] >> Hi, >> >> IMHO Erik has the model right regarding multiple routers. In dynamic >> radio environments or in applications with any kind of mobility (e.g. >> Asset Management) the ability to register with multiple routers is >> useful. I also like the new registration message, a clean solution. >> >> - Zach >> >> Pascal Thubert (pthubert) wrote: >>> Hi Erik: >>> >>> I like very much your idea of a new registration message, that's > cleaner >>> than changing NS like I do in the BbR proposal. >>> >>> OTOH, we do not seem to have the same model for the LoWPAN. In >>> particular, your draft seems to assume that the host would want to >>> reach numerous routers and register to them all. >>> >>> For instance, if you have an oil plant or a factory, it makes little >>> sense for a sensor node to go all across the factory across numerous >>> LoWPAN hops to register to a router that the node will never use. >>> >>> In my mind, the LoWPAN nodes form dynamic clusters around the nearest >>> router and use it. Routers might share a faster, powered network that > is >>> called a backbone in ISA parlance, to discover and reach one another. >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> Behalf Of Erik Nordmark >>>> Sent: lundi 16 juin 2008 19:51 >>>> To: 6lowpan@ietf.org >>>> Subject: [6lowpan] [Fwd: New Version Notification >>> fordraft-nordmark-6lowpan-reg-00] >>>> >>>> -------- Original Message -------- >>>> Subject: New Version Notification for draft-nordmark-6lowpan-reg-00 >>>> Date: Mon, 16 Jun 2008 10:44:02 -0700 (PDT) >>>> From: IETF I-D Submission Tool >>>> To: Erik.Nordmark@sun.com >>>> CC: Erik.Nordmark@sun.com >>>> >>>> >>>> A new version of I-D, draft-nordmark-6lowpan-reg-00.txt has been >>>> successfuly submitted by Erik Nordmark and posted to the IETF >>> repository. >>>> Filename: draft-nordmark-6lowpan-reg >>>> Revision: 00 >>>> Title: Neighbor Discovery Registration Extension >>>> Creation_date: 2008-06-16 >>>> WG ID: Independent Submission >>>> Number_of_pages: 9 >>>> >>>> Abstract: >>>> In order to reduce Neighbor Discovery multicast messages it is > useful >>>> if the routers on a link can maintain an authoritative list of the >>>> IPv6 and layer 2 addresses for all the hosts on the link. >>>> >>>> This draft specifies an extension to the Router Advertisement >>>> messages which trigger to hosts to send periodic registration >>>> messages which can be either unicast, multicast, or anycast. The >>>> protocol uses a soft-state approach to gather registration >>>> information. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> >> -- >> Zach Shelby | Head of Research | +358 40 7796297 >> Sensinode Ltd. www.sensinode.com > -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 10 09:01:56 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010553A67EA; Thu, 10 Jul 2008 09:01:56 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E7E3A680E for <6lowpan@core3.amsl.com>; Thu, 10 Jul 2008 09:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWavdJ8BB8Ox for <6lowpan@core3.amsl.com>; Thu, 10 Jul 2008 09:01:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 929DF3A677D for <6lowpan@ietf.org>; Thu, 10 Jul 2008 09:01:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="14040473" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Jul 2008 16:01:53 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6AG1rce010233 for <6lowpan@ietf.org>; Thu, 10 Jul 2008 18:01:53 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6AG1rKl015395 for <6lowpan@ietf.org>; Thu, 10 Jul 2008 16:01:53 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 18:01:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 18:01:11 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05F1D3A7@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-thubert-6lowpan-backbone-router-01 Thread-Index: AcjipU7/z4KXseGfRY2OsolrVv2ikgAACNfw From: "Pascal Thubert (pthubert)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 10 Jul 2008 16:01:53.0264 (UTC) FILETIME=[45263700:01C8E2A6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1801; t=1215705713; x=1216569713; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20FW=3A=20New=20Version=20Notification=20for=20=2 0=20=20=20=20=20=20=20=20draft-thubert-6lowpan-backbone-rout er-01=20 |Sender:=20; bh=hQPmq8jNLqUqm6VltCToyuHqtGB2s+KTpM2XQOOoymc=; b=AteatXdIeJEGCM2i0wW9nQJp4D6lFT4oSgDooXUbOeNvzcjeHdN0ZLZnhZ GYSbLNxJYSxKWggdVsewm8AS7PR1zml0VB7oGRC0BrSiLDIrWTbTjKy+Wtqw M9ZFo9Vel4; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [6lowpan] FW: New Version Notification for draft-thubert-6lowpan-backbone-router-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Dear LoWPANers: I posted an update to the BbR draft. The changes are: - New ICMP messages as opposed to NS/NA options for the binding that reflect the discussions with Erik and Zach, - New functional anycast addresses for the 6LOWPAN_NODE and 6LOWPAN_BBR used during the registration. As a result of those changes, the new draft enables registration without any multicast, though RA operation is still described as an option. Dear Chairs, I'd wish to have a chance to discuss the white board and proxy operations in Dublin. Can you please allocate a slot in the agenda? Pascal >-----Original Message----- >From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >Sent: jeudi 10 juillet 2008 17:55 >To: Pascal Thubert (pthubert) >Subject: New Version Notification for draft-thubert-6lowpan-backbone-router-01 > > >A new version of I-D, draft-thubert-6lowpan-backbone-router-01.txt has been successfuly submitted by >Pascal Thubert and posted to the IETF repository. > >Filename: draft-thubert-6lowpan-backbone-router >Revision: 01 >Title: 6LoWPAN Backbone Router >Creation_date: 2008-07-10 >WG ID: Independent Submission >Number_of_pages: 19 > >Abstract: >ISA100.11a is a Working Group at the ISA SP100 standard committee >that covers Wireless Systems for Industrial Automation and Process >Control. The WG is mandated to design a scalable, industrial grade >LowPAN for devices such as sensors, valves, and actuators. The >upcoming standard uses the 6LoWPAN format for the network header. It >also introduces the concept of a Backbone Router to merge small >LoWPANs via a high speed transit and scale the ISA100.11a network. >This paper proposes an IPv6 version of the Backbone Router concept. > > > >The IETF Secretariat. > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 14 17:54:10 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969C03A6900; Mon, 14 Jul 2008 17:54:10 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7D03A6845 for <6lowpan@core3.amsl.com>; Mon, 14 Jul 2008 17:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdYkcGw-AIpu for <6lowpan@core3.amsl.com>; Mon, 14 Jul 2008 17:54:09 -0700 (PDT) Received: from de01egw01.freescale.net (de01egw01.freescale.net [192.88.165.102]) by core3.amsl.com (Postfix) with ESMTP id F18BC3A6900 for <6lowpan@ietf.org>; Mon, 14 Jul 2008 17:54:08 -0700 (PDT) Received: from de01smr02.am.mot.com (de01smr02.freescale.net [10.208.0.151]) by de01egw01.freescale.net (8.12.11/az33egw01) with ESMTP id m6F0sVcg007855 for <6lowpan@ietf.org>; Mon, 14 Jul 2008 17:54:31 -0700 (MST) Received: from az33exm24.fsl.freescale.net (az33exm24.am.freescale.net [10.64.32.14]) by de01smr02.am.mot.com (8.13.1/8.13.0) with ESMTP id m6F0sTYK019297 for <6lowpan@ietf.org>; Mon, 14 Jul 2008 19:54:30 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 17:54:29 -0700 Message-ID: <598D5675D34BE349929AF5EDE9B03E27020F66D6@az33exm24.fsl.freescale.net> In-Reply-To: <1215444638.5878.6.camel@dellx1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Regarding coexistence with 802.11n Thread-Index: Acjhy5jvJLEp15zHRaGRW4vz6WbmKwER5HXg References: <66df4faf0807040904v62e9e89ay394f326b9402535d@mail.gmail.com> <1215444638.5878.6.camel@dellx1> From: "Adams Jon" To: "Geoff Mulligan" , "Mustafa Hasan" Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Regarding coexistence with 802.11n X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Good afternoon, Hasan (and Geoff) Appendix e does discuss a number of mitigation factors designed into 802.15.4 to improve its ability to coexist with other 802 as well as a narrow class of known interferers. Two important features are the non-alignment of of 802.11 channels with that of 802.15.4 channels in the 2400MHz band. This in theory allows an 802.15.4 station to operate away from a given 802.11 station in the immediate vicinity and even provides (in many regulatory domains) a few 15.4 channels that are completely clear of 802.11 channels. The other is the temporal agility of the 15.4 radio and the brevity of conversations (low duty cycle)- the fact that clear channel assessment and an entire 802.15.4 conversation (data transmission and acknowledgement) can occur in a few milliseconds. This means that 802.15.4 transceivers can take advantage of small gaps in conversations taking place between 802.11 equipment, the off times for consumer microwave ovens, etc. There is a real issue with 802.11n in 40MHz channels, one that was not perceived long ago. As it is described right now, the expectation by a number of 802.11 voters is to allow 2 channels of non-overlapping 40MHz-wide operation in the US 2400-2483.5MHz band (and likely in other regions/countries as well). If there is agreement on this, there will be locations (likely many) where both 40MHz channels are occupied and used intensively. With two heavily loaded 11n channels and a number of hidden transmitters, it may prove difficult for 802.15.4 stations to compete successfully as there will be NO clear channels and only the temporal agility of the 15.4 radio gives it a chance to communicate. Sincerely, Jon Jon Adams Business Development, Wireless Connectivity Operation Freescale Semiconductor 2100 E Elliot Rd MD EL 542 Tempe, AZ 85284 +1 480.628.6686 mobile +1 480.413.3439 office jta@freescale.com -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Geoff Mulligan Sent: Monday, July 07, 2008 8:31 AM To: Mustafa Hasan Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Regarding coexistence with 802.11n Appendix E of the 802.15.4 standard goes into detail on co-existence. On Fri, 2008-07-04 at 09:04 -0700, Mustafa Hasan wrote: > Dear 6lowpaner, > > I need little help regarding the coexistence issue of ISM Band with > other ISM, especially with the 802.11n, 802.11b. > > I want to know what are the factor is going to save the 802.15.4 > fighting with others frequency. > > > Thanks in Advance... > > > Regards > > M. Hasan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 15 01:35:57 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618EB28C368; Tue, 15 Jul 2008 01:35:57 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D61F28C36B for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 01:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTiDbD5FI4cq for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 01:35:55 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 027EE28C351 for <6lowpan@ietf.org>; Tue, 15 Jul 2008 01:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m6F8GvoN029264; Tue, 15 Jul 2008 10:17:00 +0200 (CEST) Message-Id: <5C489A30-AA4D-4626-939A-1BCD1D9C1539@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 10:16:56 +0200 X-Mailer: Apple Mail (2.926) Cc: Carsten Bormann Subject: [6lowpan] Call for agenda items for Dublin meeting X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Lowpanners, we need to set up the meeting agenda for Dublin (currently scheduled for Tue, Jul 29, 0900 to 1130). If you wish to have agenda time at that meeting, please send an agenda request to the chairs, before July 16th 12:00 UTC. We would like to focus the meeting on the six work items in our new charter, with a little time set aside for new work that falls outside of our current charter as well as our coordination with other WGs, if needed. As always, you should have an objective for the discussion resulting from your agenda item, such as the resolution of issues that haven't been possible to resolve on the mailing list; mere updates on your draft are fine (as they are likely to generate useful discussion of what was updated), but should be quite limited in time. Please tell us: -- Presentation Title, Name of presenter -- References to relevant Internet-Draft(s) -- Objective you want to achieve -- Requested amount of time in minutes By the way, I'll need your slides by Jul 28 10:00 UTC (last minute changes will be possible till Jul 29 06:00 UTC). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 15 03:23:56 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF3B3A6B78; Tue, 15 Jul 2008 03:23:56 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4415E3A6B78 for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 03:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id El1daAIqsTU1 for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 03:23:54 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by core3.amsl.com (Postfix) with ESMTP id D83073A6B73 for <6lowpan@ietf.org>; Tue, 15 Jul 2008 03:23:49 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so3674961tib.25 for <6lowpan@ietf.org>; Tue, 15 Jul 2008 03:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=9VR+VLr196KLL4lSKKu2kB4slUxa47jCGWtzz/ebAPI=; b=KQOPtSA6Rg/BI1N0yirIdUfbonl8YPEY7gJ8N/8fyzxQ3+5GkOjTB4DrvejFcUff57 m5rgsnyFDF1/6XTPPRg+A96QkKM7DIsnlzUStSr2p2+zVm9/vfImv9IU5rDo7dPeWugZ v5i4ZjHf5JB6TmToWCN+SY8kukkP9owEWp0Cc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=oWV8W813nmyidqn2Y7D/b76V+7v1RhTuCVx/DuZi7P9+5QK+ar7gdPypZhCGRaPqDM mKp6ZSifo1LYrv+3WB9Iths2xG8hGZrEgMaRzNdPTrxatv2AMMt168iQ4mVgEDY1ScVF STW/IfU2RhHikohozDD/9iKmc3jeTL2/53gvg= Received: by 10.110.11.1 with SMTP id 1mr10221718tik.2.1216117451928; Tue, 15 Jul 2008 03:24:11 -0700 (PDT) Received: by 10.110.21.5 with HTTP; Tue, 15 Jul 2008 03:24:11 -0700 (PDT) Message-ID: <77f1dba80807150324r3becbb9i9485d83ec7249bb4@mail.gmail.com> Date: Tue, 15 Jul 2008 19:24:11 +0900 From: "Eunsook \"Eunah\" Kim" To: "Carsten Bormann" In-Reply-To: <5C489A30-AA4D-4626-939A-1BCD1D9C1539@tzi.org> MIME-Version: 1.0 Content-Disposition: inline References: <5C489A30-AA4D-4626-939A-1BCD1D9C1539@tzi.org> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Call for agenda items for Dublin meeting X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Dear Chairmen, I would like to ask slots for two drafts: 1. 6LoWPAN use-case - Design and Application Spaces for 6LoWPANs - draft-ekim-6lowpan-scenarios-03 (6LoWPAN applicability has been updated) 2. 6LoWPAN routing requirments - Problem Statement and Requirements for 6LoWPAN Mesh Routing - draft-dokaspar-6lowpan-routreq-06 (Problem statement, routing parameters, some requirements have been updated to meet the chartered text. Overally touched to see the view point of specific 6LoWPAN features considering both route-over and mesh-under as charter text says. but forgot to change 'Abstract' so that abstract is now staying 'mesh-under', but main text is not.) I would like to discuss the updated documents and if WG thinks it's good for WG docs as both documents are in the scope of rechartered item. Any comments are welcome on the two drafts. Thanks, -eunah On Tue, Jul 15, 2008 at 5:16 PM, Carsten Bormann wrote: > Lowpanners, > > we need to set up the meeting agenda for Dublin (currently scheduled > for Tue, Jul 29, 0900 to 1130). If you wish to have agenda time at > that meeting, please send an agenda request to the chairs, before July > 16th 12:00 UTC. > > We would like to focus the meeting on the six work items in our new > charter, with a little time set aside for new work that falls outside > of our current charter as well as our coordination with other WGs, if > needed. As always, you should have an objective for the discussion > resulting from your agenda item, such as the resolution of issues that > haven't been possible to resolve on the mailing list; mere updates on > your draft are fine (as they are likely to generate useful discussion > of what was updated), but should be quite limited in time. > > Please tell us: > > -- Presentation Title, Name of presenter > -- References to relevant Internet-Draft(s) > -- Objective you want to achieve > -- Requested amount of time in minutes > > By the way, I'll need your slides by Jul 28 10:00 UTC (last minute > changes will be possible till Jul 29 06:00 UTC). > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 15 06:07:47 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC923A6A07; Tue, 15 Jul 2008 06:07:47 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363583A6838 for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 06:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWr6meu7BCyz for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 06:07:41 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by core3.amsl.com (Postfix) with ESMTP id 4D9103A6956 for <6lowpan@ietf.org>; Tue, 15 Jul 2008 06:07:41 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so3726782tib.25 for <6lowpan@ietf.org>; Tue, 15 Jul 2008 06:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=JVvfegfiGE8M2ZjmB45fh/AfprkY2DDnbFgkT+eAbVw=; b=VLWO7UH+EIVoZgv/Uo7y517VP/enLvqQfrejkXdWYDaWVj1rVoHYMGCFiB+OSwKHZj u3klw6hH0CV/xf/mFTt8lMw205ZDEjg41mvHe1TEZKWmicoU4vxMqEKetjnw0Napbvok m0YGm+c6klK0WbanPGjK9jUlBAEYkuTr6cmhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=lkgdiDfb16HNdLmcGnBnqFtx93a4Qu1N5cBuNytylfJ6MbKExHRvnqDhf6F+5pcf0A ysCYQ3f83j8nNRcLEjJxF2M249+DMicPsasmsLr8Ec27+CFQSjeO2MN4x7VgYJze1iJr xGi2ksvBzgN+P/yZ53m3Iq5Y1VPK579GuWDO4= Received: by 10.110.53.14 with SMTP id b14mr10410828tia.8.1216127282208; Tue, 15 Jul 2008 06:08:02 -0700 (PDT) Received: by 10.110.60.20 with HTTP; Tue, 15 Jul 2008 06:08:01 -0700 (PDT) Message-ID: <66df4faf0807150608g548abdb0w2d12d9d9214f25c6@mail.gmail.com> Date: Tue, 15 Jul 2008 06:08:01 -0700 From: "Mustafa Hasan" To: "Adams Jon" , geoff@mulligan.com In-Reply-To: <598D5675D34BE349929AF5EDE9B03E27020F66D6@az33exm24.fsl.freescale.net> MIME-Version: 1.0 Content-Disposition: inline References: <66df4faf0807040904v62e9e89ay394f326b9402535d@mail.gmail.com> <1215444638.5878.6.camel@dellx1> <598D5675D34BE349929AF5EDE9B03E27020F66D6@az33exm24.fsl.freescale.net> Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Regarding coexistence with 802.11n X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Dear Jon & Geoff, Thank you very much for such a nice and detail mail.... It helped me a lot. I want to add few comments regarding this issues, after my little research in this field. 1. Even thr are some free channels available for different region, but still creating problem for IEEE802.15.4 traffic. Actually, high power of wifi is killing ieee802.15.4 traffic (testbed results). 2. The current research on this issue is interestingly biased, some are saying its not a big problem (e.g ZigBee Alliance) and others (e.g. Z-Wave Alliance) are saying its a big issue. 3. Distance between ieee802.15.4 and ieee802.11x is a big problem in this case. If I summarize all the research efforts (ieee802.19 coexistence assurance documents, white paper(ZigBee, Z-Wave) and many research papers), its not possible that 15.4 & 11x stay together in a distance of <2 meters (even tried with offset 20MHz). 4. thr are many potential application require this distance to be in few centimeters. May be some technique in upper layers can give little bit reliability... but is it enough??? I am looking for some help, comments and suggestion, how coexistence problem can be solved for very short distance scenario... Thank you....... Regards M. Hasan On Mon, Jul 14, 2008 at 5:54 PM, Adams Jon wrote: > Good afternoon, Hasan (and Geoff) > > Appendix e does discuss a number of mitigation factors designed into > 802.15.4 to improve its ability to coexist with other 802 as well as a > narrow class of known interferers. Two important features are the > non-alignment of of 802.11 channels with that of 802.15.4 channels in > the 2400MHz band. This in theory allows an 802.15.4 station to operate > away from a given 802.11 station in the immediate vicinity and even > provides (in many regulatory domains) a few 15.4 channels that are > completely clear of 802.11 channels. The other is the temporal agility > of the 15.4 radio and the brevity of conversations (low duty cycle)- the > fact that clear channel assessment and an entire 802.15.4 conversation > (data transmission and acknowledgement) can occur in a few milliseconds. > This means that 802.15.4 transceivers can take advantage of small gaps > in conversations taking place between 802.11 equipment, the off times > for consumer microwave ovens, etc. > > There is a real issue with 802.11n in 40MHz channels, one that was not > perceived long ago. As it is described right now, the expectation by a > number of 802.11 voters is to allow 2 channels of non-overlapping > 40MHz-wide operation in the US 2400-2483.5MHz band (and likely in other > regions/countries as well). If there is agreement on this, there will be > locations (likely many) where both 40MHz channels are occupied and used > intensively. With two heavily loaded 11n channels and a number of hidden > transmitters, it may prove difficult for 802.15.4 stations to compete > successfully as there will be NO clear channels and only the temporal > agility of the 15.4 radio gives it a chance to communicate. > > Sincerely, Jon > > Jon Adams > Business Development, Wireless Connectivity Operation > Freescale Semiconductor > 2100 E Elliot Rd MD EL 542 > Tempe, AZ 85284 > +1 480.628.6686 mobile > +1 480.413.3439 office > jta@freescale.com > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Geoff Mulligan > Sent: Monday, July 07, 2008 8:31 AM > To: Mustafa Hasan > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] Regarding coexistence with 802.11n > > Appendix E of the 802.15.4 standard goes into detail on co-existence. > > On Fri, 2008-07-04 at 09:04 -0700, Mustafa Hasan wrote: >> Dear 6lowpaner, >> >> I need little help regarding the coexistence issue of ISM Band with >> other ISM, especially with the 802.11n, 802.11b. >> >> I want to know what are the factor is going to save the 802.15.4 >> fighting with others frequency. >> >> >> Thanks in Advance... >> >> >> Regards >> >> M. Hasan >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 15 07:44:56 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7911A3A68CD; Tue, 15 Jul 2008 07:44:56 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D511D3A68CD for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 07:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnprqGFNEFdt for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 07:44:51 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 83E323A67FB for <6lowpan@ietf.org>; Tue, 15 Jul 2008 07:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m6F8GvoN029264; Tue, 15 Jul 2008 10:17:00 +0200 (CEST) Message-Id: <5C489A30-AA4D-4626-939A-1BCD1D9C1539@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 10:16:56 +0200 X-Mailer: Apple Mail (2.926) Cc: Carsten Bormann Subject: [6lowpan] Call for agenda items for Dublin meeting X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Lowpanners, we need to set up the meeting agenda for Dublin (currently scheduled for Tue, Jul 29, 0900 to 1130). If you wish to have agenda time at that meeting, please send an agenda request to the chairs, before July 16th 12:00 UTC. We would like to focus the meeting on the six work items in our new charter, with a little time set aside for new work that falls outside of our current charter as well as our coordination with other WGs, if needed. As always, you should have an objective for the discussion resulting from your agenda item, such as the resolution of issues that haven't been possible to resolve on the mailing list; mere updates on your draft are fine (as they are likely to generate useful discussion of what was updated), but should be quite limited in time. Please tell us: -- Presentation Title, Name of presenter -- References to relevant Internet-Draft(s) -- Objective you want to achieve -- Requested amount of time in minutes By the way, I'll need your slides by Jul 28 10:00 UTC (last minute changes will be possible till Jul 29 06:00 UTC). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 15 08:43:57 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B97F3A6B22; Tue, 15 Jul 2008 08:43:57 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8077A3A6B0B for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 08:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWdt5vS6sKm7 for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 08:43:55 -0700 (PDT) Received: from mail.stg.com (mail.stg.com [75.145.148.171]) by core3.amsl.com (Postfix) with ESMTP id 135463A6996 for <6lowpan@ietf.org>; Tue, 15 Jul 2008 08:43:55 -0700 (PDT) Received: from mrman (internal.stg.com [75.145.148.170]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: zog) by mail.stg.com (Postfix) with ESMTPSA id 020A333CAC; Tue, 15 Jul 2008 10:44:21 -0500 (CDT) From: "Christian Herzog" To: "'Mustafa Hasan'" , "'Adams Jon'" , References: <66df4faf0807040904v62e9e89ay394f326b9402535d@mail.gmail.com><1215444638.5878.6.camel@dellx1><598D5675D34BE349929AF5EDE9B03E27020F66D6@az33exm24.fsl.freescale.net> <66df4faf0807150608g548abdb0w2d12d9d9214f25c6@mail.gmail.com> Date: Tue, 15 Jul 2008 10:44:21 -0500 Organization: Software Technologies Group, Inc. Message-ID: <011801c8e691$a6c47b40$e427d10a@stg.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <66df4faf0807150608g548abdb0w2d12d9d9214f25c6@mail.gmail.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acjme9ps2p2ZoF1NSeygX7/D0x/exQACdTfQ Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Regarding coexistence with 802.11n X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: zog@stg.com 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > -----Original Message----- > From: 6lowpan-bounces@ietf.org > [mailto:6lowpan-bounces@ietf.org] On Behalf Of Mustafa Hasan > Sent: Tuesday, July 15, 2008 8:08 AM > To: Adams Jon; geoff@mulligan.com > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] Regarding coexistence with 802.11n > > Dear Jon & Geoff, > > Thank you very much for such a nice and detail mail.... It helped me a > lot. I want to add few comments regarding this issues, after my little > research in this field. > > 1. Even thr are some free channels available for different region, but > still creating problem for IEEE802.15.4 traffic. Actually, high power > of wifi is killing ieee802.15.4 traffic (testbed results). > > 2. The current research on this issue is interestingly biased, some > are saying its not a big problem (e.g ZigBee Alliance) and others > (e.g. Z-Wave Alliance) are saying its a big issue. The 802 family of standards has some modicum of coexistence "built-in" as Jon suggested - our experience is that a serious interference source are non-802 devices including various FHSS devices that pay little to no heed to whatever else is in the band. The often have no coexistence considerations and blatantly use the band as if they were the only device in town. Some of these devices are getting smarter though (but for their own selfish reasons). Various first generation 2.4GHz cordless phones used to horrible spectrum users by using the entire 2.4GHz band with little regard for anything else. They seem to be taking some steps now to segment the band and avoid Wi-Fi sized areas now; probably not to help Wi-Fi but to make themselves work better by avoiding sections of the band that don't work well for *them*. > 3. Distance between ieee802.15.4 and ieee802.11x is a big problem in > this case. If I summarize all the research efforts (ieee802.19 > coexistence assurance documents, white paper(ZigBee, Z-Wave) and many > research papers), its not possible that 15.4 & 11x stay together in a > distance of <2 meters (even tried with offset 20MHz). Our practical experience is 2 meters is plenty in most situations, even 1 meter is enough but getting riskier. A lot of the vendor/organization white papers seem incredibly biased to me and upon reading them, I basically get the idea that the network running right on my desk couldn't possibly work (and might even kill me ;) when clearly it is working. > 4. thr are many potential application require this distance to be in > few centimeters. May be some technique in upper layers can give little > bit reliability... but is it enough??? > > I am looking for some help, comments and suggestion, how coexistence > problem can be solved for very short distance scenario... For a few centimeters, this problem may very well be unsolvable (at reasonable cost/effort). The only way the upper layers can accommodate something as brutal as this is through coordination and knowing that the radio will effectively be "blinded" at specific times. For uncoordinated networks, this isn't really practical. At centimeter distances, *everything* can act like an antenna and it is very easy to saturate a radio receiver which effectively blinds it from receiving anything - as you pointed out, even significant frequency separation isn't enough when things are closely located; there is just so far to run in a relatively small band. Even closely located *receivers* can interfere with each other even if they never transmit; we have had to use shielding between closely colocated receivers in some multi-receiver designs to prevent them from interfering with each other. In simple terms, if it oscillates, it radiates and something either sensitive enough or close enough will get effected by such radiation possibly to the point of incorrect operation. Few centimeter separation of transmitters is a difficult problem to solve and would likely be out of scope of this effort. -- Christian Herzog Software Technologies Group, Inc. mailto:zog@stg.com http://www.stg.com +1 (708) 547-0110 x225 FAX +1 (708) 547-0783 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 15 08:58:01 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609AB3A6A07; Tue, 15 Jul 2008 08:58:01 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5B43A686A for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 08:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A12m25+IhJiU for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 08:57:58 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [65.254.51.10]) by core3.amsl.com (Postfix) with ESMTP id 859903A67EC for <6lowpan@ietf.org>; Tue, 15 Jul 2008 08:57:58 -0700 (PDT) Received: from [72.164.184.70] (helo=RunningDog2) by wilson.nswebhost.com with smtp (Exim 4.69) (envelope-from ) id 1KImuE-0006wI-7C; Tue, 15 Jul 2008 10:57:55 -0500 Message-ID: <001c01c8e693$7ebf0cd0$760710ac@RunningDog2> From: "Benjamin A. Rolfe" To: "Adams Jon" , "Geoff Mulligan" , "Mustafa Hasan" References: <66df4faf0807040904v62e9e89ay394f326b9402535d@mail.gmail.com><1215444638.5878.6.camel@dellx1> <598D5675D34BE349929AF5EDE9B03E27020F66D6@az33exm24.fsl.freescale.net> Date: Tue, 15 Jul 2008 08:57:31 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ClamAntiVirus-Scanner: This mail is clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Regarding coexistence with 802.11n X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Jon gives an excellent summary of the current situation. I'll elaborate slightly on a few points.... > There is a real issue with 802.11n in 40MHz channels, one that was not > perceived long ago. This issue was raised quite some time ago. That is one reason it has become a bit contentious now. 'nuff said... > As it is described right now, the expectation by a > number of 802.11 voters is to allow 2 channels of non-overlapping > 40MHz-wide operation in the US 2400-2483.5MHz band (and likely in other > regions/countries as well). If there is agreement on this, there will be > locations (likely many) where both 40MHz channels are occupied and used > intensively. With two heavily loaded 11n channels and a number of hidden > transmitters, it may prove difficult for 802.15.4 stations to compete > successfully as there will be NO clear channels and only the temporal > agility of the 15.4 radio gives it a chance to communicate. Additionally, the usage models and applications discussed by TGn raise concernes of near 100% occupation in time as well as frequency. Systems such as Bluetooth and 802.15.4 depend on other services leaving some time to squeak in, as well. There is a perception that 11n may completely fill the band in frequency and in time, which presents much greater conflict than with the typical usage models of today. The most common usage of 802.11g today is connecting to the internet, which usually involves a bottleneck of 6MBps or less between the user and the internet. Thus actually air duty cycle for the most common 11g usage scenarios leaves a lot of room in time for other services. Thus explanations offered by TGn based on similarity of channel bonding to having multiple 11g APs in the same space have been less than reassuring. I think this is significant. Another factor is that while operating under the same rules, it is likely 802.15.4 nodes will be operating at much lower effective transmit power than 11n (due to focus on low power, low cost implementation). Alas, the same factors that make 802.15.4 unlikely to interfere with, and likely to "lose" contention with an 11n system, also make 15.4 neighbors harder for other services such as 11n to detect. -Ben > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Geoff Mulligan > Sent: Monday, July 07, 2008 8:31 AM > To: Mustafa Hasan > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] Regarding coexistence with 802.11n > > Appendix E of the 802.15.4 standard goes into detail on co-existence. > > On Fri, 2008-07-04 at 09:04 -0700, Mustafa Hasan wrote: >> Dear 6lowpaner, >> >> I need little help regarding the coexistence issue of ISM Band with >> other ISM, especially with the 802.11n, 802.11b. >> >> I want to know what are the factor is going to save the 802.15.4 >> fighting with others frequency. >> >> >> Thanks in Advance... >> >> >> Regards >> >> M. Hasan >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 15 10:34:41 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06BC28C149; Tue, 15 Jul 2008 10:34:41 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4B728C152 for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 10:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR-Qy7zk-0L1 for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 10:34:39 -0700 (PDT) Received: from de01egw02.freescale.net (de01egw02.freescale.net [192.88.165.103]) by core3.amsl.com (Postfix) with ESMTP id 5BA1F28C129 for <6lowpan@ietf.org>; Tue, 15 Jul 2008 10:34:39 -0700 (PDT) Received: from de01smr01.freescale.net (de01smr01.freescale.net [10.208.0.31]) by de01egw02.freescale.net (8.12.11/de01egw02) with ESMTP id m6FHZ0SE025690 for <6lowpan@ietf.org>; Tue, 15 Jul 2008 10:35:01 -0700 (MST) Received: from az33exm24.fsl.freescale.net (az33exm24.am.freescale.net [10.64.32.14]) by de01smr01.freescale.net (8.13.1/8.13.0) with ESMTP id m6FHYxsF005951 for <6lowpan@ietf.org>; Tue, 15 Jul 2008 12:35:00 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 10:34:58 -0700 Message-ID: <598D5675D34BE349929AF5EDE9B03E27020F67FC@az33exm24.fsl.freescale.net> In-Reply-To: <66df4faf0807150608g548abdb0w2d12d9d9214f25c6@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Regarding coexistence with 802.11n Thread-Index: Acjme9opj51UkxByRhmLHdUmqIBOHAAGGCVQ References: <66df4faf0807040904v62e9e89ay394f326b9402535d@mail.gmail.com> <1215444638.5878.6.camel@dellx1> <598D5675D34BE349929AF5EDE9B03E27020F66D6@az33exm24.fsl.freescale.net> <66df4faf0807150608g548abdb0w2d12d9d9214f25c6@mail.gmail.com> From: "Adams Jon" To: "Mustafa Hasan" , Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Regarding coexistence with 802.11n X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org -----Original Message----- From: Mustafa Hasan [mailto:mhmunna@gmail.com] Sent: Tuesday, July 15, 2008 6:08 AM To: Adams Jon; geoff@mulligan.com Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Regarding coexistence with 802.11n >2. The current research on this issue is interestingly biased, some are saying its not a big >problem (e.g ZigBee Alliance) and others (e.g. Z-Wave Alliance) are saying its a big issue. Beware of wild claims %^). At least in the US, the 902MHz band has enjoyed a huge resurgence of uses as well as a strengthening of licensed uses. As many do not realize, the 902-928MHz band has some licensed users including location services and amateur radio, in addition to a huge and growing amount of license-free users. For the license-free users, it's the location and monitoring services (LMS) though, that is most concerning from a usability point of view. Back in the early 1990's, before the price of GPS receivers dropped much below US$1k, several companies in the US were able to get licenses to occupy 6MHz wide channels in the 902MHz band with fairly high power mountaintop or towertop radios. The object was to provide trilateration services to mobile receivers in delivery trucks, theft recovery services for automobiles, etc. Well, the price of GPS dropped more quickly than LMS, and the companies went silent, the licenses pretty much worthless. In the last few years, there has been a LOT of lobbying of the FCC to repurpose these licenses to allow the licensees to do pretty much whatever they want with their frequencies, including wireless broadband, etc. This is a great concern as they are not subject to the power limitations of Part 15 and in fact at least one licensee wants to exact some significant restrictions on 900MHz Part 15 devices. Wireless broadband internet service providers have discovered the excellent propagation and penetration of 902MHz. It is now common to find, especially in suburban or rural areas, wireless ISPs delivering broadband in the 902MHz band, in 5, 10 and even 20MHz bandwidths. The legal limit there is +36dBm EIRP as well. Lastly, one significant and continually growing use of the 902MHz band is wireless metering for electric, gas and water meters. My house has a 900MHz wireless gas meter that blurps out a packet every minute or so. In dense housing areas the aggregation can be impressive. US railroads have deployed 900MHz readers for RFID tags that are on about 80% of the railcar fleet (about 8M railcars) and those readers transmit essentially a CW carrier at a +44dBm level for several minutes while the train passes the reader. RFID readers in stores and commercial establishments are increasingly using 900MHz for illuminating tags using similar power levels. Amateur radio is making greater use of the 902MHz band (they're a primary licensed user). While it's FM narrow-band comms for the most part (but there is digital QPSK and GMSK as well), the EIRP is typically in the +43 to +50dBm range for mobile, portable and tower/mountaintop. The 900MHz band is no panacea. The users there are often digitally modulated, with power levels from Part 15 levels (+36dBm EIRP) and up. A truly obsolete technology (narrow-band FSK, traditionally 9600 baud, with some usage now at 40k baud, single RF channel) like Z-Wave cannot compete with any of the above uses. Not only is Z-Wave exceedingly slow and inaccurate in assessing the availability of the channel, its packets are 40-80ms long, and it isn't detected by the digitally modulated systems out there, so they punch holes in the packet. FSK requires a significant SNR (10-15dB) to demodulate successfully, so any interference can threaten its link performance. The sole Z-Wave 908.42MHz frequency happens to be in the middle of the mobile transmit side for ham radio, so the ham down the street can saturate a Z-Wave receiver without even knowing. It's no wonder that the new Z-Wave 401 chip is purported to support the 2.4GHz band. Now, all of this doesn't mean that somehow the 2.4GHz band is much better - like Christian and Ben remind us, there's plenty of uses in the 2.4GHz band that aren't too worried about who else is out there. However, both in-lab extreme testing, real-world testing, and anecdotal evidence show that 15.4, 802.11, microwave ovens, Bluetooth and cordless phones aren't necessarily incompatible. Witness the success of 15.4 systems and demonstrations in huge conference arenas like CES in the US, where the density and average power level of 802.11g systems (nodes on nearly every channel, even though that doesn't make much sense due to overlap) conspire only to generally increase latency of the 15.4 system by a few milliseconds at worst. Our 15.4 systems here at work behave well even with our very high usage and density of 802.11g systems. Use of 15.4 systems is most successful for low-duty cycle (<1%), moderate latency (10ms) uses. As Ben points out, there is significant concern by many that 802.11n has the potential to not play very fair with the channel, and make life difficult for the rest of us. This is a good reason for those of those with voting rights in 802.11 to stand up and fight against this threat to the 2.4GHz band. Sincerely, Jon Jon Adams Business Development, Wireless Connectivity Operation Freescale Semiconductor 2100 E Elliot Rd MD EL 542 Tempe, AZ 85284 +1 480.628.6686 mobile +1 480.413.3439 office jta@freescale.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 15 11:08:33 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4FA73A6995; Tue, 15 Jul 2008 11:08:33 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36173A6995 for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 11:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALufs63PSQ+V for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 11:08:31 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [65.254.51.10]) by core3.amsl.com (Postfix) with ESMTP id A96C93A68E8 for <6lowpan@ietf.org>; Tue, 15 Jul 2008 11:08:31 -0700 (PDT) Received: from [72.164.184.70] (helo=RunningDog2) by wilson.nswebhost.com with smtp (Exim 4.69) (envelope-from ) id 1KIoxO-0005ql-Gx for 6lowpan@ietf.org; Tue, 15 Jul 2008 13:08:58 -0500 Message-ID: <002201c8e6a5$d9d16430$760710ac@RunningDog2> From: "Benjamin A. Rolfe" To: <6lowpan@ietf.org> References: <66df4faf0807040904v62e9e89ay394f326b9402535d@mail.gmail.com><1215444638.5878.6.camel@dellx1><598D5675D34BE349929AF5EDE9B03E27020F66D6@az33exm24.fsl.freescale.net><66df4faf0807150608g548abdb0w2d12d9d9214f25c6@mail.gmail.com> <011801c8e691$a6c47b40$e427d10a@stg.com> Date: Tue, 15 Jul 2008 10:57:29 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ClamAntiVirus-Scanner: This mail is clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] Regarding coexistence with 802.11n X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org 1 meter is *probably* a safe assumption for coexistence of 802.11 and 802.15.4 in most use cases. It is definitely *not* a good assumption for 802.11 and BT. These already are collocated in the same deice (phone, PDA, laptop) and require simultaneous operation. One reason it works is both are operating at fairly low duty cycle today and so there is the opportunity for good luck. Some cleverness, some luck ;-). -Ben ----- Original Message ----- From: "Christian Herzog" To: "'Mustafa Hasan'" ; "'Adams Jon'" ; Cc: <6lowpan@ietf.org> Sent: Tuesday, July 15, 2008 8:44 AM Subject: Re: [6lowpan] Regarding coexistence with 802.11n >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org >> [mailto:6lowpan-bounces@ietf.org] On Behalf Of Mustafa Hasan >> Sent: Tuesday, July 15, 2008 8:08 AM >> To: Adams Jon; geoff@mulligan.com >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] Regarding coexistence with 802.11n >> >> Dear Jon & Geoff, >> >> Thank you very much for such a nice and detail mail.... It helped me > a >> lot. I want to add few comments regarding this issues, after my > little >> research in this field. >> >> 1. Even thr are some free channels available for different region, > but >> still creating problem for IEEE802.15.4 traffic. Actually, high > power >> of wifi is killing ieee802.15.4 traffic (testbed results). >> >> 2. The current research on this issue is interestingly biased, some >> are saying its not a big problem (e.g ZigBee Alliance) and others >> (e.g. Z-Wave Alliance) are saying its a big issue. > > The 802 family of standards has some modicum of coexistence "built-in" > as Jon suggested - our experience is that a serious interference > source are non-802 devices including various FHSS devices that pay > little to no heed to whatever else is in the band. The often have no > coexistence considerations and blatantly use the band as if they were > the only device in town. > > Some of these devices are getting smarter though (but for their own > selfish reasons). Various first generation 2.4GHz cordless phones > used to horrible spectrum users by using the entire 2.4GHz band with > little regard for anything else. They seem to be taking some steps > now to segment the band and avoid Wi-Fi sized areas now; probably not > to help Wi-Fi but to make themselves work better by avoiding sections > of the band that don't work well for *them*. > > >> 3. Distance between ieee802.15.4 and ieee802.11x is a big problem in >> this case. If I summarize all the research efforts (ieee802.19 >> coexistence assurance documents, white paper(ZigBee, Z-Wave) and > many >> research papers), its not possible that 15.4 & 11x stay together in > a >> distance of <2 meters (even tried with offset 20MHz). > > Our practical experience is 2 meters is plenty in most situations, > even 1 meter is enough but getting riskier. > > A lot of the vendor/organization white papers seem incredibly biased > to me and upon reading them, I basically get the idea that the network > running right on my desk couldn't possibly work (and might even kill > me ;) when clearly it is working. > > >> 4. thr are many potential application require this distance to be in >> few centimeters. May be some technique in upper layers can give > little >> bit reliability... but is it enough??? >> >> I am looking for some help, comments and suggestion, how coexistence >> problem can be solved for very short distance scenario... > > > For a few centimeters, this problem may very well be unsolvable (at > reasonable cost/effort). The only way the upper layers can > accommodate something as brutal as this is through coordination and > knowing that the radio will effectively be "blinded" at specific > times. For uncoordinated networks, this isn't really practical. > > At centimeter distances, *everything* can act like an antenna and it > is very easy to saturate a radio receiver which effectively blinds it > from receiving anything - as you pointed out, even significant > frequency separation isn't enough when things are closely located; > there is just so far to run in a relatively small band. > > Even closely located *receivers* can interfere with each other even if > they never transmit; we have had to use shielding between closely > colocated receivers in some multi-receiver designs to prevent them > from interfering with each other. In simple terms, if it oscillates, > it radiates and something either sensitive enough or close enough will > get effected by such radiation possibly to the point of incorrect > operation. > > Few centimeter separation of transmitters is a difficult problem to > solve and would likely be out of scope of this effort. > > > -- > Christian Herzog Software Technologies Group, Inc. > mailto:zog@stg.com http://www.stg.com > +1 (708) 547-0110 x225 FAX +1 (708) 547-0783 > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 15 18:06:35 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414843A6AAF; Tue, 15 Jul 2008 18:06:35 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73DEC3A6AC8 for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 18:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LbcnoHfrp-E for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 18:06:33 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 7FF193A67B4 for <6lowpan@ietf.org>; Tue, 15 Jul 2008 17:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m6FJOMFv028827; Tue, 15 Jul 2008 21:24:25 +0200 (CEST) Message-Id: From: Carsten Bormann To: "Adams Jon" In-Reply-To: <598D5675D34BE349929AF5EDE9B03E27020F67FC@az33exm24.fsl.freescale.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 21:24:22 +0200 References: <66df4faf0807040904v62e9e89ay394f326b9402535d@mail.gmail.com> <1215444638.5878.6.camel@dellx1> <598D5675D34BE349929AF5EDE9B03E27020F66D6@az33exm24.fsl.freescale.net> <66df4faf0807150608g548abdb0w2d12d9d9214f25c6@mail.gmail.com> <598D5675D34BE349929AF5EDE9B03E27020F67FC@az33exm24.fsl.freescale.net> X-Mailer: Apple Mail (2.926) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] Regarding coexistence with 802.11n X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Jon, this was really useful background material, especially for those of us living in GSM 900 land (where 870 to 960 MHz are taken for various variants of GSM). Modern usage models for home WiFi are indeed likely to use much higher duty cycles (consider Apple's Time Capsule product, which might do a full backup for multiple hours, mostly limited by the bitrate achievable over the radio). Apart from the fact that .11n has revitalized 5 GHz usage, the only hope may be that neither the backup software nor the MAC is not good enough to go up to 100 %. However, I'm a bit uneasy with the following part: > 802.11n has the potential to not play very fair with the > channel, and make life difficult for the rest of us. This is a good > reason for those of those with voting rights in 802.11 to stand up and > fight against this threat to the 2.4GHz band. The .11n cat has been out of the bag for slightly more than a year now (http://www.wi-fi.org/pressroom_overview.php?newsid=694 -- 325 approved products, more than half of the WiFi chipsets now); IEEE politics won't stop that. More importantly, I don't think we should use IETF lists for attempting to kindle tensions between IEEE groups. Gruesse, Carsten (typing this from an IEEE 802.11n laptop to an IEEE 802.11n base station which both won't care whether a formal standard exists) _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 15 20:52:08 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6143A6835; Tue, 15 Jul 2008 20:52:08 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E08863A6835 for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 20:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4c3SS4kJlv1 for <6lowpan@core3.amsl.com>; Tue, 15 Jul 2008 20:52:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id B77EB3A6834 for <6lowpan@ietf.org>; Tue, 15 Jul 2008 20:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m6F8GvoN029264; Tue, 15 Jul 2008 10:17:00 +0200 (CEST) Message-Id: <5C489A30-AA4D-4626-939A-1BCD1D9C1539@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 10:16:56 +0200 X-Mailer: Apple Mail (2.926) Cc: Carsten Bormann Subject: [6lowpan] Call for agenda items for Dublin meeting X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Lowpanners, we need to set up the meeting agenda for Dublin (currently scheduled for Tue, Jul 29, 0900 to 1130). If you wish to have agenda time at that meeting, please send an agenda request to the chairs, before July 16th 12:00 UTC. We would like to focus the meeting on the six work items in our new charter, with a little time set aside for new work that falls outside of our current charter as well as our coordination with other WGs, if needed. As always, you should have an objective for the discussion resulting from your agenda item, such as the resolution of issues that haven't been possible to resolve on the mailing list; mere updates on your draft are fine (as they are likely to generate useful discussion of what was updated), but should be quite limited in time. Please tell us: -- Presentation Title, Name of presenter -- References to relevant Internet-Draft(s) -- Objective you want to achieve -- Requested amount of time in minutes By the way, I'll need your slides by Jul 28 10:00 UTC (last minute changes will be possible till Jul 29 06:00 UTC). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 16 06:06:52 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13DCD3A6B40; Wed, 16 Jul 2008 06:06:52 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DFB3A6B40 for <6lowpan@core3.amsl.com>; Wed, 16 Jul 2008 06:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmfR8DJFQpqG for <6lowpan@core3.amsl.com>; Wed, 16 Jul 2008 06:06:49 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id 7CFB63A6909 for <6lowpan@ietf.org>; Wed, 16 Jul 2008 06:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m6GD6koj017956; Wed, 16 Jul 2008 15:06:49 +0200 (CEST) Message-Id: From: Carsten Bormann To: Carsten Bormann In-Reply-To: <5C489A30-AA4D-4626-939A-1BCD1D9C1539@tzi.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 16 Jul 2008 15:06:46 +0200 References: <5C489A30-AA4D-4626-939A-1BCD1D9C1539@tzi.org> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Call for agenda items for Dublin meeting X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org I now have uploaded a draft agenda to http://www.ietf.org/proceedings/08jul/agenda/6lowpan.txt We need to fill in the s, and add any missing agenda items. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 16 09:24:49 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5FD28C110; Wed, 16 Jul 2008 09:24:49 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63FFC3A677D for <6lowpan@core3.amsl.com>; Wed, 16 Jul 2008 09:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O45D8GxYmBep for <6lowpan@core3.amsl.com>; Wed, 16 Jul 2008 09:24:46 -0700 (PDT) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by core3.amsl.com (Postfix) with ESMTP id 1D86D3A6980 for <6lowpan@ietf.org>; Wed, 16 Jul 2008 09:24:46 -0700 (PDT) Received: by el-out-1112.google.com with SMTP id v27so1049796ele.13 for <6lowpan@ietf.org>; Wed, 16 Jul 2008 09:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=tezYQNs+kvzwXXjm5tKiXjiMUGo5W9HBvmFv9ddkXPI=; b=j8k0aN+Lu1D2soyVUlA/VvkdpPJVdMJsUyBMhpnZ+akqhUjR7qNGa6fLPnxed526ek O+M6GkEcogtNHJZA2jFdaqAo79aQtvsHbyiolBdL0ZgtjKDumscUPdYlA7Cj0Q8dacdX U9A4PKkG4zm3Uno7yDIoqeW/kL+3BiUgnpwzA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=sw2KKcgHDNUObB+5b1SH04wXqHijZSVv+UNAaLxMJr/Xn3wI/ZkTF4O3P6AN2NMNYS /NGB4vGk2G0qR0Oo44FGjweurcpK9l1EmPqSP5plNFTsVCOiALivtBhpPXK6ifGpCd/d ebZcqPu/8LNvjXAetvFMu6sDJ/ugRZaoUogO4= Received: by 10.114.171.1 with SMTP id t1mr357202wae.120.1216225515019; Wed, 16 Jul 2008 09:25:15 -0700 (PDT) Received: by 10.114.197.16 with HTTP; Wed, 16 Jul 2008 09:25:14 -0700 (PDT) Message-ID: Date: Wed, 16 Jul 2008 09:25:14 -0700 From: "David Culler" To: 6lowpan@ietf.org MIME-Version: 1.0 Subject: [6lowpan] HC X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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="===============1251060626==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1251060626== Content-Type: multipart/alternative; boundary="----=_Part_27252_18565368.1216225515015" ------=_Part_27252_18565368.1216225515015 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline It appears that the 6LoWPAN WG is poised to take up serious discussion of HC (http://www3.tools.ietf.org/html/draft-hui-6lowpan-hc-00) and I would like to encourage us to make a bold move forward while the number of "dusty deck 6LoWPAN implementations" are few - eliminate HC1/HC2 in the process. As a bit of background, the original format document defined HC1 for compression of link local IPv6 addresses and HC2 for compression of UDP and ICMP headers. Both were part of a rather awkward encoding. Most other parts of the encoding got cleaned up with the switch to the stacked header format that went to RFC. Aside from its awkwardness, HC1 was never sufficient, because it provided no compression of routable addresses, nor for the most useful multicast addresses - both rather essential to IPv6. HC1g was proposed to provide a similar (somewhat more effective) stateless compression of common addresses of global scope. This meant two similar compression schemes, HC1 for link-local, HC1G for global. Both are implementable with much less than a thousand lines of code. No ambiguity about when to use which. HC provides a much cleaner approach which subsumes both HC1 and HC1g, better supports multicast, and is much more usable with IPv6 stacked headers because the order of the subheaders is respected. (HC2 comes in between the dispatch and the address subheader, rather than as a portion of the transport subheader). The decision to take on HC, clean up the rough edges, and build consensus around it is the easy part. The bolder step that I would like to suggest is that we deprecate HC1 and get it removed soon. It is always easier to maintain backward compatibility than to make a clean break. But, ultimately that is burdening all the many future implementations in order to avoid a burden on the few current implementations. The reason to avoid this burden is not that either is a huge amount of code. Implementing any of these HCs is only several hundred LOC. The issue is testing and interoperability. The interoperability draft sheds some light on this. There are so many different compression forms and since each is an optimization on the uncompressed version, there are many different ways to represent the same thing. All with different sizes and offsets. At least they are all in the same suite. To multiply that with all the combinations of HC1 and HC will be really unpleasant. Moreover, the only thing anyone will ever use after a short while is HC, since it is so much cleaner and more effective. That means all the HC1 mess and all the testing and interoperability investment will be for nothing other than that - just to pass the test. But it will generate latent bugs, increase the footprint, and frustrate interoperabilty. So, as we imagine a future of billions of 6LoWPAN IP devices embedded in important hard to reach places, lets take the step now to simplify their implementation and testing, rather worry too much about saving a few hours of coding for the half dozen existing implementations. If that is not reason enough, those same implementors will save many times that amount in reduced testing and interoperability validation. ------=_Part_27252_18565368.1216225515015 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
It appears that the 6LoWPAN WG is poised to take up serious discussion of HC (http://www3.tools.ietf.org/html/draft-hui-6lowpan-hc-00) and I would like to encourage us to make a bold move forward while the number of "dusty deck 6LoWPAN implementations" are few - eliminate HC1/HC2 in the process.

As a bit of background, the original format document defined HC1 for compression of link local IPv6 addresses and HC2 for compression of UDP and ICMP headers.  Both were part of a rather awkward encoding.  Most other parts of the encoding got cleaned up with the switch to the stacked header format that went to RFC.  Aside from its awkwardness, HC1 was never sufficient, because it provided no compression of routable addresses, nor for the most useful multicast addresses - both rather essential to IPv6.  HC1g was proposed to provide a similar (somewhat more effective) stateless compression of common addresses of global scope.  This meant two similar compression schemes, HC1 for link-local, HC1G for global.  Both are implementable with much less than a thousand lines of code.  No ambiguity about when to use which.

HC provides a much cleaner approach which subsumes both HC1 and HC1g, better supports multicast, and is much more usable with IPv6 stacked headers because the order of the subheaders is respected.  (HC2 comes in between the dispatch and the address subheader, rather than as a portion of the transport subheader).

The decision to take on HC, clean up the rough edges, and build consensus around it is the easy part.  The bolder step that I would like to suggest is that we deprecate HC1 and get it removed soon.

It is always easier to maintain backward compatibility than to make a clean break.  But, ultimately that is burdening all the many future implementations in order to avoid a burden on the few current implementations.

The reason to avoid this burden is not that either is a huge amount of code.  Implementing any of these HCs is only several hundred LOC.  The issue is testing and interoperability. The interoperability draft sheds some light on this.  There are so many different compression forms and since each is an optimization on the uncompressed version, there are many different ways to represent the same thing.  All with different sizes and offsets.  At least they are all in the same suite.  To multiply that with all the combinations of HC1 and HC will be really unpleasant.  Moreover, the only thing anyone will ever use after a short while is HC, since it is so much cleaner and more effective.  That means all the HC1 mess and all the testing and interoperability investment will be for nothing other than that - just to pass the test.  But it will generate latent bugs, increase the footprint, and frustrate interoperabilty.

So, as we imagine a future of billions of 6LoWPAN IP devices embedded in important hard to reach places, lets take the step now to simplify their implementation and testing, rather worry too much about saving a few hours of coding for the half dozen existing implementations.  If that is not reason enough, those same implementors will save many times that amount in reduced testing and interoperability validation.


------=_Part_27252_18565368.1216225515015-- --===============1251060626== 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://www.ietf.org/mailman/listinfo/6lowpan --===============1251060626==-- From 6lowpan-bounces@ietf.org Wed Jul 16 23:02:45 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBCB28C110; Wed, 16 Jul 2008 23:02:45 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750D33A69B7 for <6lowpan@core3.amsl.com>; Wed, 16 Jul 2008 23:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAUrceb2RsnC for <6lowpan@core3.amsl.com>; Wed, 16 Jul 2008 23:02:43 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by core3.amsl.com (Postfix) with ESMTP id 325D93A6858 for <6lowpan@ietf.org>; Wed, 16 Jul 2008 23:02:43 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so5597778wra.17 for <6lowpan@ietf.org>; Wed, 16 Jul 2008 23:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=33bRdKx3+ujND3S5NHWpoN7HgCtysmVZ+vJWKoc11eo=; b=NRQCZjzqE9PzXrMqPWYk2O/L1XeRDh6LeWwlmJeu8prb7UOQwJyI8o9pOALzxy4ACh GLdVHEOotFC4EAY8BqkTZiSXiEq4FgLV/dVogt1iXatWlEvHLlb8qFmd4Re9OpWG+mzS xYTZk03md6vTPQjqdKuwTAU2GDqeVFkY+Ks2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=En1k8VzmpMhALiVWmJVZx3RUf4wAPF13/LjRNi9nRXWiZ7J+WL7cko1ebqpJRB0IYb oZG1gRZfioAFKLsyDtdYxgFrKZtfJ2zJ9MUlXud4ycEJ9q408WVRW/BS9IkEDq0dh3cN /nZ0fRUZ4vsukK/3QCPMTqLmqBRbLwwfImgBk= Received: by 10.90.66.14 with SMTP id o14mr2840718aga.61.1216274589523; Wed, 16 Jul 2008 23:03:09 -0700 (PDT) Received: by 10.90.88.14 with HTTP; Wed, 16 Jul 2008 23:03:09 -0700 (PDT) Message-ID: Date: Thu, 17 Jul 2008 15:03:09 +0900 From: "Ki-Hyung Kim" To: "Carsten Bormann" , "Geoff Mulligan" In-Reply-To: MIME-Version: 1.0 References: <5C489A30-AA4D-4626-939A-1BCD1D9C1539@tzi.org> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Call for agenda items for Dublin meeting X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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="===============1700177783==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1700177783== Content-Type: multipart/alternative; boundary="----=_Part_33626_11124121.1216274589484" ------=_Part_33626_11124121.1216274589484 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline RGVhciBDaGFpcm1hbgpUaGlzIGlzIEtpLUh5dW5nIEtpbS4KCkNvdWxkIEkgcmVxdWVzdCBwcmVz ZW50YXRpb24gc2xvdHMgZm9yIHRoZSBmb2xsb3dpbmcgZHJhZnRzPwoKMSkgICJDb21taXNzaW9u aW5nIGluIDZsb3dwYW4iIChkcmFmdC1kYW5pZWwtNmxvd3Bhbi1jb21taXNzaW9uaW5nLTAyKSBm b3IKdGhlIGJvb3RzdHJhcHBpbmcgaXRlbSBpbiB0aGUgbmV3IGNoYXJ0ZXIuCjIpICAiNmxvd3Bh biBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2UiIChkcmFmdC1kYW5pZWwtbG93cGFuLW1pYi0w MSkgZm9yCnRoZSA2bG93cGFuIEFyY2hpdGVjdHVyZSBpdGVtIGluIHRoZSBjaGFydGVyIGFzIGEg bWFuYWdlbWVudCBhcmNoaXRlY3R1cmUgb2YKNmxvd3Bhbi4KClRoYW5rcyBpbiBhZHZhbmNlLgoK CgoKT24gNy8xNi8wOCwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+IHdyb3RlOgo+Cj4g SSBub3cgaGF2ZSB1cGxvYWRlZCBhIGRyYWZ0IGFnZW5kYSB0bwo+Cj4gIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvMDhqdWwvYWdlbmRhLzZsb3dwYW4udHh0Cj4KPiBXZSBuZWVkIHRv IGZpbGwgaW4gdGhlIDx3aG8+cywgYW5kIGFkZCBhbnkgbWlzc2luZyBhZ2VuZGEgaXRlbXMuCj4K PiBHcnVlc3NlLCBDYXJzdGVuCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+IDZsb3dwYW4gbWFpbGluZyBsaXN0Cj4gNmxvd3BhbkBpZXRmLm9yZwo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3Bhbgo+Cj4KPgoKCi0t IApLaS1IeXVuZyBLaW0gKLHoseLH/Cwg0N3Rw/r7KQpBc3NvY2lhdGUgUHJvZmVzc29yLCBBam91 IFVuaXZlcnNpdHksIEtvcmVhLCAgaHR0cDovL3d3dy42bG93cGFuLm5ldApUZWw6ICs4Mi0zMS0y MTktMjQzMywgQ2VsOiArODItMTAtNDc2MC0yNTUxCg== ------=_Part_33626_11124121.1216274589484 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5EZWFyIENoYWlybWFuPC9kaXY+CjxkaXY+VGhpcyBpcyBLaS1IeXVuZyBLaW0uPC9kaXY+ CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+Q291bGQgSSByZXF1ZXN0IHByZXNlbnRhdGlvbiBzbG90 cyBmb3IgdGhlIGZvbGxvd2luZyBkcmFmdHM/PC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+ MSkmbmJzcDsmbmJzcDsmcXVvdDtDb21taXNzaW9uaW5nIGluIDZsb3dwYW4mcXVvdDsgKDxhIGhy ZWY9Imh0dHA6Ly9kcmFmdC1kYW5pZWwtNmxvd3Bhbi1jb21taXNzaW9uaW5nLTAyIj5kcmFmdC1k YW5pZWwtNmxvd3Bhbi1jb21taXNzaW9uaW5nLTAyPC9hPikgZm9yIHRoZSBib290c3RyYXBwaW5n IGl0ZW0gaW4gdGhlIG5ldyBjaGFydGVyLjwvZGl2Pgo8ZGl2PjIpJm5ic3A7ICZxdW90OzZsb3dw YW4gTWFuYWdlbWVudCBJbmZvcm1hdGlvbiZuYnNwO0Jhc2UmcXVvdDsgKDxhIGhyZWY9Imh0dHA6 Ly9kcmFmdC1kYW5pZWwtbG93cGFuLW1pYi0wMSI+ZHJhZnQtZGFuaWVsLWxvd3Bhbi1taWItMDE8 L2E+KSBmb3IgdGhlIDZsb3dwYW4gQXJjaGl0ZWN0dXJlIGl0ZW0gaW4gdGhlIGNoYXJ0ZXIgYXMg YSBtYW5hZ2VtZW50IGFyY2hpdGVjdHVyZSBvZiA2bG93cGFuLjwvZGl2PgoKPGRpdj4mbmJzcDs8 L2Rpdj4KPGRpdj5UaGFua3MgaW4gYWR2YW5jZS48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRp dj48YnI+PGJyPiZuYnNwOzwvZGl2Pgo8ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24g Ny8xNi8wOCwgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPkNhcnN0ZW4gQm9ybWFubjwvYj4g Jmx0OzxhIGhyZWY9Im1haWx0bzpjYWJvQHR6aS5vcmciPmNhYm9AdHppLm9yZzwvYT4mZ3Q7IHdy b3RlOjwvc3Bhbj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iUEFERElO Ry1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IEJPUkRFUi1MRUZUOiAjY2Nj IDFweCBzb2xpZCI+SSBub3cgaGF2ZSB1cGxvYWRlZCBhIGRyYWZ0IGFnZW5kYSB0bzxicj48YnI+ Jm5ic3A7PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQs dGhpcykiIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDhqdWwvYWdlbmRh LzZsb3dwYW4udHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy8wOGp1bC9hZ2VuZGEvNmxvd3Bhbi50eHQ8L2E+PGJyPgo8YnI+V2UgbmVlZCB0byBmaWxs IGluIHRoZSAmbHQ7d2hvJmd0O3MsIGFuZCBhZGQgYW55IG1pc3NpbmcgYWdlbmRhIGl0ZW1zLiAK PGRpdj48c3BhbiBjbGFzcz0iZSIgaWQ9InFfMTFiMmJmYjg5YjUxZTgzY18xIj48YnI+PGJyPkdy dWVzc2UsIENhcnN0ZW48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPjZsb3dwYW4gbWFpbGluZyBsaXN0PGJyPjxhIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86Nmxv d3BhbkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjZsb3dwYW5AaWV0Zi5vcmc8L2E+PGJyPgo8 YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFu PC9hPjxicj48YnI+PGJyPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPgo8YnIg Y2xlYXI9ImFsbCI+PGJyPi0tIDxicj5LaS1IeXVuZyBLaW0gKLHoseLH/Cwg0N3Rw/r7KTxicj5B c3NvY2lhdGUgUHJvZmVzc29yLCBBam91IFVuaXZlcnNpdHksIEtvcmVhLCZuYnNwOyZuYnNwOzxh IGhyZWY9Imh0dHA6Ly93d3cuNmxvd3Bhbi5uZXQiPmh0dHA6Ly93d3cuNmxvd3Bhbi5uZXQ8L2E+ IDxicj5UZWw6ICs4Mi0zMS0yMTktMjQzMywgQ2VsOiArODItMTAtNDc2MC0yNTUxIAo= ------=_Part_33626_11124121.1216274589484-- --===============1700177783== 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://www.ietf.org/mailman/listinfo/6lowpan --===============1700177783==-- From 6lowpan-bounces@ietf.org Thu Jul 17 01:14:22 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D453A6ADC; Thu, 17 Jul 2008 01:14:22 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B8A3A6B1A for <6lowpan@core3.amsl.com>; Thu, 17 Jul 2008 01:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNes3yOxccVV for <6lowpan@core3.amsl.com>; Thu, 17 Jul 2008 01:14:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0A6353A688E for <6lowpan@ietf.org>; Thu, 17 Jul 2008 01:14:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,202,1215388800"; d="scan'208,217";a="14594146" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2008 08:14:43 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6H8Ei2q004862; Thu, 17 Jul 2008 10:14:44 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6H8Ehkm009624; Thu, 17 Jul 2008 08:14:43 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 10:14:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Jul 2008 10:13:56 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05F771A8@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] HC Thread-Index: AcjnYJMa7Qi3Y4tmRG2esrNRdVYuZgAhA8Fw References: From: "Pascal Thubert (pthubert)" To: "David Culler" , <6lowpan@ietf.org> X-OriginalArrivalTime: 17 Jul 2008 08:14:43.0855 (UTC) FILETIME=[2B3611F0:01C8E7E5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12112; t=1216282484; x=1217146484; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20HC |Sender:=20; bh=FUvnKuJYOCEQKShPNsNej4Mx1xL86gRPX9dr6722YUc=; b=SwBIE8yjER9ZSkbOjecmpdn3cL1GHaYE3ZttsSX0ANQee0onNwqpaJWXZK IlTDAluC/6KPGrZ9d35t8lYiTH3Zn5eigSmQatR5nyHgQJ7ItpFwMmd6DzDv rCidSj7nyh; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [6lowpan] HC X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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="===============1267811549==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1267811549== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E7E5.2B13CB4E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E7E5.2B13CB4E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi David: =20 I do support that approach. I'd note that it would impose some pressure to release HC rather quickly. Is there a way to get a feedback on existing deployments that use 6LoWPAN HC1?=20 =20 Pascal ________________________________ From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of David Culler Sent: mercredi 16 juillet 2008 18:25 To: 6lowpan@ietf.org Subject: [6lowpan] HC =20 It appears that the 6LoWPAN WG is poised to take up serious discussion of HC (http://www3.tools.ietf.org/html/draft-hui-6lowpan-hc-00) and I would like to encourage us to make a bold move forward while the number of "dusty deck 6LoWPAN implementations" are few - eliminate HC1/HC2 in the process. As a bit of background, the original format document defined HC1 for compression of link local IPv6 addresses and HC2 for compression of UDP and ICMP headers. Both were part of a rather awkward encoding. Most other parts of the encoding got cleaned up with the switch to the stacked header format that went to RFC. Aside from its awkwardness, HC1 was never sufficient, because it provided no compression of routable addresses, nor for the most useful multicast addresses - both rather essential to IPv6. HC1g was proposed to provide a similar (somewhat more effective) stateless compression of common addresses of global scope. This meant two similar compression schemes, HC1 for link-local, HC1G for global. Both are implementable with much less than a thousand lines of code. No ambiguity about when to use which. HC provides a much cleaner approach which subsumes both HC1 and HC1g, better supports multicast, and is much more usable with IPv6 stacked headers because the order of the subheaders is respected. (HC2 comes in between the dispatch and the address subheader, rather than as a portion of the transport subheader). The decision to take on HC, clean up the rough edges, and build consensus around it is the easy part. The bolder step that I would like to suggest is that we deprecate HC1 and get it removed soon. It is always easier to maintain backward compatibility than to make a clean break. But, ultimately that is burdening all the many future implementations in order to avoid a burden on the few current implementations. The reason to avoid this burden is not that either is a huge amount of code. Implementing any of these HCs is only several hundred LOC. The issue is testing and interoperability. The interoperability draft sheds some light on this. There are so many different compression forms and since each is an optimization on the uncompressed version, there are many different ways to represent the same thing. All with different sizes and offsets. At least they are all in the same suite. To multiply that with all the combinations of HC1 and HC will be really unpleasant. Moreover, the only thing anyone will ever use after a short while is HC, since it is so much cleaner and more effective. That means all the HC1 mess and all the testing and interoperability investment will be for nothing other than that - just to pass the test. But it will generate latent bugs, increase the footprint, and frustrate interoperabilty. So, as we imagine a future of billions of 6LoWPAN IP devices embedded in important hard to reach places, lets take the step now to simplify their implementation and testing, rather worry too much about saving a few hours of coding for the half dozen existing implementations. If that is not reason enough, those same implementors will save many times that amount in reduced testing and interoperability validation. ------_=_NextPart_001_01C8E7E5.2B13CB4E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi = David:

 

I do support that approach. = I’d note that it would impose some pressure to release HC rather = quickly.

Is there a way to get a feedback on existing deployments that use 6LoWPAN HC1?

 

Pascal

From: = 6lowpan-bounces@ietf.org = [mailto:6lowpan-bounces@ietf.org] On Behalf Of David Culler
Sent: mercredi 16 juillet = 2008 18:25
To: 6lowpan@ietf.org
Subject: [6lowpan] HC

 

It appears = that the 6LoWPAN WG is poised to take up serious discussion of HC (http://w= ww3.tools.ietf.org/html/draft-hui-6lowpan-hc-00) and I would like to encourage us to make a bold move forward while the = number of "dusty deck 6LoWPAN implementations" are few - eliminate = HC1/HC2 in the process.

As a bit of background, the original format document defined HC1 for compression of link local IPv6 addresses and HC2 for compression of UDP = and ICMP headers.  Both were part of a rather awkward encoding.  = Most other parts of the encoding got cleaned up with the switch to the = stacked header format that went to RFC.  Aside from its awkwardness, HC1 = was never sufficient, because it provided no compression of routable addresses, = nor for the most useful multicast addresses - both rather essential to = IPv6.  HC1g was proposed to provide a similar (somewhat more effective) stateless compression of common addresses of global scope.  This meant two = similar compression schemes, HC1 for link-local, HC1G for global.  Both are implementable with much less than a thousand lines of code.  No = ambiguity about when to use which.

HC provides a much cleaner approach which subsumes both HC1 and HC1g, = better supports multicast, and is much more usable with IPv6 stacked headers = because the order of the subheaders is respected.  (HC2 comes in between = the dispatch and the address subheader, rather than as a portion of the = transport subheader).

The decision to take on HC, clean up the rough edges, and build = consensus around it is the easy part.  The bolder step that I would like to = suggest is that we deprecate HC1 and get it removed soon.

It is always easier to maintain backward compatibility than to make a = clean break.  But, ultimately that is burdening all the many future implementations in order to avoid a burden on the few current = implementations.

The reason to avoid this burden is not that either is a huge amount of code.  Implementing any of these HCs is only several hundred = LOC.  The issue is testing and interoperability. The interoperability draft = sheds some light on this.  There are so many different compression forms = and since each is an optimization on the uncompressed version, there are = many different ways to represent the same thing.  All with different sizes and offsets.  At least they are all in the same suite.  To = multiply that with all the combinations of HC1 and HC will be really unpleasant.  Moreover, the only thing anyone will ever use after a short while is HC, = since it is so much cleaner and more effective.  That means all the HC1 = mess and all the testing and interoperability investment will be for nothing = other than that - just to pass the test.  But it will generate latent bugs, = increase the footprint, and frustrate interoperabilty.

So, as we imagine a future of billions of 6LoWPAN IP devices embedded in important hard to reach places, lets take the step now to simplify their implementation and testing, rather worry too much about saving a few = hours of coding for the half dozen existing implementations.  If that is not = reason enough, those same implementors will save many times that amount in = reduced testing and interoperability validation.

------_=_NextPart_001_01C8E7E5.2B13CB4E-- --===============1267811549== 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://www.ietf.org/mailman/listinfo/6lowpan --===============1267811549==-- From 6lowpan-bounces@ietf.org Thu Jul 17 01:35:50 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9D53A688E; Thu, 17 Jul 2008 01:35:50 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78AE3A67E6 for <6lowpan@core3.amsl.com>; Thu, 17 Jul 2008 01:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGeNFdyx0tQD for <6lowpan@core3.amsl.com>; Thu, 17 Jul 2008 01:35:48 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 156793A688E for <6lowpan@ietf.org>; Thu, 17 Jul 2008 01:35:47 -0700 (PDT) Received: from dialtutka.bogus (line-4717.dyn.kponet.fi [85.29.64.190]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m6H8a9tW028773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Thu, 17 Jul 2008 11:36:13 +0300 Message-ID: <487F0457.1060502@sensinode.com> Date: Thu, 17 Jul 2008 11:35:35 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> References: In-Reply-To: Subject: Re: [6lowpan] HC X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org I support this motion fully. This is the time to do it, getting stuck with both HC1 and HC not only complicated implementation, testing and validation. It also slows down technology acceptance by confusing engineers and users. A couple questions come to mind: - Timeline would need to be quick, end of this year at the latest. Could we manage that or better? - How would the depreciation be done in practice? I guess a new complete RFC would be issued, and the whole RFC4944 depreciated. - Zach David Culler wrote: > It appears that the 6LoWPAN WG is poised to take up serious discussion > of HC (http://www3.tools.ietf.org/html/draft-hui-6lowpan-hc-00) and I > would like to encourage us to make a bold move forward while the number > of "dusty deck 6LoWPAN implementations" are few - eliminate HC1/HC2 in > the process. > > As a bit of background, the original format document defined HC1 for > compression of link local IPv6 addresses and HC2 for compression of UDP > and ICMP headers. Both were part of a rather awkward encoding. Most > other parts of the encoding got cleaned up with the switch to the > stacked header format that went to RFC. Aside from its awkwardness, HC1 > was never sufficient, because it provided no compression of routable > addresses, nor for the most useful multicast addresses - both rather > essential to IPv6. HC1g was proposed to provide a similar (somewhat > more effective) stateless compression of common addresses of global > scope. This meant two similar compression schemes, HC1 for link-local, > HC1G for global. Both are implementable with much less than a thousand > lines of code. No ambiguity about when to use which. > > HC provides a much cleaner approach which subsumes both HC1 and HC1g, > better supports multicast, and is much more usable with IPv6 stacked > headers because the order of the subheaders is respected. (HC2 comes in > between the dispatch and the address subheader, rather than as a portion > of the transport subheader). > > The decision to take on HC, clean up the rough edges, and build > consensus around it is the easy part. The bolder step that I would like > to suggest is that we deprecate HC1 and get it removed soon. > > It is always easier to maintain backward compatibility than to make a > clean break. But, ultimately that is burdening all the many future > implementations in order to avoid a burden on the few current > implementations. > > The reason to avoid this burden is not that either is a huge amount of > code. Implementing any of these HCs is only several hundred LOC. The > issue is testing and interoperability. The interoperability draft sheds > some light on this. There are so many different compression forms and > since each is an optimization on the uncompressed version, there are > many different ways to represent the same thing. All with different > sizes and offsets. At least they are all in the same suite. To > multiply that with all the combinations of HC1 and HC will be really > unpleasant. Moreover, the only thing anyone will ever use after a short > while is HC, since it is so much cleaner and more effective. That means > all the HC1 mess and all the testing and interoperability investment > will be for nothing other than that - just to pass the test. But it > will generate latent bugs, increase the footprint, and frustrate > interoperabilty. > > So, as we imagine a future of billions of 6LoWPAN IP devices embedded in > important hard to reach places, lets take the step now to simplify their > implementation and testing, rather worry too much about saving a few > hours of coding for the half dozen existing implementations. If that is > not reason enough, those same implementors will save many times that > amount in reduced testing and interoperability validation. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 17 01:40:11 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6FF3A6A7C; Thu, 17 Jul 2008 01:40:11 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77B1B3A68EF for <6lowpan@core3.amsl.com>; Thu, 17 Jul 2008 01:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUrPscUFPMMF for <6lowpan@core3.amsl.com>; Thu, 17 Jul 2008 01:40:09 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by core3.amsl.com (Postfix) with ESMTP id 2B77E3A6A22 for <6lowpan@ietf.org>; Thu, 17 Jul 2008 01:40:09 -0700 (PDT) Received: from mlsv6.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id D0D1937C85 for <6lowpan@ietf.org>; Thu, 17 Jul 2008 17:40:39 +0900 (JST) Received: from MFILTER-S3.hitachi.co.jp by mlsv6.hitachi.co.jp (8.13.1/8.13.1) id m6H8edLf003642; Thu, 17 Jul 2008 17:40:39 +0900 Received: from vshuts4.hitachi.co.jp (unverified) by MFILTER-S3.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Thu, 17 Jul 2008 17:40:39 +0900 X-AuditID: 0ac90650-acb52ba000004dd3-fd-487f0587df56 Received: from hsdlgw92.sdl.hitachi.co.jp (unknown [133.144.7.20]) by vshuts4.hitachi.co.jp (Symantec Mail Security) with ESMTP id 3A681204284; Thu, 17 Jul 2008 17:40:39 +0900 (JST) Received: from vgate2.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.13.1/3.7W06092911) id m6H8eUbg004428; Thu, 17 Jul 2008 17:40:39 +0900 Received: from sdl99w.sdl.hitachi.co.jp ([133.144.14.250]) by vgate2.sdl.hitachi.co.jp (SAVSMTP 3.1.1.32) with SMTP id M2008071717403823004 ; Thu, 17 Jul 2008 17:40:38 +0900 Received: from 127.0.0.1 (IDENT:U2FsdGVkX1/nGpsejvFq2myLDS6qQXF4hrMUjZga6Qw@localhost.localdomain [127.0.0.1]) by sdl99w.sdl.hitachi.co.jp (8.13.1/3.7W04031011) with SMTP id m6H8ePG5014730; Thu, 17 Jul 2008 17:40:25 +0900 Message-Id: <200807170840.m6H8ePG5014730@sdl99w.sdl.hitachi.co.jp> Date: Thu, 17 Jul 2008 17:40:25 +0900 From: IGARASHI Yuichi X-Mailer: EdMax Ver2.85.5F MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05F771A8@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC05F771A8@xmb-ams-337.emea.cisco.com> X-Brightmail-Tracker: AAAAAA== Cc: 6lowpan@ietf.org, David Culler Subject: Re: [6lowpan] HC X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi David, I support your approach, too. The test for interoperability is increased by complicating specifications. Implementers never want that, I think. Yuichi "Pascal Thubert (pthubert)" wrote: > Hi David: > > > > I do support that approach. I'd note that it would impose some pressure > to release HC rather quickly. > > Is there a way to get a feedback on existing deployments that use > 6LoWPAN HC1? > > > > Pascal > > ________________________________ > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of David Culler > Sent: mercredi 16 juillet 2008 18:25 > To: 6lowpan@ietf.org > Subject: [6lowpan] HC > > > > It appears that the 6LoWPAN WG is poised to take up serious discussion > of HC (http://www3.tools.ietf.org/html/draft-hui-6lowpan-hc-00) and I > would like to encourage us to make a bold move forward while the number > of "dusty deck 6LoWPAN implementations" are few - eliminate HC1/HC2 in > the process. > > As a bit of background, the original format document defined HC1 for > compression of link local IPv6 addresses and HC2 for compression of UDP > and ICMP headers. Both were part of a rather awkward encoding. Most > other parts of the encoding got cleaned up with the switch to the > stacked header format that went to RFC. Aside from its awkwardness, HC1 > was never sufficient, because it provided no compression of routable > addresses, nor for the most useful multicast addresses - both rather > essential to IPv6. HC1g was proposed to provide a similar (somewhat > more effective) stateless compression of common addresses of global > scope. This meant two similar compression schemes, HC1 for link-local, > HC1G for global. Both are implementable with much less than a thousand > lines of code. No ambiguity about when to use which. > > HC provides a much cleaner approach which subsumes both HC1 and HC1g, > better supports multicast, and is much more usable with IPv6 stacked > headers because the order of the subheaders is respected. (HC2 comes in > between the dispatch and the address subheader, rather than as a portion > of the transport subheader). > > The decision to take on HC, clean up the rough edges, and build > consensus around it is the easy part. The bolder step that I would like > to suggest is that we deprecate HC1 and get it removed soon. > > It is always easier to maintain backward compatibility than to make a > clean break. But, ultimately that is burdening all the many future > implementations in order to avoid a burden on the few current > implementations. > > The reason to avoid this burden is not that either is a huge amount of > code. Implementing any of these HCs is only several hundred LOC. The > issue is testing and interoperability. The interoperability draft sheds > some light on this. There are so many different compression forms and > since each is an optimization on the uncompressed version, there are > many different ways to represent the same thing. All with different > sizes and offsets. At least they are all in the same suite. To > multiply that with all the combinations of HC1 and HC will be really > unpleasant. Moreover, the only thing anyone will ever use after a short > while is HC, since it is so much cleaner and more effective. That means > all the HC1 mess and all the testing and interoperability investment > will be for nothing other than that - just to pass the test. But it > will generate latent bugs, increase the footprint, and frustrate > interoperabilty. > > So, as we imagine a future of billions of 6LoWPAN IP devices embedded in > important hard to reach places, lets take the step now to simplify their > implementation and testing, rather worry too much about saving a few > hours of coding for the half dozen existing implementations. If that is > not reason enough, those same implementors will save many times that > amount in reduced testing and interoperability validation. > > > -- Hitachi, Ltd., Systems Development Laboratory IGARASHI Yuichi Mail： yuichi.igarashi.hb@.hitachi.com Tel ： +81-(0)45-860-3080 FAX ： +81-(0)45-860-1674 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 17 01:53:30 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FE43A6ADB; Thu, 17 Jul 2008 01:53:30 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C473A6ADB; Thu, 17 Jul 2008 01:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.994 X-Spam-Level: X-Spam-Status: No, score=-3.994 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8iP2v+yOw6x; Thu, 17 Jul 2008 01:53:28 -0700 (PDT) Received: from gw-eur4.philips.com (gw-eur4.philips.com [161.85.125.10]) by core3.amsl.com (Postfix) with ESMTP id C225B3A6A96; Thu, 17 Jul 2008 01:53:27 -0700 (PDT) Received: from smtpscan-eur7.philips.com (smtpscan-eur7.mail.philips.com [130.144.57.172]) by gw-eur4.philips.com (Postfix) with ESMTP id CC7C61A52; Thu, 17 Jul 2008 08:52:51 +0000 (GMT) Received: from smtpscan-eur7.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 675F414C; Thu, 17 Jul 2008 08:53:57 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur7.philips.com (Postfix) with ESMTP id 24B9F111D; Thu, 17 Jul 2008 08:53:57 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id E8286A7; Thu, 17 Jul 2008 08:53:56 +0000 (GMT) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05F771A8@xmb-ams-337.emea.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Anthony Schoofs Date: Thu, 17 Jul 2008 10:56:24 +0200 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.6FP2HF30 | November 25, 2007) at 17/07/2008 10:56:26 MIME-Version: 1.0 Cc: 6lowpan-bounces@ietf.org, 6lowpan@ietf.org, David Culler Subject: Re: [6lowpan] HC X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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="===============1542718080==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1542718080== Content-type: multipart/related; Boundary="0__=4EBBFE1ADFBE752E8f9e8a93df938690918c4EBBFE1ADFBE752E" --0__=4EBBFE1ADFBE752E8f9e8a93df938690918c4EBBFE1ADFBE752E Content-type: multipart/alternative; Boundary="1__=4EBBFE1ADFBE752E8f9e8a93df938690918c4EBBFE1ADFBE752E" --1__=4EBBFE1ADFBE752E8f9e8a93df938690918c4EBBFE1ADFBE752E Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 SSBhbSBhbHNvIGluIGZhdm9yIG9mIHRoYXQgYXBwcm9hY2guDQpXZSBoYXZlIGhhZCBpc3N1ZXMg d2l0aCByb3V0aW5nIHBhY2tldHMgZnJvbSA2bG93cGFuIG5vZGVzIHRvIElQIGhvc3RzLCBhbmQN CndlIGRlZmluaXRpdmVseSBuZWVkIHRoZSBIQyBjb21wcmVzc2lvbiB0byBtYWtlIHRoaW5ncyBj bGVhbmVyIGFuZA0Kb3B0aW1pemVkLg0KDQpBbnRob255DQotLQ0KQW50aG9ueSBTY2hvb2ZzDQpS ZXNlYXJjaCBTY2llbnRpc3QNClBoaWxpcHMgUmVzZWFyY2gNCkhpZ2ggVGVjaCBDYW1wdXMgMzQg LCA1NjU2IEFFIEVpbmRob3ZlbiwgVGhlIE5ldGhlcmxhbmRzDQpFbWFpbDogYW50aG9ueS5zY2hv b2ZzQHBoaWxpcHMuY29tDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUbyANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICJEYXZpZCBDdWxsZXIiICAgICAgICAgICAgICAg ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRhdmlkLmN1 bGxlckBnbWFpbC5jb20+ICAgICAgICAgICAgDQogICAgICJQYXNjYWwgVGh1YmVydCAgICAgICAg ICAgICAgICAgICA8Nmxvd3BhbkBpZXRmLm9yZz4gICAgICAgICAgICAgICAgICANCiAgICAgKHB0 aHViZXJ0KSIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGNjIA0KICAgICA8cHRodWJlcnRAY2lzY28uY29tPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3ViamVjdCANCiAgICAg U2VudCBieTogICAgICAgICAgICAgICAgICAgICAgICAgIFJlOiBbNmxvd3Bhbl0gSEMgICAgICAg ICAgICAgICAgICAgIA0KICAgICA2bG93cGFuLWJvdW5jZXNAaWV0ZiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQ2xhc3NpZmljYXRpb24gDQogICAgIC5vcmcgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KICAgICAxNy0wNy0yMDA4IDEwOjEzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQoNCg0KSGkgRGF2aWQ6DQoNCkkgZG8gc3VwcG9ydCB0aGF0IGFwcHJvYWNoLiBJ4oCZ ZCBub3RlIHRoYXQgaXQgd291bGQgaW1wb3NlIHNvbWUgcHJlc3N1cmUgdG8NCnJlbGVhc2UgSEMg cmF0aGVyIHF1aWNrbHkuDQpJcyB0aGVyZSBhIHdheSB0byBnZXQgYSBmZWVkYmFjayBvbiBleGlz dGluZyBkZXBsb3ltZW50cyB0aGF0IHVzZSA2TG9XUEFODQpIQzE/DQoNClBhc2NhbA0KDQpGcm9t OiA2bG93cGFuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzo2bG93cGFuLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZg0KT2YgRGF2aWQgQ3VsbGVyDQpTZW50OiBtZXJjcmVkaSAxNiBqdWlsbGV0 IDIwMDggMTg6MjUNClRvOiA2bG93cGFuQGlldGYub3JnDQpTdWJqZWN0OiBbNmxvd3Bhbl0gSEMN Cg0KSXQgYXBwZWFycyB0aGF0IHRoZSA2TG9XUEFOIFdHIGlzIHBvaXNlZCB0byB0YWtlIHVwIHNl cmlvdXMgZGlzY3Vzc2lvbiBvZg0KSEMgKGh0dHA6Ly93d3czLnRvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaHVpLTZsb3dwYW4taGMtMDApIGFuZCBJIHdvdWxkDQpsaWtlIHRvIGVuY291cmFnZSB1 cyB0byBtYWtlIGEgYm9sZCBtb3ZlIGZvcndhcmQgd2hpbGUgdGhlIG51bWJlciBvZiAiZHVzdHkN CmRlY2sgNkxvV1BBTiBpbXBsZW1lbnRhdGlvbnMiIGFyZSBmZXcgLSBlbGltaW5hdGUgSEMxL0hD MiBpbiB0aGUgcHJvY2Vzcy4NCg0KQXMgYSBiaXQgb2YgYmFja2dyb3VuZCwgdGhlIG9yaWdpbmFs IGZvcm1hdCBkb2N1bWVudCBkZWZpbmVkIEhDMSBmb3INCmNvbXByZXNzaW9uIG9mIGxpbmsgbG9j YWwgSVB2NiBhZGRyZXNzZXMgYW5kIEhDMiBmb3IgY29tcHJlc3Npb24gb2YgVURQIGFuZA0KSUNN UCBoZWFkZXJzLiAgQm90aCB3ZXJlIHBhcnQgb2YgYSByYXRoZXIgYXdrd2FyZCBlbmNvZGluZy4g IE1vc3Qgb3RoZXINCnBhcnRzIG9mIHRoZSBlbmNvZGluZyBnb3QgY2xlYW5lZCB1cCB3aXRoIHRo ZSBzd2l0Y2ggdG8gdGhlIHN0YWNrZWQgaGVhZGVyDQpmb3JtYXQgdGhhdCB3ZW50IHRvIFJGQy4g IEFzaWRlIGZyb20gaXRzIGF3a3dhcmRuZXNzLCBIQzEgd2FzIG5ldmVyDQpzdWZmaWNpZW50LCBi ZWNhdXNlIGl0IHByb3ZpZGVkIG5vIGNvbXByZXNzaW9uIG9mIHJvdXRhYmxlIGFkZHJlc3Nlcywg bm9yDQpmb3IgdGhlIG1vc3QgdXNlZnVsIG11bHRpY2FzdCBhZGRyZXNzZXMgLSBib3RoIHJhdGhl ciBlc3NlbnRpYWwgdG8gSVB2Ni4NCkhDMWcgd2FzIHByb3Bvc2VkIHRvIHByb3ZpZGUgYSBzaW1p bGFyIChzb21ld2hhdCBtb3JlIGVmZmVjdGl2ZSkgc3RhdGVsZXNzDQpjb21wcmVzc2lvbiBvZiBj b21tb24gYWRkcmVzc2VzIG9mIGdsb2JhbCBzY29wZS4gIFRoaXMgbWVhbnQgdHdvIHNpbWlsYXIN CmNvbXByZXNzaW9uIHNjaGVtZXMsIEhDMSBmb3IgbGluay1sb2NhbCwgSEMxRyBmb3IgZ2xvYmFs LiAgQm90aCBhcmUNCmltcGxlbWVudGFibGUgd2l0aCBtdWNoIGxlc3MgdGhhbiBhIHRob3VzYW5k IGxpbmVzIG9mIGNvZGUuICBObyBhbWJpZ3VpdHkNCmFib3V0IHdoZW4gdG8gdXNlIHdoaWNoLg0K DQpIQyBwcm92aWRlcyBhIG11Y2ggY2xlYW5lciBhcHByb2FjaCB3aGljaCBzdWJzdW1lcyBib3Ro IEhDMSBhbmQgSEMxZywNCmJldHRlciBzdXBwb3J0cyBtdWx0aWNhc3QsIGFuZCBpcyBtdWNoIG1v cmUgdXNhYmxlIHdpdGggSVB2NiBzdGFja2VkDQpoZWFkZXJzIGJlY2F1c2UgdGhlIG9yZGVyIG9m IHRoZSBzdWJoZWFkZXJzIGlzIHJlc3BlY3RlZC4gIChIQzIgY29tZXMgaW4NCmJldHdlZW4gdGhl IGRpc3BhdGNoIGFuZCB0aGUgYWRkcmVzcyBzdWJoZWFkZXIsIHJhdGhlciB0aGFuIGFzIGEgcG9y dGlvbiBvZg0KdGhlIHRyYW5zcG9ydCBzdWJoZWFkZXIpLg0KDQpUaGUgZGVjaXNpb24gdG8gdGFr ZSBvbiBIQywgY2xlYW4gdXAgdGhlIHJvdWdoIGVkZ2VzLCBhbmQgYnVpbGQgY29uc2Vuc3VzDQph cm91bmQgaXQgaXMgdGhlIGVhc3kgcGFydC4gIFRoZSBib2xkZXIgc3RlcCB0aGF0IEkgd291bGQg bGlrZSB0byBzdWdnZXN0DQppcyB0aGF0IHdlIGRlcHJlY2F0ZSBIQzEgYW5kIGdldCBpdCByZW1v dmVkIHNvb24uDQoNCkl0IGlzIGFsd2F5cyBlYXNpZXIgdG8gbWFpbnRhaW4gYmFja3dhcmQgY29t cGF0aWJpbGl0eSB0aGFuIHRvIG1ha2UgYSBjbGVhbg0KYnJlYWsuICBCdXQsIHVsdGltYXRlbHkg dGhhdCBpcyBidXJkZW5pbmcgYWxsIHRoZSBtYW55IGZ1dHVyZQ0KaW1wbGVtZW50YXRpb25zIGlu IG9yZGVyIHRvIGF2b2lkIGEgYnVyZGVuIG9uIHRoZSBmZXcgY3VycmVudA0KaW1wbGVtZW50YXRp b25zLg0KDQpUaGUgcmVhc29uIHRvIGF2b2lkIHRoaXMgYnVyZGVuIGlzIG5vdCB0aGF0IGVpdGhl ciBpcyBhIGh1Z2UgYW1vdW50IG9mDQpjb2RlLiAgSW1wbGVtZW50aW5nIGFueSBvZiB0aGVzZSBI Q3MgaXMgb25seSBzZXZlcmFsIGh1bmRyZWQgTE9DLiAgVGhlDQppc3N1ZSBpcyB0ZXN0aW5nIGFu ZCBpbnRlcm9wZXJhYmlsaXR5LiBUaGUgaW50ZXJvcGVyYWJpbGl0eSBkcmFmdCBzaGVkcw0Kc29t ZSBsaWdodCBvbiB0aGlzLiAgVGhlcmUgYXJlIHNvIG1hbnkgZGlmZmVyZW50IGNvbXByZXNzaW9u IGZvcm1zIGFuZA0Kc2luY2UgZWFjaCBpcyBhbiBvcHRpbWl6YXRpb24gb24gdGhlIHVuY29tcHJl c3NlZCB2ZXJzaW9uLCB0aGVyZSBhcmUgbWFueQ0KZGlmZmVyZW50IHdheXMgdG8gcmVwcmVzZW50 IHRoZSBzYW1lIHRoaW5nLiAgQWxsIHdpdGggZGlmZmVyZW50IHNpemVzIGFuZA0Kb2Zmc2V0cy4g IEF0IGxlYXN0IHRoZXkgYXJlIGFsbCBpbiB0aGUgc2FtZSBzdWl0ZS4gIFRvIG11bHRpcGx5IHRo YXQgd2l0aA0KYWxsIHRoZSBjb21iaW5hdGlvbnMgb2YgSEMxIGFuZCBIQyB3aWxsIGJlIHJlYWxs eSB1bnBsZWFzYW50LiAgTW9yZW92ZXIsDQp0aGUgb25seSB0aGluZyBhbnlvbmUgd2lsbCBldmVy IHVzZSBhZnRlciBhIHNob3J0IHdoaWxlIGlzIEhDLCBzaW5jZSBpdCBpcw0Kc28gbXVjaCBjbGVh bmVyIGFuZCBtb3JlIGVmZmVjdGl2ZS4gIFRoYXQgbWVhbnMgYWxsIHRoZSBIQzEgbWVzcyBhbmQg YWxsDQp0aGUgdGVzdGluZyBhbmQgaW50ZXJvcGVyYWJpbGl0eSBpbnZlc3RtZW50IHdpbGwgYmUg Zm9yIG5vdGhpbmcgb3RoZXIgdGhhbg0KdGhhdCAtIGp1c3QgdG8gcGFzcyB0aGUgdGVzdC4gIEJ1 dCBpdCB3aWxsIGdlbmVyYXRlIGxhdGVudCBidWdzLCBpbmNyZWFzZQ0KdGhlIGZvb3RwcmludCwg YW5kIGZydXN0cmF0ZSBpbnRlcm9wZXJhYmlsdHkuDQoNClNvLCBhcyB3ZSBpbWFnaW5lIGEgZnV0 dXJlIG9mIGJpbGxpb25zIG9mIDZMb1dQQU4gSVAgZGV2aWNlcyBlbWJlZGRlZCBpbg0KaW1wb3J0 YW50IGhhcmQgdG8gcmVhY2ggcGxhY2VzLCBsZXRzIHRha2UgdGhlIHN0ZXAgbm93IHRvIHNpbXBs aWZ5IHRoZWlyDQppbXBsZW1lbnRhdGlvbiBhbmQgdGVzdGluZywgcmF0aGVyIHdvcnJ5IHRvbyBt dWNoIGFib3V0IHNhdmluZyBhIGZldyBob3Vycw0Kb2YgY29kaW5nIGZvciB0aGUgaGFsZiBkb3pl biBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMuICBJZiB0aGF0IGlzIG5vdA0KcmVhc29uIGVub3Vn aCwgdGhvc2Ugc2FtZSBpbXBsZW1lbnRvcnMgd2lsbCBzYXZlIG1hbnkgdGltZXMgdGhhdCBhbW91 bnQgaW4NCnJlZHVjZWQgdGVzdGluZyBhbmQgaW50ZXJvcGVyYWJpbGl0eSB2YWxpZGF0aW9uLg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCjZsb3dwYW4g bWFpbGluZyBsaXN0DQo2bG93cGFuQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvLzZsb3dwYW4NCg== --1__=4EBBFE1ADFBE752E8f9e8a93df938690918c4EBBFE1ADFBE752E Content-type: text/html; charset=UTF-8 Content-Disposition: inline Content-transfer-encoding: base64 PGh0bWw+PGJvZHk+DQo8cD5JIGFtIGFsc28gaW4gZmF2b3Igb2YgdGhhdCBhcHByb2FjaC48YnI+ DQpXZSBoYXZlIGhhZCBpc3N1ZXMgd2l0aCByb3V0aW5nIHBhY2tldHMgZnJvbSA2bG93cGFuIG5v ZGVzIHRvIElQIGhvc3RzLCBhbmQgd2UgZGVmaW5pdGl2ZWx5IG5lZWQgdGhlIEhDIGNvbXByZXNz aW9uIHRvIG1ha2UgdGhpbmdzIGNsZWFuZXIgYW5kIG9wdGltaXplZC48YnI+DQo8YnI+DQpBbnRo b255PGJyPg0KLS08YnI+DQpBbnRob255IFNjaG9vZnM8YnI+DQpSZXNlYXJjaCBTY2llbnRpc3Q8 YnI+DQpQaGlsaXBzIFJlc2VhcmNoPGJyPg0KSGlnaCBUZWNoIENhbXB1cyAzNCAsIDU2NTYgQUUg RWluZGhvdmVuLCBUaGUgTmV0aGVybGFuZHM8YnI+DQpFbWFpbDogYW50aG9ueS5zY2hvb2ZzQHBo aWxpcHMuY29tPGJyPg0KPGJyPg0KPGltZyBzcmM9ImNpZDoxMF9fPTRFQkJGRTFBREZCRTc1MkU4 ZjllOGE5M2RmOTNAcGhpbGlwcy5jb20iIHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiIgYWx0PSJJbmFj dGl2ZSBoaWRlIGRldGFpbHMgZm9yICZxdW90O1Bhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkmcXVv dDsgJmx0O3B0aHViZXJ0QGNpc2NvLmNvbSZndDsiPiZxdW90O1Bhc2NhbCBUaHViZXJ0IChwdGh1 YmVydCkmcXVvdDsgJmx0O3B0aHViZXJ0QGNpc2NvLmNvbSZndDs8YnI+DQo8YnI+DQo8YnI+DQoN Cjx0YWJsZSB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRp bmc9IjAiPg0KPHRyIHZhbGlnbj0idG9wIj48dGQgc3R5bGU9ImJhY2tncm91bmQtaW1hZ2U6dXJs KGNpZDoyMF9fPTRFQkJGRTFBREZCRTc1MkU4ZjllOGE5M2RmOTNAcGhpbGlwcy5jb20pOyBiYWNr Z3JvdW5kLXJlcGVhdDogbm8tcmVwZWF0OyAiIHdpZHRoPSIzNCUiPg0KPHVsPjxiPjxmb250IHNp emU9IjIiPiZxdW90O1Bhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkmcXVvdDsgJmx0O3B0aHViZXJ0 QGNpc2NvLmNvbSZndDs8L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiPiA8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPSIyIj5TZW50IGJ5OjwvZm9udD48YnI+DQo8Zm9udCBzaXplPSIyIj42bG93cGFuLWJv dW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSIyIj4xNy0wNy0yMDA4IDEwOjEz PC9mb250PjwvdWw+DQo8L3RkPjx0ZCB3aWR0aD0iNjYlIj4NCjx0YWJsZSB3aWR0aD0iMTAwJSIg Ym9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRyIHZhbGlnbj0i dG9wIj48dGQgd2lkdGg9IjElIj48aW1nIHNyYz0iY2lkOjMwX189NEVCQkZFMUFERkJFNzUyRThm OWU4YTkzZGY5M0BwaGlsaXBzLmNvbSIgYm9yZGVyPSIwIiBoZWlnaHQ9IjEiIHdpZHRoPSI5OCIg YWx0PSIiPjxicj4NCjxkaXYgYWxpZ249InJpZ2h0Ij48Zm9udCBzaXplPSIyIj5UbzwvZm9udD48 L2Rpdj48L3RkPjx0ZCB3aWR0aD0iMTAwJSI+PGltZyBzcmM9ImNpZDozMF9fPTRFQkJGRTFBREZC RTc1MkU4ZjllOGE5M2RmOTNAcGhpbGlwcy5jb20iIGJvcmRlcj0iMCIgaGVpZ2h0PSIxIiB3aWR0 aD0iMSIgYWx0PSIiPjxicj4NCjxmb250IHNpemU9IjIiPiZxdW90O0RhdmlkIEN1bGxlciZxdW90 OyAmbHQ7ZGF2aWQuY3VsbGVyQGdtYWlsLmNvbSZndDs8YnI+DQombHQ7Nmxvd3BhbkBpZXRmLm9y ZyZndDs8L2ZvbnQ+PC90ZD48L3RyPg0KDQo8dHIgdmFsaWduPSJ0b3AiPjx0ZCB3aWR0aD0iMSUi PjxpbWcgc3JjPSJjaWQ6MzBfXz00RUJCRkUxQURGQkU3NTJFOGY5ZThhOTNkZjkzQHBoaWxpcHMu Y29tIiBib3JkZXI9IjAiIGhlaWdodD0iMSIgd2lkdGg9Ijk4IiBhbHQ9IiI+PGJyPg0KPGRpdiBh bGlnbj0icmlnaHQiPjxmb250IHNpemU9IjIiPmNjPC9mb250PjwvZGl2PjwvdGQ+PHRkIHdpZHRo PSIxMDAlIj48aW1nIHNyYz0iY2lkOjMwX189NEVCQkZFMUFERkJFNzUyRThmOWU4YTkzZGY5M0Bw aGlsaXBzLmNvbSIgYm9yZGVyPSIwIiBoZWlnaHQ9IjEiIHdpZHRoPSIxIiBhbHQ9IiI+PGJyPg0K PC90ZD48L3RyPg0KDQo8dHIgdmFsaWduPSJ0b3AiPjx0ZCB3aWR0aD0iMSUiPjxpbWcgc3JjPSJj aWQ6MzBfXz00RUJCRkUxQURGQkU3NTJFOGY5ZThhOTNkZjkzQHBoaWxpcHMuY29tIiBib3JkZXI9 IjAiIGhlaWdodD0iMSIgd2lkdGg9Ijk4IiBhbHQ9IiI+PGJyPg0KPGRpdiBhbGlnbj0icmlnaHQi Pjxmb250IHNpemU9IjIiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+PC90ZD48dGQgd2lkdGg9IjEwMCUi PjxpbWcgc3JjPSJjaWQ6MzBfXz00RUJCRkUxQURGQkU3NTJFOGY5ZThhOTNkZjkzQHBoaWxpcHMu Y29tIiBib3JkZXI9IjAiIGhlaWdodD0iMSIgd2lkdGg9IjEiIGFsdD0iIj48YnI+DQo8Zm9udCBz aXplPSIyIj5SZTogWzZsb3dwYW5dIEhDPC9mb250PjwvdGQ+PC90cj4NCg0KPHRyIHZhbGlnbj0i dG9wIj48dGQgd2lkdGg9IjElIiB2YWxpZ249Im1pZGRsZSI+PGltZyBzcmM9ImNpZDozMF9fPTRF QkJGRTFBREZCRTc1MkU4ZjllOGE5M2RmOTNAcGhpbGlwcy5jb20iIGJvcmRlcj0iMCIgaGVpZ2h0 PSIxIiB3aWR0aD0iOTgiIGFsdD0iIj48YnI+DQo8ZGl2IGFsaWduPSJyaWdodCI+PGZvbnQgc2l6 ZT0iMiI+Q2xhc3NpZmljYXRpb248L2ZvbnQ+PC9kaXY+PC90ZD48dGQgd2lkdGg9IjEwMCUiIHZh bGlnbj0ibWlkZGxlIj48aW1nIHNyYz0iY2lkOjMwX189NEVCQkZFMUFERkJFNzUyRThmOWU4YTkz ZGY5M0BwaGlsaXBzLmNvbSIgYm9yZGVyPSIwIiBoZWlnaHQ9IjEiIHdpZHRoPSIxIiBhbHQ9IiI+ PGJyPg0KPC90ZD48L3RyPg0KPC90YWJsZT4NCg0KPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHNwYWNp bmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0ciB2YWxpZ249InRvcCI+PHRkIHdpZHRoPSI1OCI+ PGltZyBzcmM9ImNpZDozMF9fPTRFQkJGRTFBREZCRTc1MkU4ZjllOGE5M2RmOTNAcGhpbGlwcy5j b20iIGJvcmRlcj0iMCIgaGVpZ2h0PSIxIiB3aWR0aD0iMSIgYWx0PSIiPjwvdGQ+PHRkIHdpZHRo PSIzMzYiPjxpbWcgc3JjPSJjaWQ6MzBfXz00RUJCRkUxQURGQkU3NTJFOGY5ZThhOTNkZjkzQHBo aWxpcHMuY29tIiBib3JkZXI9IjAiIGhlaWdodD0iMSIgd2lkdGg9IjEiIGFsdD0iIj48L3RkPjwv dHI+DQo8L3RhYmxlPg0KPC90ZD48L3RyPg0KPC90YWJsZT4NCjxicj4NCjxmb250IGNvbG9yPSIj MDAwMDgwIiBmYWNlPSJBcmlhbCI+SGkgRGF2aWQ6PC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIj MDAwMDgwIiBmYWNlPSJBcmlhbCI+IDwvZm9udD48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDA4MCIg ZmFjZT0iQXJpYWwiPkkgZG8gc3VwcG9ydCB0aGF0IGFwcHJvYWNoLiBJ4oCZZCBub3RlIHRoYXQg aXQgd291bGQgaW1wb3NlIHNvbWUgcHJlc3N1cmUgdG8gcmVsZWFzZSBIQyByYXRoZXIgcXVpY2ts eS48L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwODAiIGZhY2U9IkFyaWFsIj5JcyB0aGVy ZSBhIHdheSB0byBnZXQgYSBmZWVkYmFjayBvbiBleGlzdGluZyBkZXBsb3ltZW50cyB0aGF0IHVz ZSA2TG9XUEFOIEhDMT8gPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDgwIiBmYWNlPSJB cmlhbCI+IDwvZm9udD48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDA4MCIgZmFjZT0iQXJpYWwiPlBh c2NhbDwvZm9udD48ZGl2IGFsaWduPSJjZW50ZXIiPjxociB3aWR0aD0iMTAwJSIgc2l6ZT0iMiIg YWxpZ249ImNlbnRlciI+PC9kaXY+PGI+PGZvbnQgZmFjZT0iVGFob21hIj5Gcm9tOjwvZm9udD48 L2I+PGZvbnQgZmFjZT0iVGFob21hIj4gNmxvd3Bhbi1ib3VuY2VzQGlldGYub3JnIFs8YSBocmVm PSJtYWlsdG86Nmxvd3Bhbi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86Nmxvd3Bhbi1ib3VuY2Vz QGlldGYub3JnPC9hPl0gPC9mb250PjxiPjxmb250IGZhY2U9IlRhaG9tYSI+T24gQmVoYWxmIE9m IDwvZm9udD48L2I+PGZvbnQgZmFjZT0iVGFob21hIj5EYXZpZCBDdWxsZXI8L2ZvbnQ+PGI+PGZv bnQgZmFjZT0iVGFob21hIj48YnI+DQpTZW50OjwvZm9udD48L2I+PGZvbnQgZmFjZT0iVGFob21h Ij4gbWVyY3JlZGkgMTYganVpbGxldCAyMDA4IDE4OjI1PC9mb250PjxiPjxmb250IGZhY2U9IlRh aG9tYSI+PGJyPg0KVG86PC9mb250PjwvYj48Zm9udCBmYWNlPSJUYWhvbWEiPiA2bG93cGFuQGll dGYub3JnPC9mb250PjxiPjxmb250IGZhY2U9IlRhaG9tYSI+PGJyPg0KU3ViamVjdDo8L2ZvbnQ+ PC9iPjxmb250IGZhY2U9IlRhaG9tYSI+IFs2bG93cGFuXSBIQzwvZm9udD48YnI+DQo8Zm9udCBz aXplPSI0IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGJyPg0KPGZvbnQgc2l6ZT0i NCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JdCBhcHBlYXJzIHRoYXQgdGhlIDZMb1dQQU4gV0cg aXMgcG9pc2VkIHRvIHRha2UgdXAgc2VyaW91cyBkaXNjdXNzaW9uIG9mIEhDICg8L2ZvbnQ+PGEg aHJlZj0iaHR0cDovL3d3dzMudG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odWktNmxvd3Bhbi1o Yy0wMCI+PHU+PGZvbnQgc2l6ZT0iNCIgY29sb3I9IiMwMDAwRkYiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+aHR0cDovL3d3dzMudG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odWktNmxvd3Bhbi1o Yy0wMDwvZm9udD48L3U+PC9hPjxmb250IHNpemU9IjQiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ KSBhbmQgSSB3b3VsZCBsaWtlIHRvIGVuY291cmFnZSB1cyB0byBtYWtlIGEgYm9sZCBtb3ZlIGZv cndhcmQgd2hpbGUgdGhlIG51bWJlciBvZiAmcXVvdDtkdXN0eSBkZWNrIDZMb1dQQU4gaW1wbGVt ZW50YXRpb25zJnF1b3Q7IGFyZSBmZXcgLSBlbGltaW5hdGUgSEMxL0hDMiBpbiB0aGUgcHJvY2Vz cy48YnI+DQo8YnI+DQpBcyBhIGJpdCBvZiBiYWNrZ3JvdW5kLCB0aGUgb3JpZ2luYWwgZm9ybWF0 IGRvY3VtZW50IGRlZmluZWQgSEMxIGZvciBjb21wcmVzc2lvbiBvZiBsaW5rIGxvY2FsIElQdjYg YWRkcmVzc2VzIGFuZCBIQzIgZm9yIGNvbXByZXNzaW9uIG9mIFVEUCBhbmQgSUNNUCBoZWFkZXJz LiAgQm90aCB3ZXJlIHBhcnQgb2YgYSByYXRoZXIgYXdrd2FyZCBlbmNvZGluZy4gIE1vc3Qgb3Ro ZXIgcGFydHMgb2YgdGhlIGVuY29kaW5nIGdvdCBjbGVhbmVkIHVwIHdpdGggdGhlIHN3aXRjaCB0 byB0aGUgc3RhY2tlZCBoZWFkZXIgZm9ybWF0IHRoYXQgd2VudCB0byBSRkMuICBBc2lkZSBmcm9t IGl0cyBhd2t3YXJkbmVzcywgSEMxIHdhcyBuZXZlciBzdWZmaWNpZW50LCBiZWNhdXNlIGl0IHBy b3ZpZGVkIG5vIGNvbXByZXNzaW9uIG9mIHJvdXRhYmxlIGFkZHJlc3Nlcywgbm9yIGZvciB0aGUg bW9zdCB1c2VmdWwgbXVsdGljYXN0IGFkZHJlc3NlcyAtIGJvdGggcmF0aGVyIGVzc2VudGlhbCB0 byBJUHY2LiAgSEMxZyB3YXMgcHJvcG9zZWQgdG8gcHJvdmlkZSBhIHNpbWlsYXIgKHNvbWV3aGF0 IG1vcmUgZWZmZWN0aXZlKSBzdGF0ZWxlc3MgY29tcHJlc3Npb24gb2YgY29tbW9uIGFkZHJlc3Nl cyBvZiBnbG9iYWwgc2NvcGUuICBUaGlzIG1lYW50IHR3byBzaW1pbGFyIGNvbXByZXNzaW9uIHNj aGVtZXMsIEhDMSBmb3IgbGluay1sb2NhbCwgSEMxRyBmb3IgZ2xvYmFsLiAgQm90aCBhcmUgaW1w bGVtZW50YWJsZSB3aXRoIG11Y2ggbGVzcyB0aGFuIGEgdGhvdXNhbmQgbGluZXMgb2YgY29kZS4g IE5vIGFtYmlndWl0eSBhYm91dCB3aGVuIHRvIHVzZSB3aGljaC48YnI+DQo8YnI+DQpIQyBwcm92 aWRlcyBhIG11Y2ggY2xlYW5lciBhcHByb2FjaCB3aGljaCBzdWJzdW1lcyBib3RoIEhDMSBhbmQg SEMxZywgYmV0dGVyIHN1cHBvcnRzIG11bHRpY2FzdCwgYW5kIGlzIG11Y2ggbW9yZSB1c2FibGUg d2l0aCBJUHY2IHN0YWNrZWQgaGVhZGVycyBiZWNhdXNlIHRoZSBvcmRlciBvZiB0aGUgc3ViaGVh ZGVycyBpcyByZXNwZWN0ZWQuICAoSEMyIGNvbWVzIGluIGJldHdlZW4gdGhlIGRpc3BhdGNoIGFu ZCB0aGUgYWRkcmVzcyBzdWJoZWFkZXIsIHJhdGhlciB0aGFuIGFzIGEgcG9ydGlvbiBvZiB0aGUg dHJhbnNwb3J0IHN1YmhlYWRlcikuPGJyPg0KPGJyPg0KVGhlIGRlY2lzaW9uIHRvIHRha2Ugb24g SEMsIGNsZWFuIHVwIHRoZSByb3VnaCBlZGdlcywgYW5kIGJ1aWxkIGNvbnNlbnN1cyBhcm91bmQg aXQgaXMgdGhlIGVhc3kgcGFydC4gIFRoZSBib2xkZXIgc3RlcCB0aGF0IEkgd291bGQgbGlrZSB0 byBzdWdnZXN0IGlzIHRoYXQgd2UgZGVwcmVjYXRlIEhDMSBhbmQgZ2V0IGl0IHJlbW92ZWQgc29v bi48YnI+DQo8YnI+DQpJdCBpcyBhbHdheXMgZWFzaWVyIHRvIG1haW50YWluIGJhY2t3YXJkIGNv bXBhdGliaWxpdHkgdGhhbiB0byBtYWtlIGEgY2xlYW4gYnJlYWsuICBCdXQsIHVsdGltYXRlbHkg dGhhdCBpcyBidXJkZW5pbmcgYWxsIHRoZSBtYW55IGZ1dHVyZSBpbXBsZW1lbnRhdGlvbnMgaW4g b3JkZXIgdG8gYXZvaWQgYSBidXJkZW4gb24gdGhlIGZldyBjdXJyZW50IGltcGxlbWVudGF0aW9u cy48YnI+DQo8YnI+DQpUaGUgcmVhc29uIHRvIGF2b2lkIHRoaXMgYnVyZGVuIGlzIG5vdCB0aGF0 IGVpdGhlciBpcyBhIGh1Z2UgYW1vdW50IG9mIGNvZGUuICBJbXBsZW1lbnRpbmcgYW55IG9mIHRo ZXNlIEhDcyBpcyBvbmx5IHNldmVyYWwgaHVuZHJlZCBMT0MuICBUaGUgaXNzdWUgaXMgdGVzdGlu ZyBhbmQgaW50ZXJvcGVyYWJpbGl0eS4gVGhlIGludGVyb3BlcmFiaWxpdHkgZHJhZnQgc2hlZHMg c29tZSBsaWdodCBvbiB0aGlzLiAgVGhlcmUgYXJlIHNvIG1hbnkgZGlmZmVyZW50IGNvbXByZXNz aW9uIGZvcm1zIGFuZCBzaW5jZSBlYWNoIGlzIGFuIG9wdGltaXphdGlvbiBvbiB0aGUgdW5jb21w cmVzc2VkIHZlcnNpb24sIHRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlzIHRvIHJlcHJlc2Vu dCB0aGUgc2FtZSB0aGluZy4gIEFsbCB3aXRoIGRpZmZlcmVudCBzaXplcyBhbmQgb2Zmc2V0cy4g IEF0IGxlYXN0IHRoZXkgYXJlIGFsbCBpbiB0aGUgc2FtZSBzdWl0ZS4gIFRvIG11bHRpcGx5IHRo YXQgd2l0aCBhbGwgdGhlIGNvbWJpbmF0aW9ucyBvZiBIQzEgYW5kIEhDIHdpbGwgYmUgcmVhbGx5 IHVucGxlYXNhbnQuICBNb3Jlb3ZlciwgdGhlIG9ubHkgdGhpbmcgYW55b25lIHdpbGwgZXZlciB1 c2UgYWZ0ZXIgYSBzaG9ydCB3aGlsZSBpcyBIQywgc2luY2UgaXQgaXMgc28gbXVjaCBjbGVhbmVy IGFuZCBtb3JlIGVmZmVjdGl2ZS4gIFRoYXQgbWVhbnMgYWxsIHRoZSBIQzEgbWVzcyBhbmQgYWxs IHRoZSB0ZXN0aW5nIGFuZCBpbnRlcm9wZXJhYmlsaXR5IGludmVzdG1lbnQgd2lsbCBiZSBmb3Ig bm90aGluZyBvdGhlciB0aGFuIHRoYXQgLSBqdXN0IHRvIHBhc3MgdGhlIHRlc3QuICBCdXQgaXQg d2lsbCBnZW5lcmF0ZSBsYXRlbnQgYnVncywgaW5jcmVhc2UgdGhlIGZvb3RwcmludCwgYW5kIGZy dXN0cmF0ZSBpbnRlcm9wZXJhYmlsdHkuPGJyPg0KPGJyPg0KU28sIGFzIHdlIGltYWdpbmUgYSBm dXR1cmUgb2YgYmlsbGlvbnMgb2YgNkxvV1BBTiBJUCBkZXZpY2VzIGVtYmVkZGVkIGluIGltcG9y dGFudCBoYXJkIHRvIHJlYWNoIHBsYWNlcywgbGV0cyB0YWtlIHRoZSBzdGVwIG5vdyB0byBzaW1w bGlmeSB0aGVpciBpbXBsZW1lbnRhdGlvbiBhbmQgdGVzdGluZywgcmF0aGVyIHdvcnJ5IHRvbyBt dWNoIGFib3V0IHNhdmluZyBhIGZldyBob3VycyBvZiBjb2RpbmcgZm9yIHRoZSBoYWxmIGRvemVu IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4gIElmIHRoYXQgaXMgbm90IHJlYXNvbiBlbm91Z2gs IHRob3NlIHNhbWUgaW1wbGVtZW50b3JzIHdpbGwgc2F2ZSBtYW55IHRpbWVzIHRoYXQgYW1vdW50 IGluIHJlZHVjZWQgdGVzdGluZyBhbmQgaW50ZXJvcGVyYWJpbGl0eSB2YWxpZGF0aW9uLjxicj4N CjwvZm9udD48dHQ+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQo2bG93cGFuIG1haWxpbmcgbGlzdDxicj4NCjZsb3dwYW5AaWV0Zi5vcmc8YnI+DQo8 L3R0Pjx0dD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZs b3dwYW4iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3BhbjwvYT48 L3R0Pjx0dD48YnI+DQo8L3R0Pjxicj4NCjwvYm9keT48L2h0bWw+ --1__=4EBBFE1ADFBE752E8f9e8a93df938690918c4EBBFE1ADFBE752E-- --0__=4EBBFE1ADFBE752E8f9e8a93df938690918c4EBBFE1ADFBE752E Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=4EBBFE1ADFBE752E8f9e8a93df93@philips.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFE1ADFBE752E8f9e8a93df938690918c4EBBFE1ADFBE752E Content-type: image/gif; name="pic00556.gif" Content-Disposition: inline; filename="pic00556.gif" Content-ID: <20__=4EBBFE1ADFBE752E8f9e8a93df93@philips.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFE1ADFBE752E8f9e8a93df938690918c4EBBFE1ADFBE752E Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <30__=4EBBFE1ADFBE752E8f9e8a93df93@philips.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFE1ADFBE752E8f9e8a93df938690918c4EBBFE1ADFBE752E-- --===============1542718080== 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://www.ietf.org/mailman/listinfo/6lowpan --===============1542718080==-- From 6lowpan-bounces@ietf.org Thu Jul 17 08:02:15 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A983A69FD; Thu, 17 Jul 2008 08:02:15 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1C33A69D6; Thu, 17 Jul 2008 07:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc5N1Up2Liup; Thu, 17 Jul 2008 07:54:27 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 26DA43A68A8; Thu, 17 Jul 2008 07:54:27 -0700 (PDT) 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 m6HEskai007582; Thu, 17 Jul 2008 08:54:46 -0600 (MDT) From: Geoff Mulligan To: Anthony Schoofs In-Reply-To: References: Date: Thu, 17 Jul 2008 08:54:41 -0600 Message-Id: <1216306481.6621.123.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 X-Mailman-Approved-At: Thu, 17 Jul 2008 08:02:13 -0700 Cc: 6lowpan-bounces@ietf.org, David Culler , 6lowpan@ietf.org Subject: Re: [6lowpan] HC X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org SSBhbHNvIGFncmVlLiAgTm93IGlzIHRoZSByaWdodCB0aW1lIGJlZm9yZSB3ZSBoYXZlIHRvIGNh cnJ5IHRoaXMgZGVzaWduCmJhZ2dhZ2UgZm9yd2FyZC4KCkFzIFBhc2NhbCBwb2ludGVkIG91dCAt IHdlIHRoZW4gbmVlZCB0byBnZXQgSEMgZG9uZSBzb29uZXIuCgoJZ2VvZmYKCk9uIFRodSwgMjAw OC0wNy0xNyBhdCAxMDo1NiArMDIwMCwgQW50aG9ueSBTY2hvb2ZzIHdyb3RlOgo+IEkgYW0gYWxz byBpbiBmYXZvciBvZiB0aGF0IGFwcHJvYWNoLgo+IFdlIGhhdmUgaGFkIGlzc3VlcyB3aXRoIHJv dXRpbmcgcGFja2V0cyBmcm9tIDZsb3dwYW4gbm9kZXMgdG8gSVAKPiBob3N0cywgYW5kIHdlIGRl ZmluaXRpdmVseSBuZWVkIHRoZSBIQyBjb21wcmVzc2lvbiB0byBtYWtlIHRoaW5ncwo+IGNsZWFu ZXIgYW5kIG9wdGltaXplZC4KPiAKPiBBbnRob255Cj4gLS0KPiBBbnRob255IFNjaG9vZnMKPiBS ZXNlYXJjaCBTY2llbnRpc3QKPiBQaGlsaXBzIFJlc2VhcmNoCj4gSGlnaCBUZWNoIENhbXB1cyAz NCAsIDU2NTYgQUUgRWluZGhvdmVuLCBUaGUgTmV0aGVybGFuZHMKPiBFbWFpbDogYW50aG9ueS5z Y2hvb2ZzQHBoaWxpcHMuY29tCj4gCj4gSW5hY3RpdmUgaGlkZSBkZXRhaWxzIGZvciBQYXNjYWwi UGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSIKPiA8cHRodWJlcnRAY2lzY28uY29tPgo+IAo+IAo+ ICAgICAgICAgIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkiCj4gICAgICAgICA8cHRodWJlcnRA Y2lzY28uY29tPiAKPiAgICAgICAgIAo+ICAgICAgICAgU2VudCBieToKPiAgICAgICAgIDZsb3dw YW4tYm91bmNlc0BpZXRmLm9yZyAKPiAgICAgICAgIAo+ICAgICAgICAgMTctMDctMjAwOCAxMDox Mwo+ICAgICAgICAgCj4gCj4gICAgICAgICAgICAgICAgVG8KPiAKPiAiRGF2aWQgQ3VsbGVyIgo+ IDxkYXZpZC5jdWxsZXJAZ21haWwuY29tPgo+IDw2bG93cGFuQGlldGYub3JnPgo+IAo+ICAgICAg ICAgICAgICAgIGNjCj4gCj4gCj4gCj4gICAgICAgICAgIFN1YmplY3QKPiAKPiBSZTogWzZsb3dw YW5dIEhDCj4gCj4gICAgQ2xhc3NpZmljYXRpb24KPiAKPiAKPiAKPiAKPiAKPiBIaSBEYXZpZDoK PiAKPiBJIGRvIHN1cHBvcnQgdGhhdCBhcHByb2FjaC4gSeKAmWQgbm90ZSB0aGF0IGl0IHdvdWxk IGltcG9zZSBzb21lCj4gcHJlc3N1cmUgdG8gcmVsZWFzZSBIQyByYXRoZXIgcXVpY2tseS4KPiBJ cyB0aGVyZSBhIHdheSB0byBnZXQgYSBmZWVkYmFjayBvbiBleGlzdGluZyBkZXBsb3ltZW50cyB0 aGF0IHVzZQo+IDZMb1dQQU4gSEMxPyAKPiAKPiBQYXNjYWwKPiAKPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiA2bG93cGFuLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzo2bG93cGFuLWJvdW5jZXNAaWV0Zi5vcmddIE9uCj4gQmVoYWxm IE9mIERhdmlkIEN1bGxlcgo+IFNlbnQ6IG1lcmNyZWRpIDE2IGp1aWxsZXQgMjAwOCAxODoyNQo+ IFRvOiA2bG93cGFuQGlldGYub3JnCj4gU3ViamVjdDogWzZsb3dwYW5dIEhDCj4gCj4gSXQgYXBw ZWFycyB0aGF0IHRoZSA2TG9XUEFOIFdHIGlzIHBvaXNlZCB0byB0YWtlIHVwIHNlcmlvdXMgZGlz Y3Vzc2lvbgo+IG9mIEhDIChodHRwOi8vd3d3My50b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1 aS02bG93cGFuLWhjLTAwKSBhbmQgSQo+IHdvdWxkIGxpa2UgdG8gZW5jb3VyYWdlIHVzIHRvIG1h a2UgYSBib2xkIG1vdmUgZm9yd2FyZCB3aGlsZSB0aGUKPiBudW1iZXIgb2YgImR1c3R5IGRlY2sg NkxvV1BBTiBpbXBsZW1lbnRhdGlvbnMiIGFyZSBmZXcgLSBlbGltaW5hdGUKPiBIQzEvSEMyIGlu IHRoZSBwcm9jZXNzLgo+IAo+IEFzIGEgYml0IG9mIGJhY2tncm91bmQsIHRoZSBvcmlnaW5hbCBm b3JtYXQgZG9jdW1lbnQgZGVmaW5lZCBIQzEgZm9yCj4gY29tcHJlc3Npb24gb2YgbGluayBsb2Nh bCBJUHY2IGFkZHJlc3NlcyBhbmQgSEMyIGZvciBjb21wcmVzc2lvbiBvZgo+IFVEUCBhbmQgSUNN UCBoZWFkZXJzLiBCb3RoIHdlcmUgcGFydCBvZiBhIHJhdGhlciBhd2t3YXJkIGVuY29kaW5nLgo+ IE1vc3Qgb3RoZXIgcGFydHMgb2YgdGhlIGVuY29kaW5nIGdvdCBjbGVhbmVkIHVwIHdpdGggdGhl IHN3aXRjaCB0byB0aGUKPiBzdGFja2VkIGhlYWRlciBmb3JtYXQgdGhhdCB3ZW50IHRvIFJGQy4g QXNpZGUgZnJvbSBpdHMgYXdrd2FyZG5lc3MsCj4gSEMxIHdhcyBuZXZlciBzdWZmaWNpZW50LCBi ZWNhdXNlIGl0IHByb3ZpZGVkIG5vIGNvbXByZXNzaW9uIG9mCj4gcm91dGFibGUgYWRkcmVzc2Vz LCBub3IgZm9yIHRoZSBtb3N0IHVzZWZ1bCBtdWx0aWNhc3QgYWRkcmVzc2VzIC0gYm90aAo+IHJh dGhlciBlc3NlbnRpYWwgdG8gSVB2Ni4gSEMxZyB3YXMgcHJvcG9zZWQgdG8gcHJvdmlkZSBhIHNp bWlsYXIKPiAoc29tZXdoYXQgbW9yZSBlZmZlY3RpdmUpIHN0YXRlbGVzcyBjb21wcmVzc2lvbiBv ZiBjb21tb24gYWRkcmVzc2VzIG9mCj4gZ2xvYmFsIHNjb3BlLiBUaGlzIG1lYW50IHR3byBzaW1p bGFyIGNvbXByZXNzaW9uIHNjaGVtZXMsIEhDMSBmb3IKPiBsaW5rLWxvY2FsLCBIQzFHIGZvciBn bG9iYWwuIEJvdGggYXJlIGltcGxlbWVudGFibGUgd2l0aCBtdWNoIGxlc3MKPiB0aGFuIGEgdGhv dXNhbmQgbGluZXMgb2YgY29kZS4gTm8gYW1iaWd1aXR5IGFib3V0IHdoZW4gdG8gdXNlIHdoaWNo Lgo+IAo+IEhDIHByb3ZpZGVzIGEgbXVjaCBjbGVhbmVyIGFwcHJvYWNoIHdoaWNoIHN1YnN1bWVz IGJvdGggSEMxIGFuZCBIQzFnLAo+IGJldHRlciBzdXBwb3J0cyBtdWx0aWNhc3QsIGFuZCBpcyBt dWNoIG1vcmUgdXNhYmxlIHdpdGggSVB2NiBzdGFja2VkCj4gaGVhZGVycyBiZWNhdXNlIHRoZSBv cmRlciBvZiB0aGUgc3ViaGVhZGVycyBpcyByZXNwZWN0ZWQuIChIQzIgY29tZXMKPiBpbiBiZXR3 ZWVuIHRoZSBkaXNwYXRjaCBhbmQgdGhlIGFkZHJlc3Mgc3ViaGVhZGVyLCByYXRoZXIgdGhhbiBh cyBhCj4gcG9ydGlvbiBvZiB0aGUgdHJhbnNwb3J0IHN1YmhlYWRlcikuCj4gCj4gVGhlIGRlY2lz aW9uIHRvIHRha2Ugb24gSEMsIGNsZWFuIHVwIHRoZSByb3VnaCBlZGdlcywgYW5kIGJ1aWxkCj4g Y29uc2Vuc3VzIGFyb3VuZCBpdCBpcyB0aGUgZWFzeSBwYXJ0LiBUaGUgYm9sZGVyIHN0ZXAgdGhh dCBJIHdvdWxkCj4gbGlrZSB0byBzdWdnZXN0IGlzIHRoYXQgd2UgZGVwcmVjYXRlIEhDMSBhbmQg Z2V0IGl0IHJlbW92ZWQgc29vbi4KPiAKPiBJdCBpcyBhbHdheXMgZWFzaWVyIHRvIG1haW50YWlu IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgdGhhbiB0byBtYWtlIGEKPiBjbGVhbiBicmVhay4gQnV0 LCB1bHRpbWF0ZWx5IHRoYXQgaXMgYnVyZGVuaW5nIGFsbCB0aGUgbWFueSBmdXR1cmUKPiBpbXBs ZW1lbnRhdGlvbnMgaW4gb3JkZXIgdG8gYXZvaWQgYSBidXJkZW4gb24gdGhlIGZldyBjdXJyZW50 Cj4gaW1wbGVtZW50YXRpb25zLgo+IAo+IFRoZSByZWFzb24gdG8gYXZvaWQgdGhpcyBidXJkZW4g aXMgbm90IHRoYXQgZWl0aGVyIGlzIGEgaHVnZSBhbW91bnQgb2YKPiBjb2RlLiBJbXBsZW1lbnRp bmcgYW55IG9mIHRoZXNlIEhDcyBpcyBvbmx5IHNldmVyYWwgaHVuZHJlZCBMT0MuIFRoZQo+IGlz c3VlIGlzIHRlc3RpbmcgYW5kIGludGVyb3BlcmFiaWxpdHkuIFRoZSBpbnRlcm9wZXJhYmlsaXR5 IGRyYWZ0Cj4gc2hlZHMgc29tZSBsaWdodCBvbiB0aGlzLiBUaGVyZSBhcmUgc28gbWFueSBkaWZm ZXJlbnQgY29tcHJlc3Npb24KPiBmb3JtcyBhbmQgc2luY2UgZWFjaCBpcyBhbiBvcHRpbWl6YXRp b24gb24gdGhlIHVuY29tcHJlc3NlZCB2ZXJzaW9uLAo+IHRoZXJlIGFyZSBtYW55IGRpZmZlcmVu dCB3YXlzIHRvIHJlcHJlc2VudCB0aGUgc2FtZSB0aGluZy4gQWxsIHdpdGgKPiBkaWZmZXJlbnQg c2l6ZXMgYW5kIG9mZnNldHMuIEF0IGxlYXN0IHRoZXkgYXJlIGFsbCBpbiB0aGUgc2FtZSBzdWl0 ZS4KPiBUbyBtdWx0aXBseSB0aGF0IHdpdGggYWxsIHRoZSBjb21iaW5hdGlvbnMgb2YgSEMxIGFu ZCBIQyB3aWxsIGJlCj4gcmVhbGx5IHVucGxlYXNhbnQuIE1vcmVvdmVyLCB0aGUgb25seSB0aGlu ZyBhbnlvbmUgd2lsbCBldmVyIHVzZSBhZnRlcgo+IGEgc2hvcnQgd2hpbGUgaXMgSEMsIHNpbmNl IGl0IGlzIHNvIG11Y2ggY2xlYW5lciBhbmQgbW9yZSBlZmZlY3RpdmUuCj4gVGhhdCBtZWFucyBh bGwgdGhlIEhDMSBtZXNzIGFuZCBhbGwgdGhlIHRlc3RpbmcgYW5kIGludGVyb3BlcmFiaWxpdHkK PiBpbnZlc3RtZW50IHdpbGwgYmUgZm9yIG5vdGhpbmcgb3RoZXIgdGhhbiB0aGF0IC0ganVzdCB0 byBwYXNzIHRoZQo+IHRlc3QuIEJ1dCBpdCB3aWxsIGdlbmVyYXRlIGxhdGVudCBidWdzLCBpbmNy ZWFzZSB0aGUgZm9vdHByaW50LCBhbmQKPiBmcnVzdHJhdGUgaW50ZXJvcGVyYWJpbHR5Lgo+IAo+ IFNvLCBhcyB3ZSBpbWFnaW5lIGEgZnV0dXJlIG9mIGJpbGxpb25zIG9mIDZMb1dQQU4gSVAgZGV2 aWNlcyBlbWJlZGRlZAo+IGluIGltcG9ydGFudCBoYXJkIHRvIHJlYWNoIHBsYWNlcywgbGV0cyB0 YWtlIHRoZSBzdGVwIG5vdyB0byBzaW1wbGlmeQo+IHRoZWlyIGltcGxlbWVudGF0aW9uIGFuZCB0 ZXN0aW5nLCByYXRoZXIgd29ycnkgdG9vIG11Y2ggYWJvdXQgc2F2aW5nIGEKPiBmZXcgaG91cnMg b2YgY29kaW5nIGZvciB0aGUgaGFsZiBkb3plbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMuIElm Cj4gdGhhdCBpcyBub3QgcmVhc29uIGVub3VnaCwgdGhvc2Ugc2FtZSBpbXBsZW1lbnRvcnMgd2ls bCBzYXZlIG1hbnkKPiB0aW1lcyB0aGF0IGFtb3VudCBpbiByZWR1Y2VkIHRlc3RpbmcgYW5kIGlu dGVyb3BlcmFiaWxpdHkgdmFsaWRhdGlvbi4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+IDZsb3dwYW4gbWFpbGluZyBsaXN0Cj4gNmxvd3BhbkBpZXRm Lm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3Bhbgo+IAo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gNmxvd3Bh biBtYWlsaW5nIGxpc3QKPiA2bG93cGFuQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby82bG93cGFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo2bG93cGFuIG1haWxpbmcgbGlzdAo2bG93cGFuQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3Bhbgo= From 6lowpan-bounces@ietf.org Thu Jul 17 17:39:36 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0E23A67B6; Thu, 17 Jul 2008 17:39:36 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23DAB3A67B6 for <6lowpan@core3.amsl.com>; Thu, 17 Jul 2008 17:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.216 X-Spam-Level: X-Spam-Status: No, score=0.216 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, J_CHICKENPOX_66=0.6, MISSING_HEADERS=1.292, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9niEatb2LnB for <6lowpan@core3.amsl.com>; Thu, 17 Jul 2008 17:39:34 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id F37D23A63D2 for <6lowpan@ietf.org>; Thu, 17 Jul 2008 17:39:33 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so113256rvf.49 for <6lowpan@ietf.org>; Thu, 17 Jul 2008 17:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=TC7aKJ9pu/AGD15A73Jnf1ZP2/jbgi9OA6eNRgtMHZw=; b=vvI+1POIeVsWwgaSRbqLOBj7rSaVJVs0puVlskfm5XCASsqJtIOygfvSndOY26hra7 czaHcDq/UKzuFteyOe3YNkxhhLtI93r9YodGhENubR3lZmOx/QrJwV85jljj2gKNFBwj aEPXT7WzOuLodq3qLkFIJnd9JFHbfqx2HzpTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=nuK8JP0ycjFnMlIqQ1YRWdBqcCmht8QxOCSr+JThFAvAS7rdt5jboqL3E2VuHV9ff5 jaPKgb1D7/m1cDR5GM5Ts9vOMUJHPkZchwtZeGdwIuDZGxXMZH/qvnrZmUZr6lXy7sLT imU7mEK73+DEe+RBvrPq0bi0ZNc17kQ/Us2aI= Received: by 10.140.202.21 with SMTP id z21mr1554039rvf.81.1216341603899; Thu, 17 Jul 2008 17:40:03 -0700 (PDT) Received: by 10.141.33.10 with HTTP; Thu, 17 Jul 2008 17:40:03 -0700 (PDT) Message-ID: <44680fe70807171740w4a53b1dfm62589f7a7fba1e5b@mail.gmail.com> Date: Thu, 17 Jul 2008 17:40:03 -0700 From: "Stephen Dawson-Haggerty" In-Reply-To: <1216306481.6621.123.camel@dellx1> MIME-Version: 1.0 Content-Disposition: inline References: <1216306481.6621.123.camel@dellx1> X-Google-Sender-Auth: c4a32b3f8e81202e Cc: 6lowpan@ietf.org, David Culler Subject: Re: [6lowpan] HC X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org I'd like to weigh in with a few notes that people on this list might be interested in. First, I've released the Berkeley 6lowpan implementation for TinyOS into tinyos-2.x-contrib/berkeley/b6lowpan under a BSD license. It is still very much a work in progress, but it should be useful to anyone wanting to experiment with 6lowpan. It uses HC for header compression and IPv6 stateless autoconf for prefix assignment. It provides UDP as the transport, and supports multi-hop routing. Standard tools like ping6, nc6, and tracert6 all work with the stack. More information is available on the project wiki (http://smote.cs.berkeley.edu:8000/tracenv/wiki/b6loWPAN). Second, it might be useful to (re)start the conversation about HC. Overall, it's relatively clean and easy to implement; many of the implementation choices surrounding a 6lowpan stack aren't really that affected by how headers are compressed. There are a couple of things neither the draft nor 4944 directly address, though: - support route-over combined with no hop-by-hop reassembly - support source routing As older discussions on the list have gone over, the first is currently possible by unpacking the IP headers in the first fragment and caching the routing information for successive fragments. I think it's probably not necessary to do anything other then declare that the compressed IP headers must fit into the first fragment, but there could be other ideas for how to best allow this. The second belongs in any standard, because it interacts with address compression: the source route can be used to infer the source and destination IP address for intra-pan routing. What I would suggest here is the addition of an LOWPAN_HCNH encoding for source routing. This also brings up the issue it should be possible to follow this header (NHSR?) with a NH_UDP encoding block so as to have compressed source routing as well as UDP headers. Whatever header format is decided on should also support a record route option in the dispatch byte. If people agree that this is important, I can write up a proposal on how to do this. What else do people see as needing work in HC? Steve On Thu, Jul 17, 2008 at 7:54 AM, Geoff Mulligan wrote: > I also agree. Now is the right time before we have to carry this design > baggage forward. > > As Pascal pointed out - we then need to get HC done sooner. > > geoff > > On Thu, 2008-07-17 at 10:56 +0200, Anthony Schoofs wrote: >> I am also in favor of that approach. >> We have had issues with routing packets from 6lowpan nodes to IP >> hosts, and we definitively need the HC compression to make things >> cleaner and optimized. >> >> Anthony >> -- >> Anthony Schoofs >> Research Scientist >> Philips Research >> High Tech Campus 34 , 5656 AE Eindhoven, The Netherlands >> Email: anthony.schoofs@philips.com >> >> Inactive hide details for Pascal"Pascal Thubert (pthubert)" >> >> >> >> "Pascal Thubert (pthubert)" >> >> >> Sent by: >> 6lowpan-bounces@ietf.org >> >> 17-07-2008 10:13 >> >> >> To >> >> "David Culler" >> >> <6lowpan@ietf.org> >> >> cc >> >> >> >> Subject >> >> Re: [6lowpan] HC >> >> Classification >> >> >> >> >> >> Hi David: >> >> I do support that approach. I'd note that it would impose some >> pressure to release HC rather quickly. >> Is there a way to get a feedback on existing deployments that use >> 6LoWPAN HC1? >> >> Pascal >> >> >> ______________________________________________________________________ >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of David Culler >> Sent: mercredi 16 juillet 2008 18:25 >> To: 6lowpan@ietf.org >> Subject: [6lowpan] HC >> >> It appears that the 6LoWPAN WG is poised to take up serious discussion >> of HC (http://www3.tools.ietf.org/html/draft-hui-6lowpan-hc-00) and I >> would like to encourage us to make a bold move forward while the >> number of "dusty deck 6LoWPAN implementations" are few - eliminate >> HC1/HC2 in the process. >> >> As a bit of background, the original format document defined HC1 for >> compression of link local IPv6 addresses and HC2 for compression of >> UDP and ICMP headers. Both were part of a rather awkward encoding. >> Most other parts of the encoding got cleaned up with the switch to the >> stacked header format that went to RFC. Aside from its awkwardness, >> HC1 was never sufficient, because it provided no compression of >> routable addresses, nor for the most useful multicast addresses - both >> rather essential to IPv6. HC1g was proposed to provide a similar >> (somewhat more effective) stateless compression of common addresses of >> global scope. This meant two similar compression schemes, HC1 for >> link-local, HC1G for global. Both are implementable with much less >> than a thousand lines of code. No ambiguity about when to use which. >> >> HC provides a much cleaner approach which subsumes both HC1 and HC1g, >> better supports multicast, and is much more usable with IPv6 stacked >> headers because the order of the subheaders is respected. (HC2 comes >> in between the dispatch and the address subheader, rather than as a >> portion of the transport subheader). >> >> The decision to take on HC, clean up the rough edges, and build >> consensus around it is the easy part. The bolder step that I would >> like to suggest is that we deprecate HC1 and get it removed soon. >> >> It is always easier to maintain backward compatibility than to make a >> clean break. But, ultimately that is burdening all the many future >> implementations in order to avoid a burden on the few current >> implementations. >> >> The reason to avoid this burden is not that either is a huge amount of >> code. Implementing any of these HCs is only several hundred LOC. The >> issue is testing and interoperability. The interoperability draft >> sheds some light on this. There are so many different compression >> forms and since each is an optimization on the uncompressed version, >> there are many different ways to represent the same thing. All with >> different sizes and offsets. At least they are all in the same suite. >> To multiply that with all the combinations of HC1 and HC will be >> really unpleasant. Moreover, the only thing anyone will ever use after >> a short while is HC, since it is so much cleaner and more effective. >> That means all the HC1 mess and all the testing and interoperability >> investment will be for nothing other than that - just to pass the >> test. But it will generate latent bugs, increase the footprint, and >> frustrate interoperabilty. >> >> So, as we imagine a future of billions of 6LoWPAN IP devices embedded >> in important hard to reach places, lets take the step now to simplify >> their implementation and testing, rather worry too much about saving a >> few hours of coding for the half dozen existing implementations. If >> that is not reason enough, those same implementors will save many >> times that amount in reduced testing and interoperability validation. >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 17 19:12:39 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8503E3A6A32; Thu, 17 Jul 2008 19:12:39 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC55D3A6A1D for <6lowpan@core3.amsl.com>; Thu, 17 Jul 2008 19:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E0pujcySCr2 for <6lowpan@core3.amsl.com>; Thu, 17 Jul 2008 19:12:36 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id ADE993A6A08 for <6lowpan@ietf.org>; Thu, 17 Jul 2008 19:12:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 5C57BAF883; Thu, 17 Jul 2008 19:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC82D3GeXgfF; Thu, 17 Jul 2008 19:13:08 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-88-226.dsl.pltn13.pacbell.net [71.142.88.226]) by mail.sf.archrock.com (Postfix) with ESMTP id 5322DAF85E; Thu, 17 Jul 2008 19:13:08 -0700 (PDT) Message-Id: <6C5CA78E-94B5-419A-85D0-B1DC1FAA28B1@archrock.com> From: Jonathan Hui To: Stephen Dawson-Haggerty In-Reply-To: <44680fe70807171740w4a53b1dfm62589f7a7fba1e5b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 17 Jul 2008 19:13:06 -0700 References: <1216306481.6621.123.camel@dellx1> <44680fe70807171740w4a53b1dfm62589f7a7fba1e5b@mail.gmail.com> X-Mailer: Apple Mail (2.926) Cc: 6lowpan@ietf.org, David Culler Subject: Re: [6lowpan] HC X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Stephen, see below: On Jul 17, 2008, at 5:40 PM, Stephen Dawson-Haggerty wrote: > - support route-over combined with no hop-by-hop reassembly We should clean up the terminology here since the working group seems to have different ideas of what "route-over" is. I admit, that I haven't been that clear myself over the past few months. I'd like us to decouple routing from forwarding in the way that IP has traditionally done. So it's probably more appropriate to say L3 forwarding in this context. Route-over is a term meant to describe IP routing rather than L2 mesh routing. > - support source routing > > As older discussions on the list have gone over, the first is > currently possible by unpacking the IP headers in the first fragment > and caching the routing information for successive fragments. I think > it's probably not necessary to do anything other then declare that the > compressed IP headers must fit into the first fragment, but there > could be other ideas for how to best allow this. Yes. Some are concerned that this adds some state/complexity within the node. I'm not convinced that the added resource requirements are a huge issue. As for fitting into the first fragment, even an uncompressed IPv6 header should fit given the worst case. Unless you have a huge hop-by-hop options header or large (yet-to-be-defined) 6lowpan headers, this shouldn't be much of an issue. > The second belongs in any standard, because it interacts with address > compression: the source route can be used to infer the source and > destination IP address for intra-pan routing. What I would suggest > here is the addition of an LOWPAN_HCNH encoding for source routing. > This also brings up the issue it should be possible to follow this > header (NHSR?) with a NH_UDP encoding block so as to have compressed > source routing as well as UDP headers. Whatever header format is > decided on should also support a record route option in the dispatch > byte. If people agree that this is important, I can write up a > proposal on how to do this. I can say that we've been using such functionality in production deployments for many months now and they are invaluable resources for debugging wireless networks (especially when routing protocols fail) and can be used for simple routing protocols as well (e.g. DSR-like protocols). While they do interact with HC, I did not include them in the first draft simply because it was more important to solve the initial problem of proposing a new HC format. Furthermore, routing type 0 was just deprecated and there is no existing definition for record-route in IPv6. I'm strongly in favor of including this functionality in the draft, but we need to be careful about the processing rules. If the working group things this is useful functionality to include in the doc, I'd be happy to see your ideas and we can compare with mine or others. > What else do people see as needing work in HC? Some of the issues on the plate that I plan to address in the next draft (as discussed in the last WG meeting): - two bits for HLIM to indicate where the packet came from - adding bits to identify the prefix context for supporting multiple prefixes - removing option for checksum compression in UDP - add a new UDP-like transport that relies on end-to-end MIC rather than checksum Chairs, given the urgency of pushing HC through, I'd like to have some time at the WG meeting to talk about updates and issues. Thanks. To answer the original question in this thread: I too am in favor of deprecating HC1 and pushing HC forward as quickly as possible. -- Jonathan Hui > > > Steve > > On Thu, Jul 17, 2008 at 7:54 AM, Geoff Mulligan > wrote: >> I also agree. Now is the right time before we have to carry this >> design >> baggage forward. >> >> As Pascal pointed out - we then need to get HC done sooner. >> >> geoff >> >> On Thu, 2008-07-17 at 10:56 +0200, Anthony Schoofs wrote: >>> I am also in favor of that approach. >>> We have had issues with routing packets from 6lowpan nodes to IP >>> hosts, and we definitively need the HC compression to make things >>> cleaner and optimized. >>> >>> Anthony >>> -- >>> Anthony Schoofs >>> Research Scientist >>> Philips Research >>> High Tech Campus 34 , 5656 AE Eindhoven, The Netherlands >>> Email: anthony.schoofs@philips.com >>> >>> Inactive hide details for Pascal"Pascal Thubert (pthubert)" >>> >>> >>> >>> "Pascal Thubert (pthubert)" >>> >>> >>> Sent by: >>> 6lowpan-bounces@ietf.org >>> >>> 17-07-2008 10:13 >>> >>> >>> To >>> >>> "David Culler" >>> >>> <6lowpan@ietf.org> >>> >>> cc >>> >>> >>> >>> Subject >>> >>> Re: [6lowpan] HC >>> >>> Classification >>> >>> >>> >>> >>> >>> Hi David: >>> >>> I do support that approach. I'd note that it would impose some >>> pressure to release HC rather quickly. >>> Is there a way to get a feedback on existing deployments that use >>> 6LoWPAN HC1? >>> >>> Pascal >>> >>> >>> ______________________________________________________________________ >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> Behalf Of David Culler >>> Sent: mercredi 16 juillet 2008 18:25 >>> To: 6lowpan@ietf.org >>> Subject: [6lowpan] HC >>> >>> It appears that the 6LoWPAN WG is poised to take up serious >>> discussion >>> of HC (http://www3.tools.ietf.org/html/draft-hui-6lowpan-hc-00) >>> and I >>> would like to encourage us to make a bold move forward while the >>> number of "dusty deck 6LoWPAN implementations" are few - eliminate >>> HC1/HC2 in the process. >>> >>> As a bit of background, the original format document defined HC1 for >>> compression of link local IPv6 addresses and HC2 for compression of >>> UDP and ICMP headers. Both were part of a rather awkward encoding. >>> Most other parts of the encoding got cleaned up with the switch to >>> the >>> stacked header format that went to RFC. Aside from its awkwardness, >>> HC1 was never sufficient, because it provided no compression of >>> routable addresses, nor for the most useful multicast addresses - >>> both >>> rather essential to IPv6. HC1g was proposed to provide a similar >>> (somewhat more effective) stateless compression of common >>> addresses of >>> global scope. This meant two similar compression schemes, HC1 for >>> link-local, HC1G for global. Both are implementable with much less >>> than a thousand lines of code. No ambiguity about when to use which. >>> >>> HC provides a much cleaner approach which subsumes both HC1 and >>> HC1g, >>> better supports multicast, and is much more usable with IPv6 stacked >>> headers because the order of the subheaders is respected. (HC2 comes >>> in between the dispatch and the address subheader, rather than as a >>> portion of the transport subheader). >>> >>> The decision to take on HC, clean up the rough edges, and build >>> consensus around it is the easy part. The bolder step that I would >>> like to suggest is that we deprecate HC1 and get it removed soon. >>> >>> It is always easier to maintain backward compatibility than to >>> make a >>> clean break. But, ultimately that is burdening all the many future >>> implementations in order to avoid a burden on the few current >>> implementations. >>> >>> The reason to avoid this burden is not that either is a huge >>> amount of >>> code. Implementing any of these HCs is only several hundred LOC. The >>> issue is testing and interoperability. The interoperability draft >>> sheds some light on this. There are so many different compression >>> forms and since each is an optimization on the uncompressed version, >>> there are many different ways to represent the same thing. All with >>> different sizes and offsets. At least they are all in the same >>> suite. >>> To multiply that with all the combinations of HC1 and HC will be >>> really unpleasant. Moreover, the only thing anyone will ever use >>> after >>> a short while is HC, since it is so much cleaner and more effective. >>> That means all the HC1 mess and all the testing and interoperability >>> investment will be for nothing other than that - just to pass the >>> test. But it will generate latent bugs, increase the footprint, and >>> frustrate interoperabilty. >>> >>> So, as we imagine a future of billions of 6LoWPAN IP devices >>> embedded >>> in important hard to reach places, lets take the step now to >>> simplify >>> their implementation and testing, rather worry too much about >>> saving a >>> few hours of coding for the half dozen existing implementations. If >>> that is not reason enough, those same implementors will save many >>> times that amount in reduced testing and interoperability >>> validation. >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 18 04:50:21 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A6528C0EC; Fri, 18 Jul 2008 04:50:21 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4893328C0F2 for <6lowpan@core3.amsl.com>; Fri, 18 Jul 2008 04:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gt8wwZgCLQpx for <6lowpan@core3.amsl.com>; Fri, 18 Jul 2008 04:50:19 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by core3.amsl.com (Postfix) with ESMTP id 350E128C0E0 for <6lowpan@ietf.org>; Fri, 18 Jul 2008 04:50:19 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so257747wra.17 for <6lowpan@ietf.org>; Fri, 18 Jul 2008 04:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=2/KzIveCOTQ6uKacsQvbzX+RKfl/jds2Pq5EDVqwbps=; b=p4FUta/wsjv5r0w8kAvmRIlGH3Jk6oMNFNKFrVVYLnmbU7EiJMKxVA2gVs/gJQFDwl Lm3aiqeRGKZLPabGBwJbRuDogTzY6M4g0QcUgoxFPi/XhDco3b/e0W4UU8AfsioI2BLF 7+g2W5J1nwRJhnI3ty82AjRwKkCe2gf8H9zxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=mLnDS0QnhiuOOSgqu/hhS1DoOzzzbpWlDLe+1sXuR3bPfkNWuCmCv9yiR5Qmi3jrGd mug1L1bps1uVrKArY6pAJjmKcbNoTK+1Ecm3NWctB7JGfsGN1NvjVR3MzrcxFNzFx9hV aFmbe1GC7DZPfd95fXwWikIOAcjDm9pZ1HfCo= Received: by 10.90.119.20 with SMTP id r20mr2559agc.98.1216381851463; Fri, 18 Jul 2008 04:50:51 -0700 (PDT) Received: by 10.90.88.14 with HTTP; Fri, 18 Jul 2008 04:50:51 -0700 (PDT) Message-ID: Date: Fri, 18 Jul 2008 20:50:51 +0900 From: "Ki-Hyung Kim" To: 6lowpan <6lowpan@ietf.org> MIME-Version: 1.0 Subject: [6lowpan] New Version of commissioning/bootstrapping protocol in 6lowpan is published (draft-daniel-6lowpan-commissioning-02.txt) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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="===============1868189001==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1868189001== Content-Type: multipart/alternative; boundary="----=_Part_50873_1334381.1216381851466" ------=_Part_50873_1334381.1216381851466 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline SGVsbG8sIGxvd3Bhbm5lcnMsCgpBIG5ldyB2ZXJzaW9uIG9mIGNvbW1pc3Npb25pbmcvYm9vdHN0 cmFwcGluZyBwcm90b2NvbCBpbiA2bG93cGFuIGlzCnB1Ymxpc2hlZC4KSXQgY29udGFpbnMgYSBi b290c3RyYXBwaW5nIHByb3RvY29sIGZvciBleGNoYW5naW5nIGJvb3RzdHJhcHBpbmcKaW5mb3Jt YXRpb24gd2l0aCBhIGJvb3RzdHJhcHBpbmcgc2VydmVyLgpQbGVhc2UgdGFrZSBhIGxvb2sgYXQg aXQgYW5kIGdpdmUgdXMgeW91ciBmZWVkYmFjay4KCkFic3RyYWN0CgogICBUaGUgY29tbWlzaW9u aW5nIHByb2Nlc3MgZGVmaW5lcyB0aGUgc3RhcnR1cCBwcm9jZWR1cmUgZXhlY3V0ZWQgYnkKICAg YW55IDZMb1dQQU4gZGV2aWNlLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBzdGFydHVwIHBy b2NlZHVyZSB0aGF0CiAgIHNob3VsZCBiZSBmb2xsb3dlZCBieSBhIDZMb1dQQU4gZGV2aWNlIGlu IGFueSBvcGVuIG9yIHNlY3VyZWQKICAgbmV0d29yay4KCgpodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvaS1kLWFubm91bmNlL2N1cnJlbnQvbXNnMjEzOTcuaHRtbAoKLS0gCktp LUh5dW5nIEtpbSAoseix4sf8LCDQ3dHD+vspCkFzc29jaWF0ZSBQcm9mZXNzb3IsIEFqb3UgVW5p dmVyc2l0eSwgS29yZWEsICBodHRwOi8vd3d3LjZsb3dwYW4ubmV0ClRlbDogKzgyLTMxLTIxOS0y NDMzLCBDZWw6ICs4Mi0xMC00NzYwLTI1NTEK ------=_Part_50873_1334381.1216381851466 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IZWxsbywgbG93cGFubmVycyw8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5BIG5l dyB2ZXJzaW9uIG9mIGNvbW1pc3Npb25pbmcvYm9vdHN0cmFwcGluZyBwcm90b2NvbCBpbiA2bG93 cGFuIGlzIHB1Ymxpc2hlZC48L2Rpdj4KPGRpdj5JdCBjb250YWlucyBhIGJvb3RzdHJhcHBpbmcg cHJvdG9jb2wgZm9yIGV4Y2hhbmdpbmcgYm9vdHN0cmFwcGluZyBpbmZvcm1hdGlvbiB3aXRoIGEg Ym9vdHN0cmFwcGluZyBzZXJ2ZXIuPC9kaXY+CjxkaXY+UGxlYXNlIHRha2UgYSBsb29rIGF0IGl0 IGFuZCBnaXZlIHVzIHlvdXIgZmVlZGJhY2suPC9kaXY+CjxkaXY+PGJyPkFic3RyYWN0PGJyPjxi cj4mbmJzcDsmbmJzcDsgVGhlIGNvbW1pc2lvbmluZyBwcm9jZXNzIGRlZmluZXMgdGhlIHN0YXJ0 dXAgcHJvY2VkdXJlIGV4ZWN1dGVkIGJ5PGJyPiZuYnNwOyZuYnNwOyBhbnkgNkxvV1BBTiBkZXZp Y2UuJm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgc3RhcnR1cCBwcm9jZWR1cmUgdGhh dDxicj4mbmJzcDsmbmJzcDsgc2hvdWxkIGJlIGZvbGxvd2VkIGJ5IGEgNkxvV1BBTiBkZXZpY2Ug aW4gYW55IG9wZW4gb3Igc2VjdXJlZDxicj4KJm5ic3A7Jm5ic3A7IG5ldHdvcmsuPGJyPiZuYnNw OzwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9pLWQtYW5ub3VuY2UvY3VycmVudC9tc2cyMTM5Ny5odG1sIj5o dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaS1kLWFubm91bmNlL2N1cnJlbnQv bXNnMjEzOTcuaHRtbDwvYT4mbmJzcDs8YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj5LaS1IeXVu ZyBLaW0gKLHoseLH/Cwg0N3Rw/r7KTxicj5Bc3NvY2lhdGUgUHJvZmVzc29yLCBBam91IFVuaXZl cnNpdHksIEtvcmVhLCZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuNmxvd3Bhbi5uZXQi Pmh0dHA6Ly93d3cuNmxvd3Bhbi5uZXQ8L2E+IDxicj4KVGVsOiArODItMzEtMjE5LTI0MzMsIENl bDogKzgyLTEwLTQ3NjAtMjU1MSA8L2Rpdj4K ------=_Part_50873_1334381.1216381851466-- --===============1868189001== 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://www.ietf.org/mailman/listinfo/6lowpan --===============1868189001==-- From 6lowpan-bounces@ietf.org Fri Jul 18 04:53:09 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69763A684D; Fri, 18 Jul 2008 04:53:09 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376EF3A684D for <6lowpan@core3.amsl.com>; Fri, 18 Jul 2008 04:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVm887tjg6LT for <6lowpan@core3.amsl.com>; Fri, 18 Jul 2008 04:53:08 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by core3.amsl.com (Postfix) with ESMTP id 3ED093A67FD for <6lowpan@ietf.org>; Fri, 18 Jul 2008 04:53:08 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so258619wra.17 for <6lowpan@ietf.org>; Fri, 18 Jul 2008 04:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=7wfd6yeGaNpwDsb8Qg1g2E3GoMwGjZEyRZ9LD30si0A=; b=XBm5z+4JniS7GflKF+JrUG9x3RwJpLLWQzTl0ifvdUgWSAOOV8bexBgTC6O6cf0ADq kT4Faq0CIB5SJwg8zmsIN/TDTiwFpTlhavNw+rMin5MBHrhWdOa5e2PFtRjXEAkFopd7 bu7eZ+BNT+PdTJ3w5aKnUrB9KM//4GYZa51Os= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=sHDAcLSZhL/YDTGI/cw+NSz85q9yPlKFG6ZrnakbLKaXOx4NikPLM3y/lg+R84FQqr dRkE9+/L56VQYtPSCNNWV9KaDFHNTWzKgfsOWVXMx05vxnC8o8KkD9lEtyPIDAjbRMsl BQbk5YArULwqejUPqIUzok0hlQcpAogCHWhfM= Received: by 10.90.83.18 with SMTP id g18mr10468agb.78.1216382018455; Fri, 18 Jul 2008 04:53:38 -0700 (PDT) Received: by 10.90.88.14 with HTTP; Fri, 18 Jul 2008 04:53:38 -0700 (PDT) Message-ID: Date: Fri, 18 Jul 2008 20:53:38 +0900 From: "Ki-Hyung Kim" To: 6lowpan <6lowpan@ietf.org> MIME-Version: 1.0 Subject: [6lowpan] New version of 6lowpan Management Information Base is published (draft-daniel-lowpan-mib-01.txt) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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="===============1826740834==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1826740834== Content-Type: multipart/alternative; boundary="----=_Part_50915_2568696.1216382018449" ------=_Part_50915_2568696.1216382018449 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline SGVsbG8gbG93cGFubmVycywKClRoZSBmb2xsb3dpbmcgaXMgdGhlIHB1YmxpY2F0aW9uIG5vdGlm aWNhdGlvbiBvZiB0aGUgbmV3IHZlcnNpb24gcmVsZWFzZSBvZgo2bG93cGFuIE1hbmFnZW1lbnQg SW5mb3JtYXRpb24gQmFzZS4KUGxlYXNlIGdpdmUgdXMgeW91ciBmZWVkYmFjay4KCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pLWQtYW5ub3VuY2UvY3VycmVudC9tc2cyMTMy OC5odG1sCgotLSAKS2ktSHl1bmcgS2ltICix6LHix/wsINDd0cP6+ykKQXNzb2NpYXRlIFByb2Zl c3NvciwgQWpvdSBVbml2ZXJzaXR5LCBLb3JlYSwgIGh0dHA6Ly93d3cuNmxvd3Bhbi5uZXQKVGVs OiArODItMzEtMjE5LTI0MzMsIENlbDogKzgyLTEwLTQ3NjAtMjU1MQo= ------=_Part_50915_2568696.1216382018449 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IZWxsbyBsb3dwYW5uZXJzLDwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PlRoZSBm b2xsb3dpbmcgaXMgdGhlIHB1YmxpY2F0aW9uIG5vdGlmaWNhdGlvbiBvZiB0aGUgbmV3IHZlcnNp b24gcmVsZWFzZSBvZiA2bG93cGFuIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZS48L2Rpdj4K PGRpdj5QbGVhc2UgZ2l2ZSB1cyB5b3VyIGZlZWRiYWNrLjwvZGl2Pgo8ZGl2Pjxicj48YSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaS1kLWFubm91bmNlL2N1cnJl bnQvbXNnMjEzMjguaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2kt ZC1hbm5vdW5jZS9jdXJyZW50L21zZzIxMzI4Lmh0bWw8L2E+PGJyIGNsZWFyPSJhbGwiPjxicj4t LSA8YnI+S2ktSHl1bmcgS2ltICix6LHix/wsINDd0cP6+yk8YnI+CkFzc29jaWF0ZSBQcm9mZXNz b3IsIEFqb3UgVW5pdmVyc2l0eSwgS29yZWEsJm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3 dy42bG93cGFuLm5ldCI+aHR0cDovL3d3dy42bG93cGFuLm5ldDwvYT4gPGJyPlRlbDogKzgyLTMx LTIxOS0yNDMzLCBDZWw6ICs4Mi0xMC00NzYwLTI1NTEgPC9kaXY+Cg== ------=_Part_50915_2568696.1216382018449-- --===============1826740834== 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://www.ietf.org/mailman/listinfo/6lowpan --===============1826740834==-- From 6lowpan-bounces@ietf.org Fri Jul 18 06:05:20 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A92A28C108; Fri, 18 Jul 2008 06:05:20 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8936028C108 for <6lowpan@core3.amsl.com>; Fri, 18 Jul 2008 06:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL60lqp0+k8s for <6lowpan@core3.amsl.com>; Fri, 18 Jul 2008 06:05:18 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4AC8328C106 for <6lowpan@ietf.org>; Fri, 18 Jul 2008 06:05:17 -0700 (PDT) Received: from h132172.gprs.dnafinland.fi (h132172.gprs.dnafinland.fi [87.93.132.172]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m6ID5bKr009367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Fri, 18 Jul 2008 16:05:46 +0300 Message-ID: <48809506.4020407@sensinode.com> Date: Fri, 18 Jul 2008 16:05:10 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org I'd like to make a bold proposal. If we now decide to take HC into use, and depreciate HC1 (momentum seems to be there); I would like to go one step further. Let's depreciate the use of the RFC 4944 mesh-header at the same time. draft-hui-6lowpan-hc-00 now allows us to do everything which the mesh-header does, and more. Sending packets to a global IPv6 node using the mesh header now requires both the mesh-header, plus an L3 destination address. Quite inefficient. Plus there is again the issue of implementation, testing, and interop along with a confusing spec where routing src/dst can be carried both in lowpan and IPv6 headers.. This situation is similar to that of HC1 and HC. The mesh-header will slowly depreciate anyways, especially with ROLL activity, and for interop reasons between vendors. Let's depreciate it now and stop the annoying mesh-under vs. route-over confusion. LOWPAN_BC0 would still be used to eliminate duplicates. At Sensinode we are likely the largest production deployers with the mesh-header at this time, and are willing to move to L3 at the same time as HC. How about other implementors using the mesh-header, can you support this motion? Can anyone think of a reason to keep the mesh header? - Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 18 08:23:40 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2123A692B; Fri, 18 Jul 2008 08:23:40 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D52128C17B for <6lowpan@core3.amsl.com>; Fri, 18 Jul 2008 08:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTtw1PnquifW for <6lowpan@core3.amsl.com>; Fri, 18 Jul 2008 08:23:38 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 22CC33A67DB for <6lowpan@ietf.org>; Fri, 18 Jul 2008 08:23:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id C2A56AF87D; Fri, 18 Jul 2008 08:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMsIkQ2093Gx; Fri, 18 Jul 2008 08:24:10 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archedrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id B41F5AF87A; Fri, 18 Jul 2008 08:24:10 -0700 (PDT) Message-Id: <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> From: Jonathan Hui To: Zach Shelby In-Reply-To: <48809506.4020407@sensinode.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 18 Jul 2008 08:24:09 -0700 References: <48809506.4020407@sensinode.com> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Zach, see below: On Jul 18, 2008, at 6:05 AM, Zach Shelby wrote: > I'd like to make a bold proposal. If we now decide to take HC into > use, and depreciate HC1 (momentum seems to be there); I would like > to go one step further. Let's depreciate the use of the RFC 4944 > mesh-header at the same time. Good question. > draft-hui-6lowpan-hc-00 now allows us to do everything which the > mesh-header does, and more. Sending packets to a global IPv6 node > using the mesh header now requires both the mesh-header, plus an L3 > destination address. Quite inefficient. Plus there is again the > issue of implementation, testing, and interop along with a > confusing spec where routing src/dst can be carried both in lowpan > and IPv6 headers.. This situation is similar to that of HC1 and HC. > The mesh-header will slowly depreciate anyways, especially with ROLL > activity, and for interop reasons between vendors. Let's depreciate > it now and stop the annoying mesh-under vs. route-over confusion. I'm all for simplicity - it's quite significant when we're dealing with resource-constrained devices that are hard to debug. Again, I think we should be more explicit about routing vs. forwarding. The mesh header allows L2 forwarding, but there's no reason why you couldn't combine that with L3 routing. Then there's the L3 vs. L2 routing debate and, if it hasn't been obvious already, I'm all for an L3 routing approach. I wouldn't want us to relive the days of LAN emulation in dynamic, multihop networks, especially those that are resource-constrained. > LOWPAN_BC0 would still be used to eliminate duplicates. If you're doing L3 forwarding, you probably want to carry that in an L3 header (we place it in a compressed hop-by-hop option header). In light of some of the earlier discussion with HC, I think it's time to incorporate HBH options into the HC draft. > At Sensinode we are likely the largest production deployers with the > mesh-header at this time, and are willing to move to L3 at the same > time as HC. How about other implementors using the mesh-header, can > you support this motion? Can anyone think of a reason to keep the > mesh header? The only real advantage I see of the mesh header is that it allows you to pick an intermediate destination. But this requires packets to carry both the mesh header and L3 addressing as you pointed out above. A better application of L2 forwarding is to apply MPLS-style forwarding and utilize the traffic-engineering capabilities that it provides, but then we'd want a header that carries a label, not the mesh addressing header that carries a source and destination addresses. I think ISA100 is currently leaning in a direction of using the mesh addressing header, but this might still be in flux. On the other hand, we've had significant experience with L3 forwarding in low- power, lossy networks and must say that it's been working pretty well so far. But others with more experience in L2 forwarding should speak up as well. -- Jonathan Hui > > > - Zach > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 18 09:45:26 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 038C128C1DD; Fri, 18 Jul 2008 09:45:22 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4388528C1DD for <6lowpan@core3.amsl.com>; Fri, 18 Jul 2008 09:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agUt9raA-Twp for <6lowpan@core3.amsl.com>; Fri, 18 Jul 2008 09:45:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 37BEB28C1D2 for <6lowpan@ietf.org>; Fri, 18 Jul 2008 09:45:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,211,1215388800"; d="scan'208";a="14790312" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2008 16:45:42 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6IGjgoF029625; Fri, 18 Jul 2008 18:45:42 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6IGjgV1022364; Fri, 18 Jul 2008 16:45:42 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 18:45:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Jul 2008 18:45:01 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05FC88AF@xmb-ams-337.emea.cisco.com> In-Reply-To: <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Mesh-header, do we need it anymore? Thread-Index: Acjo6lu+FffjO9xVSdGiWtHIx7NCXQACgDWg References: <48809506.4020407@sensinode.com> <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Zach Shelby" X-OriginalArrivalTime: 18 Jul 2008 16:45:42.0180 (UTC) FILETIME=[B768F640:01C8E8F5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2171; t=1216399542; x=1217263542; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Mesh-header,=20do=20we=20ne ed=20it=20anymore? |Sender:=20; bh=slOjweZpkodUYCbCSFIHhpad6RtEIYPvrQ9dphs852g=; b=NynCI3tmqnLFyE7AjltUZK/ti/QMDA2tQpbmx5tYHuGG/MLaXOOMTH2zRf 69eroSL7rwyLjwiIdC4cwBTK8u9ck8Gk9uovLJSiEwO6NPT/PNrTXAdwQSDl rzk8wojaWt; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > >> draft-hui-6lowpan-hc-00 now allows us to do everything which the >> mesh-header does, and more. Sending packets to a global IPv6 node >> using the mesh header now requires both the mesh-header, plus an L3 >> destination address. Quite inefficient. Plus there is again the >> issue of implementation, testing, and interop along with a >> confusing spec where routing src/dst can be carried both in lowpan >> and IPv6 headers.. This situation is similar to that of HC1 and HC. >> The mesh-header will slowly depreciate anyways, especially with ROLL >> activity, and for interop reasons between vendors. Let's depreciate >> it now and stop the annoying mesh-under vs. route-over confusion. > >I'm all for simplicity - it's quite significant when we're dealing >with resource-constrained devices that are hard to debug. Again, I >think we should be more explicit about routing vs. forwarding. The >mesh header allows L2 forwarding, but there's no reason why you >couldn't combine that with L3 routing. Then there's the L3 vs. L2 >routing debate and, if it hasn't been obvious already, I'm all for an >L3 routing approach. I wouldn't want us to relive the days of LAN >emulation in dynamic, multihop networks, especially those that are >resource-constrained. [Pascal] That's how I see it too and this echoes Stephen's question about forwarding compressed packets. A simple way to decide whether to terminate 6LoWPAN or to forward a 6LoWPAN packet still compressed is to have the information in the header. For instance, the routing computes which sink is the best exit point to leave the 6LoWPAN network towards the final destination. That sink should become the place where 6LoWPAN is terminated and fragments are recomposed. The "mesh" header becomes a routing header that forces all the packets to be routed via the sink. Forwarding happens along a graph towards that sink, and 6LoWPAN is not finished until the next hop in the routing header is reached. On the way back, The routing header indicates the last router (FFD) that serves the final destination if that one does not route. Makes sense? _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 18 10:09:15 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA0128C1F6; Fri, 18 Jul 2008 10:09:15 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6439C28C1F8 for <6lowpan@core3.amsl.com>; Fri, 18 Jul 2008 10:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA2XTNcgTKVv for <6lowpan@core3.amsl.com>; Fri, 18 Jul 2008 10:09:13 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id A930E28C1F6 for <6lowpan@ietf.org>; Fri, 18 Jul 2008 10:09:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 832E3AF883; Fri, 18 Jul 2008 10:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbNiCi8X+f2J; Fri, 18 Jul 2008 10:09:47 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archedrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id E68FAAF84A; Fri, 18 Jul 2008 10:09:46 -0700 (PDT) Message-Id: <35AE696E-8F0A-4CFA-A62A-EC1E679B66A6@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05FC88AF@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 18 Jul 2008 10:09:46 -0700 References: <48809506.4020407@sensinode.com> <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05FC88AF@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal: On Jul 18, 2008, at 9:45 AM, Pascal Thubert (pthubert) wrote: >> I'm all for simplicity - it's quite significant when we're dealing >> with resource-constrained devices that are hard to debug. Again, I >> think we should be more explicit about routing vs. forwarding. The >> mesh header allows L2 forwarding, but there's no reason why you >> couldn't combine that with L3 routing. Then there's the L3 vs. L2 >> routing debate and, if it hasn't been obvious already, I'm all for an >> L3 routing approach. I wouldn't want us to relive the days of LAN >> emulation in dynamic, multihop networks, especially those that are >> resource-constrained. > [Pascal] > > That's how I see it too and this echoes Stephen's question about > forwarding compressed packets. Except that Stephen (and Zach) was talking about L3 forwarding, where reassembly must (explicitly or implicitly) happen hop-by-hop. > A simple way to decide whether to terminate 6LoWPAN or to forward a > 6LoWPAN packet still compressed is to have the information in the > header. > > For instance, the routing computes which sink is the best exit point > to leave the 6LoWPAN network towards the final destination. > > That sink should become the place where 6LoWPAN is terminated and > fragments are recomposed. The "mesh" header becomes a routing > header that forces all the packets to be routed via the sink. > > Forwarding happens along a graph towards that sink, and 6LoWPAN is not > finished until the next hop in the routing header is reached. > > On the way back, The routing header indicates the last router (FFD) > that > serves the final destination if that one does not route. > > Makes sense? For L2 forwarding, this is a sensible solution (routing headers are commonly used for these kinds of things). With L3 forwarding, there is no ambiguity of where the reassembly must happen. -- Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Jul 20 15:14:53 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC9D3A67EA; Sun, 20 Jul 2008 15:14:53 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60703A67EA for <6lowpan@core3.amsl.com>; Sun, 20 Jul 2008 15:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAGHjXkwg8vD for <6lowpan@core3.amsl.com>; Sun, 20 Jul 2008 15:14:50 -0700 (PDT) Received: from gateway2.EECS.Berkeley.EDU (gateway2.EECS.Berkeley.EDU [169.229.60.39]) by core3.amsl.com (Postfix) with ESMTP id EBA983A67E6 for <6lowpan@ietf.org>; Sun, 20 Jul 2008 15:14:50 -0700 (PDT) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway2.EECS.Berkeley.EDU (8.14.3/8.13.3) with ESMTP id m6KMFKvh015224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 20 Jul 2008 15:15:28 -0700 (PDT) Message-ID: <4883B9AA.8060102@eecs.berkeley.edu> Date: Sun, 20 Jul 2008 15:18:18 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Zach Shelby References: <48809506.4020407@sensinode.com> In-Reply-To: <48809506.4020407@sensinode.com> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Zach - I agree. Let's do it right, and stick with route over. ksjp Zach Shelby wrote: > I'd like to make a bold proposal. If we now decide to take HC into > use, and depreciate HC1 (momentum seems to be there); I would like to > go one step further. Let's depreciate the use of the RFC 4944 > mesh-header at the same time. > > draft-hui-6lowpan-hc-00 now allows us to do everything which the > mesh-header does, and more. Sending packets to a global IPv6 node > using the mesh header now requires both the mesh-header, plus an L3 > destination address. Quite inefficient. Plus there is again the issue > of implementation, testing, and interop along with a confusing spec > where routing src/dst can be carried both in lowpan and IPv6 headers.. > This situation is similar to that of HC1 and HC. The mesh-header will > slowly depreciate anyways, especially with ROLL activity, and for > interop reasons between vendors. Let's depreciate it now and stop the > annoying mesh-under vs. route-over confusion. > > LOWPAN_BC0 would still be used to eliminate duplicates. > > At Sensinode we are likely the largest production deployers with the > mesh-header at this time, and are willing to move to L3 at the same > time as HC. How about other implementors using the mesh-header, can > you support this motion? Can anyone think of a reason to keep the mesh > header? > > - Zach > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Jul 20 16:29:31 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DCF3A684E; Sun, 20 Jul 2008 16:29:31 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4903A684E for <6lowpan@core3.amsl.com>; Sun, 20 Jul 2008 16:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIk3gRphdVNG for <6lowpan@core3.amsl.com>; Sun, 20 Jul 2008 16:29:30 -0700 (PDT) Received: from nlpi087.prodigy.net (nlpi087.prodigy.net [207.115.36.103]) by core3.amsl.com (Postfix) with ESMTP id E68C93A67CE for <6lowpan@ietf.org>; Sun, 20 Jul 2008 16:29:29 -0700 (PDT) X-ORBL: [71.131.176.119] Received: from [192.168.1.53] (adsl-71-131-176-119.dsl.sntc01.pacbell.net [71.131.176.119]) by nlpi087.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id m6KNU1Yq023936; Sun, 20 Jul 2008 18:30:04 -0500 Message-Id: From: "Pete St. Pierre" To: 6lowpan <6lowpan@ietf.org> In-Reply-To: <4883B9AA.8060102@eecs.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Sun, 20 Jul 2008 16:30:01 -0700 References: <48809506.4020407@sensinode.com> <4883B9AA.8060102@eecs.berkeley.edu> X-Mailer: Apple Mail (2.926) Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > Zach - I agree. Let's do it right, and stick with route over. When we have a solution that is proven to work, that makes sense. In the meantime, let's not deprecate things people are using and may still need, depending on the future successes. I think it make a lot of sense to settle on a single HC model, since there is proven, implemented work. I think abandoning the mesh header in its entirety at this point is premature. ...Pete > > > ksjp > > Zach Shelby wrote: >> I'd like to make a bold proposal. If we now decide to take HC into >> use, and depreciate HC1 (momentum seems to be there); I would like >> to go one step further. Let's depreciate the use of the RFC 4944 >> mesh-header at the same time. >> >> draft-hui-6lowpan-hc-00 now allows us to do everything which the >> mesh-header does, and more. Sending packets to a global IPv6 node >> using the mesh header now requires both the mesh-header, plus an L3 >> destination address. Quite inefficient. Plus there is again the >> issue of implementation, testing, and interop along with a >> confusing spec where routing src/dst can be carried both in lowpan >> and IPv6 headers.. This situation is similar to that of HC1 and HC. >> The mesh-header will slowly depreciate anyways, especially with >> ROLL activity, and for interop reasons between vendors. Let's >> depreciate it now and stop the annoying mesh-under vs. route-over >> confusion. >> >> LOWPAN_BC0 would still be used to eliminate duplicates. >> >> At Sensinode we are likely the largest production deployers with >> the mesh-header at this time, and are willing to move to L3 at the >> same time as HC. How about other implementors using the mesh- >> header, can you support this motion? Can anyone think of a reason >> to keep the mesh header? >> >> - Zach >> > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 21 00:14:54 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A07D3A68C0; Mon, 21 Jul 2008 00:14:54 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196F43A68C0 for <6lowpan@core3.amsl.com>; Mon, 21 Jul 2008 00:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5oNRSg4t4zu for <6lowpan@core3.amsl.com>; Mon, 21 Jul 2008 00:14:51 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 9191B3A68AB for <6lowpan@ietf.org>; Mon, 21 Jul 2008 00:14:50 -0700 (PDT) Received: from h158243.gprs.dnafinland.fi (h158243.gprs.dnafinland.fi [87.93.158.243]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m6L7FMAA027602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Mon, 21 Jul 2008 10:15:24 +0300 Message-ID: <4884376A.6040801@sensinode.com> Date: Mon, 21 Jul 2008 10:14:50 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> References: <48809506.4020407@sensinode.com> <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> In-Reply-To: <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Thanks for the feedback everyone. I'll just summarize here what feedback I've gotten so far. Still waiting or more reasons we need the mesh-header, and feedback from others who have implemented and are using mesh-header forwarding. So far then we have 2 features the mesh-header allows: - Specification of intermediate destination (e.g. a particular BbR), but this comes at the cost of mesh-header + HC dst address for addressing outside the lowpan. Does the current BbR actually require this wrt the primary router? - Fragments are not reassembled at intermediate hops. Are there some down-sides to doing IPv6 routing inside the lowpan? - Fragments must be "reassembled" at each router in the lowpan. Not necessarily a bad thing, could allow for hop-by-hop recovery. - We may have IPv6 ND issues if each node in the lowpan is an IPv6 router. We need to differentiate between lowpan IPv6 routers (LpR?) and BbRs. IPv6 routers inside the lowpan should not e.g. send their own RAs. As far as I understand ISA100 could just as easily use HC to achieve the routing options it has in mind. Geoff, Pascal, is this correct? Pete had a good point about not prematurely depreciating something that works and is in use. However I would still like to hear who is really using it. I have an understanding there is actually quite equal implementation and deployment experience for both IPv6 routing and mesh-header forwarding inside lowpans at this time. I would say both work fine. However we don't have a standard algorithm for mesh forwarding (and are not going to get it), so what happens when ROLL algorithms come into use? For example, our forwarding algorithm could just as easily store the src+dst+hopcount in the IPv6 header using HC as in the mesh-header as now without penalty. In practice in limited nodes lowpan and IPv6 are processed and implemented together, it is really a very small implementation detail whether to look at the mesh-header or HC IPv6 header for the dst address, and then consult your routing table for the next hop. - Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 21 00:33:48 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 950993A6804; Mon, 21 Jul 2008 00:33:48 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53C93A6804 for <6lowpan@core3.amsl.com>; Mon, 21 Jul 2008 00:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnv2blZFSmlI for <6lowpan@core3.amsl.com>; Mon, 21 Jul 2008 00:33:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 41B283A659B for <6lowpan@ietf.org>; Mon, 21 Jul 2008 00:33:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,222,1215388800"; d="scan'208";a="14885427" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Jul 2008 07:34:20 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6L7YKst001057; Mon, 21 Jul 2008 09:34:20 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6L7YK8A004825; Mon, 21 Jul 2008 07:34:20 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 09:34:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 09:33:09 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05FC8A28@xmb-ams-337.emea.cisco.com> In-Reply-To: <35AE696E-8F0A-4CFA-A62A-EC1E679B66A6@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Mesh-header, do we need it anymore? Thread-Index: Acjo+Rn9vY/R0hAsRhikqEvY+5zsQgCBIIyQ References: <48809506.4020407@sensinode.com> <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05FC88AF@xmb-ams-337.emea.cisco.com> <35AE696E-8F0A-4CFA-A62A-EC1E679B66A6@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 21 Jul 2008 07:34:20.0384 (UTC) FILETIME=[305CBE00:01C8EB04] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3855; t=1216625660; x=1217489660; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Mesh-header,=20do=20we=20ne ed=20it=20anymore? |Sender:=20; bh=Vf3j5bSS9ECt+u4eFWaNdusU9X5qjCmjNYiZMGF/YoQ=; b=gnpsH6IOqVJgNdzBR1X+vJXRDE8kqyd35dX0C+oWvPDsENcxf5f5C4uePT T18Y8GSKRO1rhNQ/+EIq1JhTalrRRmPI3WuLTZZ6H6CtFtPEojkw5nI/k3vt hdglYxzBLN; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan: I think it is desirable to be able to route packets in the compressed form. Rassembling 6LoWPAN packets at each hop will slow the traffic down and cause congestion on the intermediate nodes if they are limited in capacity. The 6LoWPAN sublayer is already L3 so we should be able to forward at that sublayer provided that there is a standard that guarantees that both sides match. But that work if it happens should NOT delay / be confused with the chartered work on HC. My vote is to standardize HC as it stands with its current coverage. Other pieces of work, like deprecating 4944, compressed forwarding and congestion handling can happen in parallel with their own schedule though it would be good to figure the broad lines in case they impact HC as it stands (eg ECN in HC). We can note that mesh headers are already and should be defined by the underlaying technology (like 802.11S and ISA do for instance). So I'm all for deprecating the 6LowPAN mesh header and forget about it. But a routing header is still route over even if the expression is compressed so it is our business. We can also note that a loose source routing enables all packet to reach a reassambly point over a routing graph whereas a strict source routing and hop-by-hop fragmentation/recomposition imply a single path for the whole packet. If the group agrees that we should define forwarding in compressed mode then we can consider it in parallel or some future and see where that leads us. If mobile IP plays a role someday, compressing RH2 and some option headers will also be of interest. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: vendredi 18 juillet 2008 19:10 >To: Pascal Thubert (pthubert) >Cc: Zach Shelby; 6lowpan >Subject: Re: [6lowpan] Mesh-header, do we need it anymore? > > >Hi Pascal: > >On Jul 18, 2008, at 9:45 AM, Pascal Thubert (pthubert) wrote: >>> I'm all for simplicity - it's quite significant when we're dealing >>> with resource-constrained devices that are hard to debug. Again, I >>> think we should be more explicit about routing vs. forwarding. The >>> mesh header allows L2 forwarding, but there's no reason why you >>> couldn't combine that with L3 routing. Then there's the L3 vs. L2 >>> routing debate and, if it hasn't been obvious already, I'm all for an >>> L3 routing approach. I wouldn't want us to relive the days of LAN >>> emulation in dynamic, multihop networks, especially those that are >>> resource-constrained. >> [Pascal] >> >> That's how I see it too and this echoes Stephen's question about >> forwarding compressed packets. > >Except that Stephen (and Zach) was talking about L3 forwarding, where >reassembly must (explicitly or implicitly) happen hop-by-hop. > >> A simple way to decide whether to terminate 6LoWPAN or to forward a >> 6LoWPAN packet still compressed is to have the information in the >> header. >> >> For instance, the routing computes which sink is the best exit point >> to leave the 6LoWPAN network towards the final destination. >> >> That sink should become the place where 6LoWPAN is terminated and >> fragments are recomposed. The "mesh" header becomes a routing >> header that forces all the packets to be routed via the sink. >> >> Forwarding happens along a graph towards that sink, and 6LoWPAN is not >> finished until the next hop in the routing header is reached. >> >> On the way back, The routing header indicates the last router (FFD) >> that >> serves the final destination if that one does not route. >> >> Makes sense? > >For L2 forwarding, this is a sensible solution (routing headers are >commonly used for these kinds of things). With L3 forwarding, there is >no ambiguity of where the reassembly must happen. > >-- >Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 21 00:51:59 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F1B3A6838; Mon, 21 Jul 2008 00:51:59 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18CA3A6838 for <6lowpan@core3.amsl.com>; Mon, 21 Jul 2008 00:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKHhfq0SuvTw for <6lowpan@core3.amsl.com>; Mon, 21 Jul 2008 00:51:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1AB783A659B for <6lowpan@ietf.org>; Mon, 21 Jul 2008 00:51:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,222,1215388800"; d="scan'208";a="14887703" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Jul 2008 07:52:34 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6L7qYYK006920; Mon, 21 Jul 2008 09:52:34 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6L7qYbv011103; Mon, 21 Jul 2008 07:52:34 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 09:52:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 09:51:53 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05FC8A4C@xmb-ams-337.emea.cisco.com> In-Reply-To: <4884376A.6040801@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Mesh-header, do we need it anymore? Thread-Index: AcjrAZc1JhbRuxxTSs2ZyQG5PPiW2wAAn5Iw References: <48809506.4020407@sensinode.com><04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> <4884376A.6040801@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 21 Jul 2008 07:52:33.0587 (UTC) FILETIME=[BBF64830:01C8EB06] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3579; t=1216626754; x=1217490754; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Mesh-header,=20do=20we=20ne ed=20it=20anymore? |Sender:=20; bh=zavRXfpd5vlb70Y6Tu74IsxJSB2eUIYwoxb/HEXVFu4=; b=e5RSdE8quCAl2ssealX//YkySA268EIJz69XTX6ywJKET29z2frm9Qb1OC d+5eM89/t3wPyyInmvnLZvGxa+AhOqX3EPBZx0azu4GyOquFMgas3QWNG3bi BsW88oIVQO; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Zach: The way I understand it: ISA100.11a defines its own mesh header at the Data Link (DL) layer. Mesh header not considered to belong to 6LoWPAN in that architecture so we ignore it. Out of my head, ISA can forget about RFC 4944 if 6LoWPAN standardizes fragmentation, HC with ECN and Carsten's proposal to skip unknown headers. Note that ISA needs the current capabilities to compress addresses that are not EUI LLAs, the network hop limit and the transport checksum. ISA would also apreciate other work like asserting the need for fragment recovery and providing a solution if the need is established. Finally, ISA100.11a is open to leave the path computation to a L3 process, though it should probably be offline. For the current release, this is going to be unspecified and left to the implementation of the system manager, but hopefully a solution out of ROLL can be standardized in some future. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby >Sent: lundi 21 juillet 2008 09:15 >To: 6lowpan >Subject: Re: [6lowpan] Mesh-header, do we need it anymore? > >Thanks for the feedback everyone. I'll just summarize here what feedback >I've gotten so far. Still waiting or more reasons we need the >mesh-header, and feedback from others who have implemented and are using >mesh-header forwarding. > >So far then we have 2 features the mesh-header allows: > > - Specification of intermediate destination (e.g. a particular BbR), >but this comes at the cost of mesh-header + HC dst address for >addressing outside the lowpan. Does the current BbR actually require >this wrt the primary router? > > - Fragments are not reassembled at intermediate hops. > >Are there some down-sides to doing IPv6 routing inside the lowpan? > > - Fragments must be "reassembled" at each router in the lowpan. Not >necessarily a bad thing, could allow for hop-by-hop recovery. > > - We may have IPv6 ND issues if each node in the lowpan is an IPv6 >router. We need to differentiate between lowpan IPv6 routers (LpR?) and >BbRs. IPv6 routers inside the lowpan should not e.g. send their own RAs. > >As far as I understand ISA100 could just as easily use HC to achieve the >routing options it has in mind. Geoff, Pascal, is this correct? > >Pete had a good point about not prematurely depreciating something that >works and is in use. However I would still like to hear who is really >using it. I have an understanding there is actually quite equal >implementation and deployment experience for both IPv6 routing and >mesh-header forwarding inside lowpans at this time. I would say both >work fine. However we don't have a standard algorithm for mesh >forwarding (and are not going to get it), so what happens when ROLL >algorithms come into use? > >For example, our forwarding algorithm could just as easily store the >src+dst+hopcount in the IPv6 header using HC as in the mesh-header as >now without penalty. In practice in limited nodes lowpan and IPv6 are >processed and implemented together, it is really a very small >implementation detail whether to look at the mesh-header or HC IPv6 >header for the dst address, and then consult your routing table for the >next hop. > >- Zach > > >-- >Zach Shelby | Head of Research | +358 40 7796297 >Sensinode Ltd. www.sensinode.com >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 21 11:55:26 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2582628C17F; Mon, 21 Jul 2008 11:55:26 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5B528C17F for <6lowpan@core3.amsl.com>; Mon, 21 Jul 2008 11:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp6kRsks+Ls1 for <6lowpan@core3.amsl.com>; Mon, 21 Jul 2008 11:55:23 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 7D9053A69F1 for <6lowpan@ietf.org>; Mon, 21 Jul 2008 11:55:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 2D89EAF89B; Mon, 21 Jul 2008 11:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frOQu6zLVjUh; Mon, 21 Jul 2008 11:56:02 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archedrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 7A897AF867; Mon, 21 Jul 2008 11:56:02 -0700 (PDT) Message-Id: From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05FC8A28@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 21 Jul 2008 11:56:01 -0700 References: <48809506.4020407@sensinode.com> <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05FC88AF@xmb-ams-337.emea.cisco.com> <35AE696E-8F0A-4CFA-A62A-EC1E679B66A6@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05FC8A28@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, On Jul 21, 2008, at 12:33 AM, Pascal Thubert (pthubert) wrote: > I think it is desirable to be able to route packets in the compressed > form. Rassembling 6LoWPAN packets at each hop will slow the traffic > down > and cause congestion on the intermediate nodes if they are limited in > capacity. The 6LoWPAN sublayer is already L3 so we should be able to > forward at that sublayer provided that there is a standard that > guarantees that both sides match. But that work if it happens should > NOT > delay / be confused with the chartered work on HC. I'm not in agreement with the above paragraph. There's nothing about L3 forwarding that prevents you from routing datagrams in the compressed form (we do it today). You can easily pull out the appropriate destination address from the HC-compressed IP header and forward accordingly. L3 forwarding also does not require explicit reassembly at every hop, just that fragments must travel the same path. I'd argue that there are many reasons why you'd want to route all fragments for the same datagram along the same path, the main reason being that it's easier to dynamically adapt L2 along a single path for the short burst of packets. I'm also not in agreement that 6LoWPAN mesh addressing header is an L3 header - it only carries L2 addresses. > My vote is to standardize HC as it stands with its current coverage. > Other pieces of work, like deprecating 4944, compressed forwarding and > congestion handling can happen in parallel with their own schedule > though it would be good to figure the broad lines in case they > impact HC > as it stands (eg ECN in HC). > > We can note that mesh headers are already and should be defined by the > underlaying technology (like 802.11S and ISA do for instance). So I'm > all for deprecating the 6LowPAN mesh header and forget about it. But a > routing header is still route over even if the expression is > compressed > so it is our business. Again, we should be explicit about whether you are talking about L2 vs. L3 forwarding. An IPv6 Routing Header is, of course, L3 forwarding but that requires fragments to follow a single path. If you're talking about MPLS-like forwarding, then that's below L3. -- Jonathan Hui > We can also note that a loose source routing enables all packet to > reach > a reassambly point over a routing graph whereas a strict source > routing > and hop-by-hop fragmentation/recomposition imply a single path for the > whole packet. > > If the group agrees that we should define forwarding in compressed > mode > then we can consider it in parallel or some future and see where that > leads us. If mobile IP plays a role someday, compressing RH2 and some > option headers will also be of interest. > > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: vendredi 18 juillet 2008 19:10 >> To: Pascal Thubert (pthubert) >> Cc: Zach Shelby; 6lowpan >> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? >> >> >> Hi Pascal: >> >> On Jul 18, 2008, at 9:45 AM, Pascal Thubert (pthubert) wrote: >>>> I'm all for simplicity - it's quite significant when we're dealing >>>> with resource-constrained devices that are hard to debug. Again, I >>>> think we should be more explicit about routing vs. forwarding. The >>>> mesh header allows L2 forwarding, but there's no reason why you >>>> couldn't combine that with L3 routing. Then there's the L3 vs. L2 >>>> routing debate and, if it hasn't been obvious already, I'm all for > an >>>> L3 routing approach. I wouldn't want us to relive the days of LAN >>>> emulation in dynamic, multihop networks, especially those that are >>>> resource-constrained. >>> [Pascal] >>> >>> That's how I see it too and this echoes Stephen's question about >>> forwarding compressed packets. >> >> Except that Stephen (and Zach) was talking about L3 forwarding, where >> reassembly must (explicitly or implicitly) happen hop-by-hop. >> >>> A simple way to decide whether to terminate 6LoWPAN or to forward a >>> 6LoWPAN packet still compressed is to have the information in the >>> header. >>> >>> For instance, the routing computes which sink is the best exit point >>> to leave the 6LoWPAN network towards the final destination. >>> >>> That sink should become the place where 6LoWPAN is terminated and >>> fragments are recomposed. The "mesh" header becomes a routing >>> header that forces all the packets to be routed via the sink. >>> >>> Forwarding happens along a graph towards that sink, and 6LoWPAN is > not >>> finished until the next hop in the routing header is reached. >>> >>> On the way back, The routing header indicates the last router (FFD) >>> that >>> serves the final destination if that one does not route. >>> >>> Makes sense? >> >> For L2 forwarding, this is a sensible solution (routing headers are >> commonly used for these kinds of things). With L3 forwarding, there >> is >> no ambiguity of where the reassembly must happen. >> >> -- >> Jonathan Hui > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 21 12:07:20 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100EF3A6AD5; Mon, 21 Jul 2008 12:07:20 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407DB3A6AD5 for <6lowpan@core3.amsl.com>; Mon, 21 Jul 2008 12:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0X+FavXPuezy for <6lowpan@core3.amsl.com>; Mon, 21 Jul 2008 12:07:17 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id DBA203A6AC3 for <6lowpan@ietf.org>; Mon, 21 Jul 2008 12:07:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 873F2AF89A; Mon, 21 Jul 2008 12:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTPqXlH0x7oL; Mon, 21 Jul 2008 12:07:56 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archedrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 7E489AF867; Mon, 21 Jul 2008 12:07:56 -0700 (PDT) Message-Id: <7852187A-C1BB-41CB-93DE-51B25CE088B2@archrock.com> From: Jonathan Hui To: Zach Shelby In-Reply-To: <4884376A.6040801@sensinode.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 21 Jul 2008 12:07:55 -0700 References: <48809506.4020407@sensinode.com> <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> <4884376A.6040801@sensinode.com> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Zach, On Jul 21, 2008, at 12:14 AM, Zach Shelby wrote: > Thanks for the feedback everyone. I'll just summarize here what > feedback I've gotten so far. Still waiting or more reasons we need > the mesh-header, and feedback from others who have implemented and > are using mesh-header forwarding. > > So far then we have 2 features the mesh-header allows: > > - Specification of intermediate destination (e.g. a particular BbR), > but this comes at the cost of mesh-header + HC dst address for > addressing outside the lowpan. Does the current BbR actually require > this wrt the primary router? Agreed. From what I understand, the current BbR draft makes one or multiple PANs appear as a single IPv6 link. As a result, the BbR draft assumes L2 forwarding and because packets transported over the backbone link do not carry the mesh addressing header, they must be reassembled at a single BbR before forwarding over the backbone. > - Fragments are not reassembled at intermediate hops. It's more appropriate to say that all fragments for a given datagram must follow the same path. Complete reassembly does not need to happen at every hop. > Are there some down-sides to doing IPv6 routing inside the lowpan? > > - Fragments must be "reassembled" at each router in the lowpan. Not > necessarily a bad thing, could allow for hop-by-hop recovery. In addition to hop-by-hop recovery, it's also easier to optimize L2 for burst transmissions along a single path. > - We may have IPv6 ND issues if each node in the lowpan is an IPv6 > router. We need to differentiate between lowpan IPv6 routers (LpR?) > and BbRs. IPv6 routers inside the lowpan should not e.g. send their > own RAs. I'm working on an ND draft that addresses this problem, but probably won't get it done in time for the meeting. > As far as I understand ISA100 could just as easily use HC to achieve > the routing options it has in mind. Geoff, Pascal, is this correct? > > Pete had a good point about not prematurely depreciating something > that works and is in use. However I would still like to hear who is > really using it. I have an understanding there is actually quite > equal implementation and deployment experience for both IPv6 routing > and mesh-header forwarding inside lowpans at this time. I would say > both work fine. However we don't have a standard algorithm for mesh > forwarding (and are not going to get it), so what happens when ROLL > algorithms come into use? Right. And from what we've seen so far, others that are defining L2 forwarding mechanisms are circumventing the mesh addressing header by defining their own... > For example, our forwarding algorithm could just as easily store the > src+dst+hopcount in the IPv6 header using HC as in the mesh-header > as now without penalty. In practice in limited nodes lowpan and IPv6 > are processed and implemented together, it is really a very small > implementation detail whether to look at the mesh-header or HC IPv6 > header for the dst address, and then consult your routing table for > the next hop. That's pretty much what we do today. End nodes have to be able to generate/process IPv6 headers anyway. Needing to process the mesh addressing header only adds to the resource requirements. -- Jonathan Hui > > > - Zach > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 21 16:39:05 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138B23A68A6; Mon, 21 Jul 2008 16:39:05 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4F63A68A6 for <6lowpan@core3.amsl.com>; Mon, 21 Jul 2008 16:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wero-ektm5De for <6lowpan@core3.amsl.com>; Mon, 21 Jul 2008 16:39:02 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 3118F3A684D for <6lowpan@ietf.org>; Mon, 21 Jul 2008 16:39:02 -0700 (PDT) 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 m6LNddpq013697; Mon, 21 Jul 2008 17:39:39 -0600 (MDT) From: Geoff Mulligan To: Jonathan Hui In-Reply-To: <7852187A-C1BB-41CB-93DE-51B25CE088B2@archrock.com> References: <48809506.4020407@sensinode.com> <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> <4884376A.6040801@sensinode.com> <7852187A-C1BB-41CB-93DE-51B25CE088B2@archrock.com> Date: Mon, 21 Jul 2008 17:39:33 -0600 Message-Id: <1216683573.6252.8.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org I don't think that we should or need to remove the mesh header. I think that there is a use for it (Sun is using it with sunspots). It would seem that you could use some layer 2 packet to determine forwarding information and then use the mesh header to create a single layer 2.5 link for all the nodes on the pan - I think that this is what sun does. I'm experimenting with passing the routing information inside the ip packet and then still using the mesh header to create single link layer in the pan (I guess this is a hybrid of route over and mesh under - Route Over Mesh). I do not want to see the mesh header deprecated. geoff On Mon, 2008-07-21 at 12:07 -0700, Jonathan Hui wrote: > Hi Zach, > > On Jul 21, 2008, at 12:14 AM, Zach Shelby wrote: > > Thanks for the feedback everyone. I'll just summarize here what > > feedback I've gotten so far. Still waiting or more reasons we need > > the mesh-header, and feedback from others who have implemented and > > are using mesh-header forwarding. > > > > So far then we have 2 features the mesh-header allows: > > > > - Specification of intermediate destination (e.g. a particular BbR), > > but this comes at the cost of mesh-header + HC dst address for > > addressing outside the lowpan. Does the current BbR actually require > > this wrt the primary router? > > Agreed. From what I understand, the current BbR draft makes one or > multiple PANs appear as a single IPv6 link. As a result, the BbR draft > assumes L2 forwarding and because packets transported over the > backbone link do not carry the mesh addressing header, they must be > reassembled at a single BbR before forwarding over the backbone. > > > - Fragments are not reassembled at intermediate hops. > > It's more appropriate to say that all fragments for a given datagram > must follow the same path. Complete reassembly does not need to happen > at every hop. > > > Are there some down-sides to doing IPv6 routing inside the lowpan? > > > > - Fragments must be "reassembled" at each router in the lowpan. Not > > necessarily a bad thing, could allow for hop-by-hop recovery. > > In addition to hop-by-hop recovery, it's also easier to optimize L2 > for burst transmissions along a single path. > > > - We may have IPv6 ND issues if each node in the lowpan is an IPv6 > > router. We need to differentiate between lowpan IPv6 routers (LpR?) > > and BbRs. IPv6 routers inside the lowpan should not e.g. send their > > own RAs. > > I'm working on an ND draft that addresses this problem, but probably > won't get it done in time for the meeting. > > > As far as I understand ISA100 could just as easily use HC to achieve > > the routing options it has in mind. Geoff, Pascal, is this correct? > > > > Pete had a good point about not prematurely depreciating something > > that works and is in use. However I would still like to hear who is > > really using it. I have an understanding there is actually quite > > equal implementation and deployment experience for both IPv6 routing > > and mesh-header forwarding inside lowpans at this time. I would say > > both work fine. However we don't have a standard algorithm for mesh > > forwarding (and are not going to get it), so what happens when ROLL > > algorithms come into use? > > Right. And from what we've seen so far, others that are defining L2 > forwarding mechanisms are circumventing the mesh addressing header by > defining their own... > > > For example, our forwarding algorithm could just as easily store the > > src+dst+hopcount in the IPv6 header using HC as in the mesh-header > > as now without penalty. In practice in limited nodes lowpan and IPv6 > > are processed and implemented together, it is really a very small > > implementation detail whether to look at the mesh-header or HC IPv6 > > header for the dst address, and then consult your routing table for > > the next hop. > > That's pretty much what we do today. End nodes have to be able to > generate/process IPv6 headers anyway. Needing to process the mesh > addressing header only adds to the resource requirements. > > -- > Jonathan Hui > > > > > > > - Zach > > > > > > -- > > Zach Shelby | Head of Research | +358 40 7796297 > > Sensinode Ltd. www.sensinode.com > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 22 00:51:44 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CDFD3A67F4; Tue, 22 Jul 2008 00:51:44 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669ED3A67F4 for <6lowpan@core3.amsl.com>; Tue, 22 Jul 2008 00:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vz7dEaID1cta for <6lowpan@core3.amsl.com>; Tue, 22 Jul 2008 00:51:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A70003A6765 for <6lowpan@ietf.org>; Tue, 22 Jul 2008 00:51:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,230,1215388800"; d="scan'208";a="14998961" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Jul 2008 07:52:18 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6M7qI4b011037; Tue, 22 Jul 2008 09:52:18 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6M7qI52029438; Tue, 22 Jul 2008 07:52:18 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 09:52:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 09:51:37 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05FC8EB3@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Mesh-header, do we need it anymore? Thread-Index: AcjrY34MahP5CQ87QeifkbDxpHVt+gAaDVeg References: <48809506.4020407@sensinode.com> <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05FC88AF@xmb-ams-337.emea.cisco.com> <35AE696E-8F0A-4CFA-A62A-EC1E679B66A6@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05FC8A28@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 22 Jul 2008 07:52:18.0013 (UTC) FILETIME=[DD17A0D0:01C8EBCF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7382; t=1216713138; x=1217577138; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Mesh-header,=20do=20we=20ne ed=20it=20anymore? |Sender:=20; bh=4nWfVvVHqjftxqrUs7/pMqZDw/VjswkThZBFtZR+a/M=; b=oPR4bhqwc414L2ZKBqrwYQG+CMzL2Fl5tiRU1DMY+wVt6UuZfvKAbiT8RT aeWr0DJngpGwwwi2sAP+pUL0xurz59lRg89PSg5n11Vb10ilLqCSxD3+ctSc lFmBxkDJOB; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: lundi 21 juillet 2008 20:56 >To: Pascal Thubert (pthubert) >Cc: Zach Shelby; 6lowpan >Subject: Re: [6lowpan] Mesh-header, do we need it anymore? > > >Hi Pascal, > >On Jul 21, 2008, at 12:33 AM, Pascal Thubert (pthubert) wrote: >> I think it is desirable to be able to route packets in the compressed >> form. Rassembling 6LoWPAN packets at each hop will slow the traffic >> down >> and cause congestion on the intermediate nodes if they are limited in >> capacity. The 6LoWPAN sublayer is already L3 so we should be able to >> forward at that sublayer provided that there is a standard that >> guarantees that both sides match. But that work if it happens should >> NOT >> delay / be confused with the chartered work on HC. > >I'm not in agreement with the above paragraph. There's nothing about >L3 forwarding that prevents you from routing datagrams in the >compressed form (we do it today). You can easily pull out the >appropriate destination address from the HC-compressed IP header and >forward accordingly. L3 forwarding also does not require explicit >reassembly at every hop, just that fragments must travel the same >path. I'd argue that there are many reasons why you'd want to route >all fragments for the same datagram along the same path, the main >reason being that it's easier to dynamically adapt L2 along a single >path for the short burst of packets. I'm also not in agreement that >6LoWPAN mesh addressing header is an L3 header - it only carries L2 >addresses. [Pascal] I agree with this. My main reason for forwarding all fragments over a same path is that if fragments from a same packet are distributed over multiple paths, more packets might be delayed or lost if one single hop experiences trouble. It is better that only some flows get hit and this can be achieved by sticking a flow to a path. This s a general behaviour that we can observe in the routers already. For fragments it's even more important because of the recomposition buffers. But we do not have to dictate that it always happens that way. We have to provide the means that it happens that way when that's the desired behaviour. > >> My vote is to standardize HC as it stands with its current coverage. >> Other pieces of work, like deprecating 4944, compressed forwarding and >> congestion handling can happen in parallel with their own schedule >> though it would be good to figure the broad lines in case they >> impact HC >> as it stands (eg ECN in HC). [Pascal] Please note well the request here for the ECN bits in HC ;) >> >> We can note that mesh headers are already and should be defined by the >> underlaying technology (like 802.11S and ISA do for instance). So I'm >> all for deprecating the 6LowPAN mesh header and forget about it. But a >> routing header is still route over even if the expression is >> compressed >> so it is our business. > >Again, we should be explicit about whether you are talking about L2 >vs. L3 forwarding. An IPv6 Routing Header is, of course, L3 forwarding >but that requires fragments to follow a single path. If you're talking >about MPLS-like forwarding, then that's below L3. > [Pascal] Well, the route that MPLS follows is set up by L3. So a lot of the opposition against mesh under does not stand against the MPLS approach. But that's a discussion for ROLL I guess. What I'm looking for is a new header that acts as an IPv6 routing header and compresses the final destination and eventually some intermediate hops. In one use of the routing header, the destination IP address that would be compressed by HC would be the last router, and when the last router receives the 6LoWPAN packet, it would swap the destination with the address in the header and forward to the final destination. I hope it's clear that I'm in favor of replacing the mesh header that belongs to L2 with a routing header that belongs to L3 with semantics extended from RFC 2460. The routing header can be loose and thus may not force all the intermediate hops. So RH enables but does not require fragments to follow a single path. A record route capability would be useful for source routing though 2460 does not have one. Looks better this way? Pascal >-- >Jonathan Hui > > >> We can also note that a loose source routing enables all packet to >> reach >> a reassambly point over a routing graph whereas a strict source >> routing >> and hop-by-hop fragmentation/recomposition imply a single path for the >> whole packet. >> >> If the group agrees that we should define forwarding in compressed >> mode >> then we can consider it in parallel or some future and see where that >> leads us. If mobile IP plays a role someday, compressing RH2 and some >> option headers will also be of interest. > > >> >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: vendredi 18 juillet 2008 19:10 >>> To: Pascal Thubert (pthubert) >>> Cc: Zach Shelby; 6lowpan >>> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? >>> >>> >>> Hi Pascal: >>> >>> On Jul 18, 2008, at 9:45 AM, Pascal Thubert (pthubert) wrote: >>>>> I'm all for simplicity - it's quite significant when we're dealing >>>>> with resource-constrained devices that are hard to debug. Again, I >>>>> think we should be more explicit about routing vs. forwarding. The >>>>> mesh header allows L2 forwarding, but there's no reason why you >>>>> couldn't combine that with L3 routing. Then there's the L3 vs. L2 >>>>> routing debate and, if it hasn't been obvious already, I'm all for >> an >>>>> L3 routing approach. I wouldn't want us to relive the days of LAN >>>>> emulation in dynamic, multihop networks, especially those that are >>>>> resource-constrained. >>>> [Pascal] >>>> >>>> That's how I see it too and this echoes Stephen's question about >>>> forwarding compressed packets. >>> >>> Except that Stephen (and Zach) was talking about L3 forwarding, where >>> reassembly must (explicitly or implicitly) happen hop-by-hop. >>> >>>> A simple way to decide whether to terminate 6LoWPAN or to forward a >>>> 6LoWPAN packet still compressed is to have the information in the >>>> header. >>>> >>>> For instance, the routing computes which sink is the best exit point >>>> to leave the 6LoWPAN network towards the final destination. >>>> >>>> That sink should become the place where 6LoWPAN is terminated and >>>> fragments are recomposed. The "mesh" header becomes a routing >>>> header that forces all the packets to be routed via the sink. >>>> >>>> Forwarding happens along a graph towards that sink, and 6LoWPAN is >> not >>>> finished until the next hop in the routing header is reached. >>>> >>>> On the way back, The routing header indicates the last router (FFD) >>>> that >>>> serves the final destination if that one does not route. >>>> >>>> Makes sense? >>> >>> For L2 forwarding, this is a sensible solution (routing headers are >>> commonly used for these kinds of things). With L3 forwarding, there >>> is >>> no ambiguity of where the reassembly must happen. >>> >>> -- >>> Jonathan Hui >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 22 01:26:13 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E273A6765; Tue, 22 Jul 2008 01:26:13 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E403A6765 for <6lowpan@core3.amsl.com>; Tue, 22 Jul 2008 01:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueeCYJW8dDMH for <6lowpan@core3.amsl.com>; Tue, 22 Jul 2008 01:26:10 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 7C01D3A63CB for <6lowpan@ietf.org>; Tue, 22 Jul 2008 01:26:08 -0700 (PDT) Received: from h160109.gprs.dnafinland.fi (h160109.gprs.dnafinland.fi [87.93.160.109]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m6M8QV1F008758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 11:26:39 +0300 Message-ID: <488599B2.9020800@sensinode.com> Date: Tue, 22 Jul 2008 11:26:26 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Geoff Mulligan References: <48809506.4020407@sensinode.com> <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> <4884376A.6040801@sensinode.com> <7852187A-C1BB-41CB-93DE-51B25CE088B2@archrock.com> <1216683573.6252.8.camel@dellx1> In-Reply-To: <1216683573.6252.8.camel@dellx1> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi, Needless to say, I see that there may be some uses for the mesh header in particular cases. Of course we need to keep it there for now. Later on (2009 e.g) it should however really be checked if anyone is using it. Maybe in order to clarify the viable use of the mesh header, and to avoid confusion with route over, draft-culler-6lowpan-architecture-00 could describe when and how it should be used in more specifics. Now the draft points out the limitations and realities of mesh header usage quite well. Could it go one step further, and define one viable, useful way to use the mesh header. The only time I see mesh under being useful as we stand, is when the L2 technology already sets up a topology that includes all needed forwarding information and messaging to maintain it. 802.15.4 in beacon mode, with a tree topology, achieves that. Why don't we just limit the scope of mesh under for this case? Then we avoid tons of ambiguity. I think this draft would be the place to at least recommend this usage. The problem I see is that the WG has put too much emphasis on mesh-under in assumptions made in most drafts assuming it will be used most often. Whereas in reality it will likely be the exception, used only in cases like the one mentioned above. For routing between PANs, or without sufficient L2 forwarding information - we should recommend route over and work closely with ROLL to support that paradigm. So I recommend that the architecture draft (and routereq draft) should be more explicit: 1. For complete broadcast domains, nothing needed. 2. For full-featured 802.15.4 beacon-mode networks, in a strict tree topology, forming a single PAN - you can use mesh under to form a single IP link. We should also explain how to do it in sufficient detail (could be done in dokaspar-6lowpan-routereq). ND optimizations should support this setup of mesh under. 3. For anything else (e.g. ad-hoc 802.15.4 networks), we recommend the use of L3 routing. For standardized routing algorithms see ROLL. ND optimizations and future HC improvements (e.g. IPv6 routing header compression suggested by Pascal) should support RO usage. 4. Experimentally you could use mesh-under with other L2 technologies or setups that maintain sufficient forwarding information, or in hybrid-mesh setups (note the dangers in hybrid-mesh from the architecture doc). - Zach Geoff Mulligan wrote: > I don't think that we should or need to remove the mesh header. I think > that there is a use for it (Sun is using it with sunspots). > > It would seem that you could use some layer 2 packet to determine > forwarding information and then use the mesh header to create a single > layer 2.5 link for all the nodes on the pan - I think that this is what > sun does. > > I'm experimenting with passing the routing information inside the ip > packet and then still using the mesh header to create single link layer > in the pan (I guess this is a hybrid of route over and mesh under - > Route Over Mesh). > > I do not want to see the mesh header deprecated. > > geoff > > On Mon, 2008-07-21 at 12:07 -0700, Jonathan Hui wrote: >> Hi Zach, >> >> On Jul 21, 2008, at 12:14 AM, Zach Shelby wrote: >>> Thanks for the feedback everyone. I'll just summarize here what >>> feedback I've gotten so far. Still waiting or more reasons we need >>> the mesh-header, and feedback from others who have implemented and >>> are using mesh-header forwarding. >>> >>> So far then we have 2 features the mesh-header allows: >>> >>> - Specification of intermediate destination (e.g. a particular BbR), >>> but this comes at the cost of mesh-header + HC dst address for >>> addressing outside the lowpan. Does the current BbR actually require >>> this wrt the primary router? >> Agreed. From what I understand, the current BbR draft makes one or >> multiple PANs appear as a single IPv6 link. As a result, the BbR draft >> assumes L2 forwarding and because packets transported over the >> backbone link do not carry the mesh addressing header, they must be >> reassembled at a single BbR before forwarding over the backbone. >> >>> - Fragments are not reassembled at intermediate hops. >> It's more appropriate to say that all fragments for a given datagram >> must follow the same path. Complete reassembly does not need to happen >> at every hop. >> >>> Are there some down-sides to doing IPv6 routing inside the lowpan? >>> >>> - Fragments must be "reassembled" at each router in the lowpan. Not >>> necessarily a bad thing, could allow for hop-by-hop recovery. >> In addition to hop-by-hop recovery, it's also easier to optimize L2 >> for burst transmissions along a single path. >> >>> - We may have IPv6 ND issues if each node in the lowpan is an IPv6 >>> router. We need to differentiate between lowpan IPv6 routers (LpR?) >>> and BbRs. IPv6 routers inside the lowpan should not e.g. send their >>> own RAs. >> I'm working on an ND draft that addresses this problem, but probably >> won't get it done in time for the meeting. >> >>> As far as I understand ISA100 could just as easily use HC to achieve >>> the routing options it has in mind. Geoff, Pascal, is this correct? >>> >>> Pete had a good point about not prematurely depreciating something >>> that works and is in use. However I would still like to hear who is >>> really using it. I have an understanding there is actually quite >>> equal implementation and deployment experience for both IPv6 routing >>> and mesh-header forwarding inside lowpans at this time. I would say >>> both work fine. However we don't have a standard algorithm for mesh >>> forwarding (and are not going to get it), so what happens when ROLL >>> algorithms come into use? >> Right. And from what we've seen so far, others that are defining L2 >> forwarding mechanisms are circumventing the mesh addressing header by >> defining their own... >> >>> For example, our forwarding algorithm could just as easily store the >>> src+dst+hopcount in the IPv6 header using HC as in the mesh-header >>> as now without penalty. In practice in limited nodes lowpan and IPv6 >>> are processed and implemented together, it is really a very small >>> implementation detail whether to look at the mesh-header or HC IPv6 >>> header for the dst address, and then consult your routing table for >>> the next hop. >> That's pretty much what we do today. End nodes have to be able to >> generate/process IPv6 headers anyway. Needing to process the mesh >> addressing header only adds to the resource requirements. >> >> -- >> Jonathan Hui >> >>> >>> - Zach >>> >>> >>> -- >>> Zach Shelby | Head of Research | +358 40 7796297 >>> Sensinode Ltd. www.sensinode.com >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 22 07:17:32 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39053A6913; Tue, 22 Jul 2008 07:17:32 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3ABE3A6913 for <6lowpan@core3.amsl.com>; Tue, 22 Jul 2008 07:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKVoqSfIHQQI for <6lowpan@core3.amsl.com>; Tue, 22 Jul 2008 07:17:30 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 432AE3A685F for <6lowpan@ietf.org>; Tue, 22 Jul 2008 07:17:29 -0700 (PDT) Received: from h16884.gprs.dnafinland.fi (h16884.gprs.dnafinland.fi [87.93.168.84]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m6MEI3TK022721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Tue, 22 Jul 2008 17:18:05 +0300 Message-ID: <4885EC18.7000207@sensinode.com> Date: Tue, 22 Jul 2008 17:18:00 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] BbR draft comments X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Pascal, Here are some comments on backbone-router-01: First, this nicely integrates Erik's 6lowpan-reg-00 concept in a way. The Binding Solicitation message is equivalent to the ND Registration message. Instead of piggybacking on the RA, BbR uses the explicit Binding Confirmation message. However in BbR the process is opposite to that in 6lowpan-reg. I prefer the model used in the BbR draft, where binding maintenance is controlled by hosts. The forced registration to multiple routers at a constant interval seems to be an overkill to me in 6lowpan-reg. I like the optional secondary binding concept, which is controlled by the host. This is a good approach. In Section 5.1, paragraph 3, "optimistic node" should be "optimistic mode". Section 6.1 has a question about the use of RAs, and finding the BbR faster when arriving to a new LoWPAN. I would actually say that listening for RAs, sending an RS, or sending a BS to 6LOWPAN_BBR are the only L2 independent ways. In case you have a LoWPAN running in ad-hoc mode then this is the only way. Of course if joining a beacon-mode network tells you who the PAN-coordinator (and thus the BbR) is quickly at L2, then it doesn't hurt to use that info. If I understand right, BbR also allows for the use of stateful compression from bormann-6lowpan-cbhc-00? Reading the draft carefully, I don't see anything preventing the use of mesh under or route over. The only issue is that you must (should?) route all traffic through your primary BbR, thus when using route over you should indicate the primary BbR as an intermediate hop. Or can you send traffic outside the lowpan through a secondary BbR at will? In 6.5 it states that as long as a binding entry exists for the source address, then forwarding can occur. This requirement should be explained in the draft better. In my opinion the BbR proposal solves lots of open problems and questions in chakrabarti-6lowpan-ipv6-nd-05, while almost completely avoiding the use of multicast and efficiently using the IPv6 router to offload ND operations. Very useful in practical networks. The timeline for ND optimization submission is in Nov, it would be ideal to eventually merge the BbR draft into the ND optimization draft? - Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 22 07:18:34 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D81B28B56A; Tue, 22 Jul 2008 07:18:34 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5328C28B56A for <6lowpan@core3.amsl.com>; Tue, 22 Jul 2008 07:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjqzHx1NOUps for <6lowpan@core3.amsl.com>; Tue, 22 Jul 2008 07:18:32 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id 18E523A69C8 for <6lowpan@ietf.org>; Tue, 22 Jul 2008 07:18:31 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1273354tib.25 for <6lowpan@ietf.org>; Tue, 22 Jul 2008 07:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=XbMVtiJsG/lxlALxDt9cWv4aO6pO3wqN76AqpuY/9gQ=; b=vo3QgKUZRqn9U67cXMap/V7wIg2K1z8StO805uHnWe0571fUtNuW+88KPniTetZYVG 4noccYn2RKjOjY8fSAgFp2bXqjaqSBf1YtUtD8trJ09SqHHQH+EV0I1ZLUsCjnro8l8d xn8Nzz5cC4PowMxBc/IFkPTQHBe1hxSzdhHQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=C8QkGpf4C4JHuN6aZiiP44ZVZqsZwuDj2UGXq0h9q7QV7YEm5tMbf7EW7U+hMWzROm tKXwMKeyyhLiOhOpNiQBWz2W7HCJH6px9ZPM7cX8sYaHcEHeHYZJoZdgZ9cSbyEYdYQc T6vDZvmBJxEoSiGV/4kSsc+MjqFirnniI4rfU= Received: by 10.110.20.17 with SMTP id 17mr4624383tit.12.1216736352239; Tue, 22 Jul 2008 07:19:12 -0700 (PDT) Received: by 10.110.21.5 with HTTP; Tue, 22 Jul 2008 07:19:12 -0700 (PDT) Message-ID: <77f1dba80807220719t138333d4m95e702357d71321c@mail.gmail.com> Date: Tue, 22 Jul 2008 23:19:12 +0900 From: "Eunsook \"Eunah\" Kim" To: "Geoff Mulligan" In-Reply-To: <1216683573.6252.8.camel@dellx1> MIME-Version: 1.0 Content-Disposition: inline References: <48809506.4020407@sensinode.com> <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> <4884376A.6040801@sensinode.com> <7852187A-C1BB-41CB-93DE-51B25CE088B2@archrock.com> <1216683573.6252.8.camel@dellx1> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Dear all, On Tue, Jul 22, 2008 at 8:39 AM, Geoff Mulligan wrote: > I don't think that we should or need to remove the mesh header. I think > that there is a use for it (Sun is using it with sunspots). > I don't know industries or other commercial fields, but Korea has been building up some 6LoWPAN testbeds, and as I know the biggest testbed in Jeju island use a comercial product which use the mesh header. > It would seem that you could use some layer 2 packet to determine > forwarding information and then use the mesh header to create a single > layer 2.5 link for all the nodes on the pan - I think that this is what > sun does. > > I'm experimenting with passing the routing information inside the ip > packet and then still using the mesh header to create single link layer > in the pan (I guess this is a hybrid of route over and mesh under - > Route Over Mesh). This hybrid way is what exactly some Korean 6LoWPAN testbeds are using. > > I do not want to see the mesh header deprecated. > > geoff > In my opinion, it's a bit early to say deprecation of mesh header as it's in use. -eunah _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 22 21:28:45 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CF803A69A7; Tue, 22 Jul 2008 21:28:45 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF463A69A7 for <6lowpan@core3.amsl.com>; Tue, 22 Jul 2008 21:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPmwsH+i+jbS for <6lowpan@core3.amsl.com>; Tue, 22 Jul 2008 21:28:44 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 109F13A6822 for <6lowpan@ietf.org>; Tue, 22 Jul 2008 21:28:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 71F52AF89A; Tue, 22 Jul 2008 21:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pns9iEKLKTuf; Tue, 22 Jul 2008 21:29:26 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-88-226.dsl.pltn13.pacbell.net [71.142.88.226]) by mail.sf.archrock.com (Postfix) with ESMTP id A57E9AF81E; Tue, 22 Jul 2008 21:29:25 -0700 (PDT) Message-Id: <9B9DCA62-C946-4D74-8557-F714407A1F8C@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05FC8EB3@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 22 Jul 2008 21:29:24 -0700 References: <48809506.4020407@sensinode.com> <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05FC88AF@xmb-ams-337.emea.cisco.com> <35AE696E-8F0A-4CFA-A62A-EC1E679B66A6@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05FC8A28@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05FC8EB3@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Jul 22, 2008, at 12:51 AM, Pascal Thubert (pthubert) wrote: > [Pascal] I agree with this. My main reason for forwarding all > fragments > over a same path is that if fragments from a same packet are > distributed > over multiple paths, more packets might be delayed or lost if one > single > hop experiences trouble. > > It is better that only some flows get hit and this can be achieved by > sticking a flow to a path. This s a general behaviour that we can > observe in the routers already. For fragments it's even more important > because of the recomposition buffers. > > But we do not have to dictate that it always happens that way. We have > to > provide the means that it happens that way when that's the desired > behaviour. Okay. I misunderstood what you meant by forwarding in "compressed form." You actually meant to inspect the compressed header rather than keeping it opaque and relying on lower-layer headers. I agree on your other statements as well. > [Pascal] Please note well the request here for the ECN bits in HC ;) Noted :-) > [Pascal] Well, the route that MPLS follows is set up by L3. > So a lot of the opposition against mesh under does not stand > against the MPLS approach. But that's a discussion for ROLL I guess. Understood, but MPLS is still a lower-layer forwarding service that is capable of treating each fragment for the same datagram differently. I'm not convinced of its advantages in the sensornet space, but it is something to think about. > What I'm looking for is a new header that acts as an IPv6 routing > header and compresses the final destination and eventually some > intermediate hops. > > In one use of the routing header, the destination IP address > that would be compressed by HC would be the last router, > and when the last router receives the 6LoWPAN packet, it > would swap the destination with the address in the header > and forward to the final destination. > > I hope it's clear that I'm in favor of replacing the mesh header > that belongs to L2 with a routing header that belongs to L3 with > semantics extended from RFC 2460. It's clear now :-) > The routing header can be loose and thus may not force all the > intermediate hops. So RH enables but does not require > fragments to follow a single path. > > A record route capability would be useful for source routing > though 2460 does not have one. > > Looks better this way? Yup. I'm in complete agreement here. -- Jonathan Hui > > > Pascal > > >> -- >> Jonathan Hui >> >> >>> We can also note that a loose source routing enables all packet to >>> reach >>> a reassambly point over a routing graph whereas a strict source >>> routing >>> and hop-by-hop fragmentation/recomposition imply a single path for > the >>> whole packet. >>> >>> If the group agrees that we should define forwarding in compressed >>> mode >>> then we can consider it in parallel or some future and see where >>> that >>> leads us. If mobile IP plays a role someday, compressing RH2 and >>> some >>> option headers will also be of interest. >> >> >>> >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: vendredi 18 juillet 2008 19:10 >>>> To: Pascal Thubert (pthubert) >>>> Cc: Zach Shelby; 6lowpan >>>> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? >>>> >>>> >>>> Hi Pascal: >>>> >>>> On Jul 18, 2008, at 9:45 AM, Pascal Thubert (pthubert) wrote: >>>>>> I'm all for simplicity - it's quite significant when we're >>>>>> dealing >>>>>> with resource-constrained devices that are hard to debug. >>>>>> Again, I >>>>>> think we should be more explicit about routing vs. forwarding. >>>>>> The >>>>>> mesh header allows L2 forwarding, but there's no reason why you >>>>>> couldn't combine that with L3 routing. Then there's the L3 vs. L2 >>>>>> routing debate and, if it hasn't been obvious already, I'm all >>>>>> for >>> an >>>>>> L3 routing approach. I wouldn't want us to relive the days of LAN >>>>>> emulation in dynamic, multihop networks, especially those that >>>>>> are >>>>>> resource-constrained. >>>>> [Pascal] >>>>> >>>>> That's how I see it too and this echoes Stephen's question about >>>>> forwarding compressed packets. >>>> >>>> Except that Stephen (and Zach) was talking about L3 forwarding, > where >>>> reassembly must (explicitly or implicitly) happen hop-by-hop. >>>> >>>>> A simple way to decide whether to terminate 6LoWPAN or to >>>>> forward a >>>>> 6LoWPAN packet still compressed is to have the information in the >>>>> header. >>>>> >>>>> For instance, the routing computes which sink is the best exit > point >>>>> to leave the 6LoWPAN network towards the final destination. >>>>> >>>>> That sink should become the place where 6LoWPAN is terminated and >>>>> fragments are recomposed. The "mesh" header becomes a routing >>>>> header that forces all the packets to be routed via the sink. >>>>> >>>>> Forwarding happens along a graph towards that sink, and 6LoWPAN is >>> not >>>>> finished until the next hop in the routing header is reached. >>>>> >>>>> On the way back, The routing header indicates the last router >>>>> (FFD) >>>>> that >>>>> serves the final destination if that one does not route. >>>>> >>>>> Makes sense? >>>> >>>> For L2 forwarding, this is a sensible solution (routing headers are >>>> commonly used for these kinds of things). With L3 forwarding, there >>>> is >>>> no ambiguity of where the reassembly must happen. >>>> >>>> -- >>>> Jonathan Hui >>> > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 22 21:33:25 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2BA43A6873; Tue, 22 Jul 2008 21:33:25 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41423A6873 for <6lowpan@core3.amsl.com>; Tue, 22 Jul 2008 21:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAt08vHq8usB for <6lowpan@core3.amsl.com>; Tue, 22 Jul 2008 21:33:23 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id C0AB63A67EE for <6lowpan@ietf.org>; Tue, 22 Jul 2008 21:33:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 2EDAEAF89A; Tue, 22 Jul 2008 21:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZPmmXvRV3MY; Tue, 22 Jul 2008 21:34:05 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-88-226.dsl.pltn13.pacbell.net [71.142.88.226]) by mail.sf.archrock.com (Postfix) with ESMTP id 855F6AF81E; Tue, 22 Jul 2008 21:34:05 -0700 (PDT) Message-Id: <4FB2B78F-458A-45FC-A438-9E24196116E3@archrock.com> From: Jonathan Hui To: Jonathan Hui In-Reply-To: <9B9DCA62-C946-4D74-8557-F714407A1F8C@archrock.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 22 Jul 2008 21:34:04 -0700 References: <48809506.4020407@sensinode.com> <04CB8852-E35C-4619-9ECE-7C9A6CB602FA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05FC88AF@xmb-ams-337.emea.cisco.com> <35AE696E-8F0A-4CFA-A62A-EC1E679B66A6@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05FC8A28@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05FC8EB3@xmb-ams-337.emea.cisco.com> <9B9DCA62-C946-4D74-8557-F714407A1F8C@archrock.com> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-header, do we need it anymore? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Jul 22, 2008, at 9:29 PM, Jonathan Hui wrote: >> The routing header can be loose and thus may not force all the >> intermediate hops. So RH enables but does not require >> fragments to follow a single path. >> >> A record route capability would be useful for source routing >> though 2460 does not have one. BTW, in case you didn't catch it in one of my previous emails, we do use both RH and RR mechanisms in our networks today, in compressed form of course, and they do work well for us. -- Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Jul 26 15:29:45 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58FF3A6A58; Sat, 26 Jul 2008 15:29:45 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475BE3A6A58 for <6lowpan@core3.amsl.com>; Sat, 26 Jul 2008 15:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW66Cf37BDiT for <6lowpan@core3.amsl.com>; Sat, 26 Jul 2008 15:29:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 6642D3A6946 for <6lowpan@ietf.org>; Sat, 26 Jul 2008 15:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m6QMTWC0016165; Sun, 27 Jul 2008 00:29:37 +0200 (CEST) Message-Id: From: Carsten Bormann To: Carsten Bormann In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Sun, 27 Jul 2008 00:29:31 +0200 References: <5C489A30-AA4D-4626-939A-1BCD1D9C1539@tzi.org> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Call for agenda items for Dublin meeting X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org A revised agenda is at: http://www.ietf.org/proceedings/08jul/agenda/6lowpan.txt Note that, as expected, we are bursting at the seams (we are already overtime); I still decided we should accommodate two Monday drafts from Jonathan because they seem very pertinent to the WG's work items. If I have missed anyone, please tell. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 28 03:06:55 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78203A68DD; Mon, 28 Jul 2008 03:06:55 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3DA3A68DD for <6lowpan@core3.amsl.com>; Mon, 28 Jul 2008 03:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1j8ach87UQl for <6lowpan@core3.amsl.com>; Mon, 28 Jul 2008 03:06:49 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 9278D3A67B1 for <6lowpan@ietf.org>; Mon, 28 Jul 2008 03:06:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 16C93AF869 for <6lowpan@ietf.org>; Mon, 28 Jul 2008 03:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pObtEGazzuh for <6lowpan@ietf.org>; Mon, 28 Jul 2008 03:06:58 -0700 (PDT) Received: from [172.17.6.176] (guestroom-nat.meeting.ietf.org [130.129.64.64]) by mail.sf.archrock.com (Postfix) with ESMTP id 09259AF85D for <6lowpan@ietf.org>; Mon, 28 Jul 2008 03:06:57 -0700 (PDT) Message-Id: <1C237630-D7D8-4FF7-B60D-D952C1676382@archrock.com> From: Jonathan Hui To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 28 Jul 2008 03:06:54 -0700 References: <20080728091537.DCA4A3A6989@core3.amsl.com> X-Mailer: Apple Mail (2.926) Subject: [6lowpan] Fwd: New Version Notification for draft-hui-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Summary of changes: - Added context identifiers to support multiple prefixes for compression. Similar to Carsten's I-D, but allows a single context to be used across different address compression modes. - UDP compression no longer provides option for eliding UDP checksum. - ISA100_UDP compression defined which does allow elision of UDP checksum. - Used an available bit to split Traffic Class from Flow Label compression. - Added some more words around multicast address compression, saying that a node MUST subscribe to both compressed and uncompressed forms and MUST NOT subscribe to only one. This rule means that nodes cannot subscribe to well-known addresses that are not well-known to 6lowpan. Feedback/suggestions welcome. Thanks. -- Jonathan Hui Begin forwarded message: > From: IETF I-D Submission Tool > Date: July 28, 2008 2:15:37 AM PDT > To: jhui@archrock.com > Subject: New Version Notification for draft-hui-6lowpan-hc-01 > > > A new version of I-D, draft-hui-6lowpan-hc-01.txt has been > successfuly submitted by Jonathan Hui and posted to the IETF > repository. > > Filename: draft-hui-6lowpan-hc > Revision: 01 > Title: Compression Format for IPv6 Datagrams in 6LoWPAN Networks > Creation_date: 2008-07-28 > WG ID: Independent Submission > Number_of_pages: 14 > > Abstract: > This document specifies an IPv6 header compression format for IPv6 > packet delivery in 6LoWPAN networks. The compression format relies > on shared context to allow compression of arbitrary prefixes. This > document specifies compression of well-known multicast addresses and > a framework for compressing next headers. UDP compression is > specified within this framework. > > > > The IETF Secretariat. > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 28 03:07:16 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017323A69C8; Mon, 28 Jul 2008 03:07:16 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8995B3A67B1 for <6lowpan@core3.amsl.com>; Mon, 28 Jul 2008 03:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWNTb4VEb-Ej for <6lowpan@core3.amsl.com>; Mon, 28 Jul 2008 03:07:13 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id CC3793A69C8 for <6lowpan@ietf.org>; Mon, 28 Jul 2008 03:07:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 697A6AF869 for <6lowpan@ietf.org>; Mon, 28 Jul 2008 03:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAb-KU22YGIR for <6lowpan@ietf.org>; Mon, 28 Jul 2008 03:07:23 -0700 (PDT) Received: from [172.17.6.176] (guestroom-nat.meeting.ietf.org [130.129.64.64]) by mail.sf.archrock.com (Postfix) with ESMTP id 7C825AF85D for <6lowpan@ietf.org>; Mon, 28 Jul 2008 03:07:22 -0700 (PDT) Message-Id: <1344176C-F7DF-44C9-98C6-B43EAC328A87@archrock.com> From: Jonathan Hui To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 28 Jul 2008 03:07:23 -0700 References: <20080728091548.531053A68D0@core3.amsl.com> X-Mailer: Apple Mail (2.926) Subject: [6lowpan] Fwd: New Version Notification for draft-hui-6lowpan-nd-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Feedback/suggestions welcome. Thanks. -- Jonathan Hui Begin forwarded message: > From: IETF I-D Submission Tool > Date: July 28, 2008 2:15:48 AM PDT > To: jhui@archrock.com > Subject: New Version Notification for draft-hui-6lowpan-nd-00 > > > A new version of I-D, draft-hui-6lowpan-nd-00.txt has been > successfuly submitted by Jonathan Hui and posted to the IETF > repository. > > Filename: draft-hui-6lowpan-nd > Revision: 00 > Title: Neighbor Discovery and Autoconfiguration for Route-Over > 6LoWPAN Networks > Creation_date: 2008-07-28 > WG ID: Independent Submission > Number_of_pages: 24 > > Abstract: > This document specifies a simple version of IPv6 Neighbor Discovery > for route-over 6LoWPAN networks. 6LoWPAN ND allows nodes to discover > routers, discover network configuration parameters, and IPv6 prefixes > for use with stateless address autoconfiguration and context-based > 6LoWPAN compression for IPv6 headers. This document also specifies > autoconfiguration mechanism for use in 6LoWPAN networks. > > > > The IETF Secretariat. > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 28 04:37:03 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D173A6880; Mon, 28 Jul 2008 04:37:03 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31C03A67DB; Mon, 28 Jul 2008 04:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtfhRDVJ4pDn; Mon, 28 Jul 2008 04:37:00 -0700 (PDT) Received: from gw-eur4.philips.com (gw-eur4.philips.com [161.85.125.10]) by core3.amsl.com (Postfix) with ESMTP id 331F43A683C; Mon, 28 Jul 2008 04:37:00 -0700 (PDT) Received: from smtpscan-eur7.philips.com (smtpscan-eur7.mail.philips.com [130.144.57.172]) by gw-eur4.philips.com (Postfix) with ESMTP id BAC951A35; Mon, 28 Jul 2008 11:35:53 +0000 (GMT) Received: from smtpscan-eur7.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 10F6BD05; Mon, 28 Jul 2008 11:37:04 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur7.philips.com (Postfix) with ESMTP id E21558CD; Mon, 28 Jul 2008 11:37:03 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id BC048A7; Mon, 28 Jul 2008 11:37:03 +0000 (GMT) In-Reply-To: <1344176C-F7DF-44C9-98C6-B43EAC328A87@archrock.com> To: Jonathan Hui X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Anthony Schoofs Date: Mon, 28 Jul 2008 13:39:39 +0200 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.6FP2HF30 | November 25, 2007) at 28/07/2008 13:39:42 MIME-Version: 1.0 Cc: 6lowpan-bounces@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-hui-6lowpan-nd-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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="===============1518067650==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1518067650== Content-type: multipart/related; Boundary="0__=4EBBFE07DFAD4AC68f9e8a93df938690918c4EBBFE07DFAD4AC6" --0__=4EBBFE07DFAD4AC68f9e8a93df938690918c4EBBFE07DFAD4AC6 Content-type: multipart/alternative; Boundary="1__=4EBBFE07DFAD4AC68f9e8a93df938690918c4EBBFE07DFAD4AC6" --1__=4EBBFE07DFAD4AC68f9e8a93df938690918c4EBBFE07DFAD4AC6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Hi Jonathan, I just had a quick look at your draft about Neighbor Discovery and Autoconfiguration for Route-Over 6LoWPAN Networks. It seems very good! - A general question: as you recall it, either the IEEE EUI-64 or short= address combined with the PAN ID may be used to generate an IID, as specified in [RFC4944]. Later you mention that appropriate link-layer address can be regener= ated from the IID. When a node from network A receives a packet from network B, how does= it know whether the source node has used the short adress or the EUI-64 address to form the IID? I understand that you can use the U/L bit to separate EUI-64 from short addressing usage, but will destination nodes= always have to check this U/L bit when receiving packets? - About the Router Advertisements, we need to make sure that they are received by all the nodes. With respect to sensor networks constraints,= nodes may not always be able to be awake when they are multicasted. Do = you leave this issue to be solved by other means (global network time synch= ro, local buffering of RAs for transmission when nodes are awake,..)? - It is mentionned that the RAs transmission period must use the trickl= e algorithm. I am not familiar with it, but it seems to me that it is not= appropriate for networks with mobile nodes. I am looking at networks wh= ere nodes can move anytime, and we would go for short RAs periods. Is mobil= ity out of your document scope? - Finally, you wrote that all 6LoWPAN nodes MUST accept the newest pref= ix information. Is this a requirement? Again, I am interested in mobile no= des and we may want to use other metrics for choosing the prefix informatio= n. Thanks! Best regards, Anthony -- Anthony Schoofs Research Scientist Philips Research High Tech Campus 34 , 5656 AE Eindhoven, The Netherlands Email: anthony.schoofs@philips.com = = = = To 6lowpan <6lowpan@ietf.org> = = cc Jonathan Hui = Subj= ect [6lowpan] Fwd: New Version = Sent by: Notification for = 6lowpan-bounces@ietf draft-hui-6lowpan-nd-00 = .org Classificat= ion = 28-07-2008 12:07 = = = = = = Feedback/suggestions welcome. Thanks. -- Jonathan Hui Begin forwarded message: > From: IETF I-D Submission Tool > Date: July 28, 2008 2:15:48 AM PDT > To: jhui@archrock.com > Subject: New Version Notification for draft-hui-6lowpan-nd-00 > > > A new version of I-D, draft-hui-6lowpan-nd-00.txt has been > successfuly submitted by Jonathan Hui and posted to the IETF > repository. > > Filename: draft-hui-6lowpan-nd > Revision: 00 > Title: Neighbor Discovery and Autoconfiguratio= n for Route-Over > 6LoWPAN Networks > Creation_date: 2008-07-28 > WG ID: Independent Submission > Number_of_pages: 24 > > Abstract: > This document specifies a simple version of IPv6 Neighbor Discovery > for route-over 6LoWPAN networks. 6LoWPAN ND allows nodes to discover > routers, discover network configuration parameters, and IPv6 prefixes= > for use with stateless address autoconfiguration and context-based > 6LoWPAN compression for IPv6 headers. This document also specifies > autoconfiguration mechanism for use in 6LoWPAN networks. > > > > The IETF Secretariat. > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan = --1__=4EBBFE07DFAD4AC68f9e8a93df938690918c4EBBFE07DFAD4AC6 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi Jonathan,
I just had a quick look at your draft about Neighbor Discovery and Auto= configuration for Route-Over 6LoWPAN Networks. It seems very good!

- A general question: as you recall it, either the IEEE EUI-64 or short= address combined with the PAN ID may be used to generate an IID, as sp= ecified in [RFC4944].
Later you mention that appropriate link-layer address can be regener= ated from the IID.
When a node from network A receives a packet from network B, how does= it know whether the source node has used the short adress or the EUI-6= 4 address to form the IID? I understand that you can use the U/L bit to= separate EUI-64 from short addressing usage, but will destination node= s always have to check this U/L bit when receiving packets?

- About the Router Advertisements, we need to make sure that they are = received by all the nodes. With respect to sensor networks constraints,= nodes may not always be able to be awake when they are multicasted. Do= you leave this issue to be solved by other means (global network time = synchro, local buffering of RAs for transmission when nodes are awake,.= .)?

- It is mentionned that the RAs transmission period must use the trickl= e algorithm. I am not familiar with it, but it seems to me that it is n= ot appropriate for networks with mobile nodes. I am looking at networks= where nodes can move anytime, and we would go for short RAs periods. I= s mobility out of your document scope?

- Finally, you wrote that all 6LoWPAN nodes MUST accept the newest pref= ix information. Is this a requirement? Again, I am interested in mobile= nodes and we may want to use other metrics for choosing the prefix inf= ormation.

Thanks!
Best regards,
Anthony

--
Anthony Schoofs
Research Scientist
Philips Research
High Tech Campus 34 , 5656 AE Eindhoven, The Netherlands
Email: anthony.schoofs@philips.com

3D"InactiveJonathan Hui <jhui@archrock.com>


=
    Jonathan Hui <jhui@archrock.com>

    Sent by:
    6lowpan-bounces@ietf.org

    28-07-2008 12:07

 = <= td width=3D"100%" valign=3D"middle">=3D""

To
3D""
6lowpan <6lowpan@ietf.org>

cc
3D""

Subject
3D""
[6lowpan] Fwd: New Version Notification for draft-hui-= 6lowpan-nd-00
3D""
Classification
=3D""3D""<= /td>


Feedback/suggestions welcome.

Thanks.

--
Jonathan Hui



Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission@ietf.org>
> Date: July 28, 2008 2:15:48 AM PDT
> To: jhui@archrock.com
> Subject: New Version Notification for draft-hui-6lowpan-nd-00
>
>
> A new version of I-D, draft-hui-6lowpan-nd-00.txt has been  <= br> > successfuly submitted by Jonathan Hui and posted to the IETF  = ;
> repository.
>
> Filename:  draft-hui-6lowpan-nd
> Revision:  00
> Title:  Neighbor Discovery and Autoconfiguration for Rou= te-Over  
> 6LoWPAN Networks
> Creation_date:  2008-07-28
> WG ID:  Independent Submission
> Number_of_pages: 24
>
> Abstract:
> This document specifies a simple version of IPv6 Neighbor Discover= y
> for route-over 6LoWPAN networks. 6LoWPAN ND allows nodes to discov= er
> routers, discover network configuration parameters, and IPv6 prefi= xes
> for use with stateless address autoconfiguration and context-based=
> 6LoWPAN compression for IPv6 headers.  This document also spe= cifies
> autoconfiguration mechanism for use in 6LoWPAN networks.
>
>
>
> The IETF Secretariat.
>
>

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
http= s://www.ietf.org/mailman/listinfo/6lowpan

= --1__=4EBBFE07DFAD4AC68f9e8a93df938690918c4EBBFE07DFAD4AC6-- --0__=4EBBFE07DFAD4AC68f9e8a93df938690918c4EBBFE07DFAD4AC6 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=4EBBFE07DFAD4AC68f9e8a93df93@philips.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFE07DFAD4AC68f9e8a93df938690918c4EBBFE07DFAD4AC6 Content-type: image/gif; name="pic08262.gif" Content-Disposition: inline; filename="pic08262.gif" Content-ID: <20__=4EBBFE07DFAD4AC68f9e8a93df93@philips.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFE07DFAD4AC68f9e8a93df938690918c4EBBFE07DFAD4AC6 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <30__=4EBBFE07DFAD4AC68f9e8a93df93@philips.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFE07DFAD4AC68f9e8a93df938690918c4EBBFE07DFAD4AC6-- --===============1518067650== 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://www.ietf.org/mailman/listinfo/6lowpan --===============1518067650==-- From 6lowpan-bounces@ietf.org Mon Jul 28 04:54:08 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18BC73A68C8; Mon, 28 Jul 2008 04:54:08 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC1C3A68C8; Mon, 28 Jul 2008 04:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxuSjf5cNvkX; Mon, 28 Jul 2008 04:54:00 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 97B5D3A6880; Mon, 28 Jul 2008 04:54:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 510E4AF869; Mon, 28 Jul 2008 04:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQJZAo9s0zJs; Mon, 28 Jul 2008 04:54:09 -0700 (PDT) Received: from jhui-mac.meeting.ietf.org (unknown [130.129.19.110]) by mail.sf.archrock.com (Postfix) with ESMTP id 4A8B7AF85B; Mon, 28 Jul 2008 04:54:08 -0700 (PDT) Message-Id: <324B87FD-D47C-469D-9FF6-49CB7BF8D9E4@archrock.com> From: Jonathan Hui To: Anthony Schoofs In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 28 Jul 2008 04:54:05 -0700 References: X-Mailer: Apple Mail (2.926) Cc: 6lowpan-bounces@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-hui-6lowpan-nd-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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="===============0172415747==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============0172415747== Content-Type: multipart/alternative; boundary=Apple-Mail-28-568160849 --Apple-Mail-28-568160849 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Anthony, Thanks for the quick feedback! See below: On Jul 28, 2008, at 4:39 AM, Anthony Schoofs wrote: > Hi Jonathan, > I just had a quick look at your draft about Neighbor Discovery and > Autoconfiguration for Route-Over 6LoWPAN Networks. It seems very good! > Thanks! It was an initial draft written last minute, so it is missing details as you point out below. I just wanted to get the basic idea out there. > - A general question: as you recall it, either the IEEE EUI-64 or > short address combined with the PAN ID may be used to generate an > IID, as specified in [RFC4944]. > Later you mention that appropriate link-layer address can be > regenerated from the IID. > When a node from network A receives a packet from network B, how > does it know whether the source node has used the short adress or > the EUI-64 address to form the IID? I understand that you can use > the U/L bit to separate EUI-64 from short addressing usage, but will > destination nodes always have to check this U/L bit when receiving > packets? > The text isn't very clear about this. The assumption is that the u/l- bit in the IID will tell you if it's global or local scope. The former implies an IEEE EUI-64, while the latter implies a short address. > - About the Router Advertisements, we need to make sure that they > are received by all the nodes. With respect to sensor networks > constraints, nodes may not always be able to be awake when they are > multicasted. Do you leave this issue to be solved by other means > (global network time synchro, local buffering of RAs for > transmission when nodes are awake,..)? > The exact implementation of ND will depend on whether or not the link protocol provides a multicast mechanism. If not, sleeping nodes can periodically wake up and send unicast Router Solicitations to routers and router will respond with unicast Router Advertisements. There was a brief statement in the Router Advertisement specification saying that the destination address can be the source address of a received Router Solicitation. This functionality is supported by IPv6 ND, so I'm not inventing anything new here. > - It is mentionned that the RAs transmission period must use the > trickle algorithm. I am not familiar with it, but it seems to me > that it is not appropriate for networks with mobile nodes. I am > looking at networks where nodes can move anytime, and we would go > for short RAs periods. Is mobility out of your document scope? > Mobility is not intended to be out of scope. The Trickle algorithm just says that the transmission period increases over time but that there are one or more triggers that may reset the period back to something small. The exact triggers that reset the transmission period are not constrained by those mentioned in the document. I should make that more clear. > - Finally, you wrote that all 6LoWPAN nodes MUST accept the newest > prefix information. Is this a requirement? Again, I am interested in > mobile nodes and we may want to use other metrics for choosing the > prefix information. > I think I see your point, but I'd also like to hear what you had in mind. For context-based header compression to work, neighboring nodes have to agree on the prefix information for each context. That's why I tried to make sure nodes were consistent rather than not. If you're talking about address autoconfiguration, that's a different story. Just because the 'A' bit is set doesn't mean that a node must configure an IPv6 address using that prefix information. The 'A' bit only indicates that it can, at least that's my interpretation of it. Again. Thanks for the quick feedback. -- Jonathan Hui > > > Thanks! > Best regards, > Anthony > > -- > Anthony Schoofs > Research Scientist > Philips Research > High Tech Campus 34 , 5656 AE Eindhoven, The Netherlands > Email: anthony.schoofs@philips.com > > Jonathan Hui > > > Jonathan Hui > Sent by: > 6lowpan-bounces@ietf.org > > 28-07-2008 12:07 > > > To > > 6lowpan <6lowpan@ietf.org> > > cc > > > Subject > > [6lowpan] Fwd: New Version Notification for draft-hui-6lowpan-nd-00 > > Classification > > > > > Feedback/suggestions welcome. > > Thanks. > > -- > Jonathan Hui > > > > Begin forwarded message: > > > From: IETF I-D Submission Tool > > Date: July 28, 2008 2:15:48 AM PDT > > To: jhui@archrock.com > > Subject: New Version Notification for draft-hui-6lowpan-nd-00 > > > > > > A new version of I-D, draft-hui-6lowpan-nd-00.txt has been > > successfuly submitted by Jonathan Hui and posted to the IETF > > repository. > > > > Filename: draft-hui-6lowpan-nd > > Revision: 00 > > Title: Neighbor Discovery and Autoconfiguration for Route-Over > > 6LoWPAN Networks > > Creation_date: 2008-07-28 > > WG ID: Independent Submission > > Number_of_pages: 24 > > > > Abstract: > > This document specifies a simple version of IPv6 Neighbor Discovery > > for route-over 6LoWPAN networks. 6LoWPAN ND allows nodes to discover > > routers, discover network configuration parameters, and IPv6 > prefixes > > for use with stateless address autoconfiguration and context-based > > 6LoWPAN compression for IPv6 headers. This document also specifies > > autoconfiguration mechanism for use in 6LoWPAN networks. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --Apple-Mail-28-568160849 Content-Type: multipart/related; boundary=Apple-Mail-29-568160850; type="text/html" --Apple-Mail-29-568160850 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable


Hi = Anthony,

Thanks for the quick feedback! See = below:

On Jul 28, 2008, at 4:39 AM, = Anthony Schoofs wrote:

Hi = Jonathan,
I just had a quick look at your draft about Neighbor = Discovery and Autoconfiguration for Route-Over 6LoWPAN Networks. It = seems very good!

Thanks! It was an initial draft = written last minute, so it is missing details as you point out below. I = just wanted to get the basic idea out there.

- A general question: as you recall it, either the = IEEE EUI-64 or short address combined with the PAN ID may be used to = generate an IID, as specified in [RFC4944].
Later you mention that = appropriate link-layer address can be regenerated from the IID.
= When a node from network A receives a packet from network B, how does it = know whether the source node has used the short adress or the EUI-64 = address to form the IID? I understand that you can use the U/L bit to = separate EUI-64 from short addressing usage, but will destination nodes = always have to check this U/L bit when receiving = packets?

The text isn't very clear about this. The = assumption is that the u/l-bit in the IID will tell you if it's global = or local scope. The former implies an IEEE EUI-64, while the latter = implies a short address.

- About = the Router Advertisements, we need to make sure that they are received = by all the nodes. With respect to sensor networks constraints, nodes may = not always be able to be awake when they are multicasted. Do you leave = this issue to be solved by other means (global network time synchro, = local buffering of RAs for transmission when nodes are = awake,..)?

The exact implementation of ND will = depend on whether or not the link protocol provides a multicast = mechanism. If not, sleeping nodes can periodically wake up and send = unicast Router Solicitations to routers and router will respond with = unicast Router Advertisements. There was a brief statement in the Router = Advertisement specification saying that the destination address can be = the source address of a received Router Solicitation. This functionality = is supported by IPv6 ND, so I'm not inventing anything new = here.

- It is mentionned that the = RAs transmission period must use the trickle algorithm. I am not = familiar with it, but it seems to me that it is not appropriate for = networks with mobile nodes. I am looking at networks where nodes can = move anytime, and we would go for short RAs periods. Is mobility out of = your document scope?

Mobility is not intended to = be out of scope. The Trickle algorithm just says that the transmission = period increases over time but that there are one or more triggers that = may reset the period back to something small. The exact triggers that = reset the transmission period are not constrained by those mentioned in = the document. I should make that more clear.

- Finally, you wrote that all 6LoWPAN nodes MUST = accept the newest prefix information. Is this a requirement? Again, I am = interested in mobile nodes and we may want to use other metrics for = choosing the prefix information.

I think I = see your point, but I'd also like to hear what you had in mind. For = context-based header compression to work, neighboring nodes have to = agree on the prefix information for each context. That's why I tried to = make sure nodes were consistent rather than not. If you're talking = about address autoconfiguration, that's a different story. Just because = the 'A' bit is set doesn't mean that a node must configure an IPv6 = address using that prefix information. The 'A' bit only indicates that = it can, at least that's my interpretation of = it.

Again. Thanks for the quick = feedback.

--
Jonathan = Hui


=
Thanks!
Best regards,
Anthony

--
Anthony = Schoofs
Research Scientist
Philips Research
High Tech Campus = 34 , 5656 AE Eindhoven, The Netherlands
Email: anthony.schoofs@philips.com

<graycol.gif>Jonathan Hui <jhui@archrock.com>


= =
=
<ecblank.gif>
To
<ecblank.gif>
6lowpan = <6lowpan@ietf.org>
<ecblank.gif>
=
cc
<ecblank.gif>
<ecblank.gif>
Subject
<ecblank.gif>
[6lowpan] Fwd: New Version Notification for = draft-hui-6lowpan-nd-00
<ecblank.gif>
Classification
<ecblank.gif>
=
<ecblank.gif><ecblank.gif>
=


Feedback/suggestions = welcome.

Thanks.

--
Jonathan Hui


=
Begin forwarded message:

> From: IETF I-D Submission Tool = <idsubmission@ietf.org>
> = Date: July 28, 2008 2:15:48 AM PDT
> To: jhui@archrock.com
> Subject: = New Version Notification for draft-hui-6lowpan-nd-00
>
>
> A = new version of I-D, draft-hui-6lowpan-nd-00.txt has been  
> = successfuly submitted by Jonathan Hui and posted to the IETF  
= > repository.
>
> Filename: =  draft-hui-6lowpan-nd
> Revision:  00
> = Title:  Neighbor Discovery and = Autoconfiguration for Route-Over  
> 6LoWPAN Networks
> = Creation_date:  2008-07-28
> WG ID: =  Independent Submission
> Number_of_pages: 24
>
> = Abstract:
> This document specifies a simple version of IPv6 = Neighbor Discovery
> for route-over 6LoWPAN networks. 6LoWPAN ND = allows nodes to discover
> routers, discover network configuration = parameters, and IPv6 prefixes
> for use with stateless address = autoconfiguration and context-based
> 6LoWPAN compression for IPv6 = headers.  This document also specifies
> autoconfiguration = mechanism for use in 6LoWPAN networks.
>
>
>
> The IETF = Secretariat.
>
>

= _______________________________________________
6lowpan mailing = list
6lowpan@ietf.org
= https://www.ietf.or= g/mailman/listinfo/6lowpan

=


= --Apple-Mail-29-568160850 Content-Disposition: inline; filename=pic08262.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="pic08262.gif" Content-Id: <20__=4EBBFE07DFAD4AC68f9e8a93df93@philips.com> R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --Apple-Mail-29-568160850-- --Apple-Mail-28-568160849-- --===============0172415747== 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://www.ietf.org/mailman/listinfo/6lowpan --===============0172415747==-- From 6lowpan-bounces@ietf.org Mon Jul 28 08:15:57 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85ACF28C138; Mon, 28 Jul 2008 08:15:57 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E23428C138 for <6lowpan@core3.amsl.com>; Mon, 28 Jul 2008 08:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2D66Yf+B+dl for <6lowpan@core3.amsl.com>; Mon, 28 Jul 2008 08:15:55 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id AC26428C0E0 for <6lowpan@ietf.org>; Mon, 28 Jul 2008 08:15:54 -0700 (PDT) Received: from snl-zach.local ([130.129.20.190]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m6SFFws2005626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Mon, 28 Jul 2008 18:15:59 +0300 Message-ID: <488DE2D1.8060702@sensinode.com> Date: Mon, 28 Jul 2008 16:16:33 +0100 From: Zach Shelby User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] Dinner Wed night - Merry Ploughboys X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Dear 6lowpanners, I am arranging a dinner for 6lowpaners (OK, rollers too) Wed night right after the plenary at a famous music pub called the Merry Ploughboys. It is just 15 min away by taxi and has a dinner followed by traditional music and dance. See www.mpbpub.com. If you are interested please send me a binding solicitation to my unicast address by the end of tomorrow's 6lowpan session and I will ack you. Right now I have a 12 person table reserved. So far 4 people have shown tentative interest. They said they still have plenty of space so if tons of people want to go it is no problem. Details: Taxis leave at 7.15 PM (dinner start time is strict) from in front of the Citywest. 20 EUR/taxi and they fit up to 6 people each, so cheap. The music is done at around 10.30 PM, so we'll take taxis back to the citywest. Those who are staying in the city can take a taxi directly there (20 minutes to downtown). Everyone pays their own share of the taxi and bill, so probably good to take some cash. Although they take credit card as well. - Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 28 11:52:36 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC39A3A6AF8; Mon, 28 Jul 2008 11:52:36 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2B43A6AF8 for <6lowpan@core3.amsl.com>; Mon, 28 Jul 2008 11:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fomiMMRPjoEF for <6lowpan@core3.amsl.com>; Mon, 28 Jul 2008 11:52:34 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by core3.amsl.com (Postfix) with ESMTP id 08CE63A69A9 for <6lowpan@ietf.org>; Mon, 28 Jul 2008 11:52:34 -0700 (PDT) Received: from mlsv6.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id D25EE37C83 for <6lowpan@ietf.org>; Tue, 29 Jul 2008 03:52:43 +0900 (JST) Received: from MFILTER-S3.hitachi.co.jp by mlsv6.hitachi.co.jp (8.13.1/8.13.1) id m6SIqhkx027805; Tue, 29 Jul 2008 03:52:43 +0900 Received: from vshuts2.hitachi.co.jp (unverified) by MFILTER-S3.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Tue, 29 Jul 2008 03:52:43 +0900 X-AuditID: 0ac90647-ad2a4ba0000028e2-e9-488e157b65c1 Received: from hsdlgw92.sdl.hitachi.co.jp (unknown [133.144.7.20]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id 8BD408B0113; Tue, 29 Jul 2008 03:52:43 +0900 (JST) Received: from vgate2.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.13.1/3.7W06092911) id m6SIqgZN017970; Tue, 29 Jul 2008 03:52:43 +0900 Received: from sdl99w.sdl.hitachi.co.jp ([133.144.14.250]) by vgate2.sdl.hitachi.co.jp (SAVSMTP 3.1.1.32) with SMTP id M2008072903524200897 ; Tue, 29 Jul 2008 03:52:42 +0900 Received: from 127.0.0.1 (IDENT:U2FsdGVkX1+TCo9wqbLsV0iutmcFS+khnW6h9L+KY2g@localhost.localdomain [127.0.0.1]) by sdl99w.sdl.hitachi.co.jp (8.13.1/3.7W04031011) with SMTP id m6SIqej7028167; Tue, 29 Jul 2008 03:52:40 +0900 Message-Id: <200807281852.m6SIqej7028167@sdl99w.sdl.hitachi.co.jp> Date: Tue, 29 Jul 2008 03:52:40 +0900 From: IGARASHI Yuichi X-Mailer: EdMax Ver2.85.5F MIME-Version: 1.0 To: Jonathan Hui In-Reply-To: <1344176C-F7DF-44C9-98C6-B43EAC328A87@archrock.com> References: <1344176C-F7DF-44C9-98C6-B43EAC328A87@archrock.com> X-Brightmail-Tracker: AAAAAA== Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-hui-6lowpan-nd-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan, I have two simple questions in draft-hui-6lowpan-nd-01. -Terminology Why do you use "Next Hop" in LOWPAN_IPHC? Why do not you use "Next Header"? -Order Why do you set "TVF"? Why do not you set "VTF"like as IPv6 packet format? Best regards, Yuichi Jonathan Hui wrote: > > Feedback/suggestions welcome. > > Thanks. > > -- > Jonathan Hui > > > > Begin forwarded message: > > > From: IETF I-D Submission Tool > > Date: July 28, 2008 2:15:48 AM PDT > > To: jhui@archrock.com > > Subject: New Version Notification for draft-hui-6lowpan-nd-00 > > > > > > A new version of I-D, draft-hui-6lowpan-nd-00.txt has been > > successfuly submitted by Jonathan Hui and posted to the IETF > > repository. > > > > Filename: draft-hui-6lowpan-nd > > Revision: 00 > > Title: Neighbor Discovery and Autoconfiguration for Route-Over > > 6LoWPAN Networks > > Creation_date: 2008-07-28 > > WG ID: Independent Submission > > Number_of_pages: 24 > > > > Abstract: > > This document specifies a simple version of IPv6 Neighbor Discovery > > for route-over 6LoWPAN networks. 6LoWPAN ND allows nodes to discover > > routers, discover network configuration parameters, and IPv6 prefixes > > for use with stateless address autoconfiguration and context-based > > 6LoWPAN compression for IPv6 headers. This document also specifies > > autoconfiguration mechanism for use in 6LoWPAN networks. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > -- Hitachi, Ltd., Systems Development Laboratory IGARASHI Yuichi Mail： yuichi.igarashi.hb@.hitachi.com Tel ： +81-(0)45-860-3080 FAX ： +81-(0)45-860-1674 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 28 12:23:25 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695C33A6B0B; Mon, 28 Jul 2008 12:23:25 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0243A6B0B for <6lowpan@core3.amsl.com>; Mon, 28 Jul 2008 12:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PD2HjTsZIwx for <6lowpan@core3.amsl.com>; Mon, 28 Jul 2008 12:23:23 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 87C0D3A6B06 for <6lowpan@ietf.org>; Mon, 28 Jul 2008 12:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m6SJNInW017399; Mon, 28 Jul 2008 21:23:22 +0200 (CEST) Message-Id: From: Carsten Bormann To: Carsten Bormann In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 28 Jul 2008 20:23:18 +0100 References: <5C489A30-AA4D-4626-939A-1BCD1D9C1539@tzi.org> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Call for agenda items for Dublin meeting X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org An updated agenda is at: http://www.ietf.org/proceedings/08jul/agenda/6lowpan.txt and a first version of the consolidated slides is at: http://www.ietf.org/proceedings/08jul/slides/6lowpan-0.pdf KHK, SC, EN, CW, consider yourself reminded that I need your slides :-) See you all tomorrow morning! Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 29 00:03:57 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551343A6AD2; Tue, 29 Jul 2008 00:03:57 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94FDB3A6ACE for <6lowpan@core3.amsl.com>; Tue, 29 Jul 2008 00:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.890, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIq6I2WAtz1u for <6lowpan@core3.amsl.com>; Tue, 29 Jul 2008 00:03:55 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 977D428C0FB for <6lowpan@ietf.org>; Tue, 29 Jul 2008 00:03:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 4255FAF895; Tue, 29 Jul 2008 00:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWJT4g-z7gLg; Tue, 29 Jul 2008 00:04:05 -0700 (PDT) Received: from [172.17.6.176] (unknown [130.129.65.140]) by mail.sf.archrock.com (Postfix) with ESMTP id E9DA3AF869; Tue, 29 Jul 2008 00:04:04 -0700 (PDT) Message-Id: <3949701D-2DEB-4C2A-ADFE-FEBD4E3F38CD@archrock.com> From: Jonathan Hui To: IGARASHI Yuichi In-Reply-To: <200807281852.m6SIqej7028167@sdl99w.sdl.hitachi.co.jp> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 29 Jul 2008 00:04:01 -0700 References: <1344176C-F7DF-44C9-98C6-B43EAC328A87@archrock.com> <200807281852.m6SIqej7028167@sdl99w.sdl.hitachi.co.jp> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-hui-6lowpan-nd-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-2022-jp"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Yuichi: On Jul 28, 2008, at 11:52 AM, IGARASHI Yuichi wrote: > Hi Jonathan, > > I have two simple questions in draft-hui-6lowpan-nd-01. > > -Terminology > Why do you use "Next Hop" in LOWPAN_IPHC? > Why do not you use "Next Header"? Oops, typo. Thanks for catching that. I'll fix it in the next revision. > -Order > Why do you set "TVF"? > Why do not you set "VTF"like as IPv6 packet format? One of the changes is that I split out Traffic Class from Flow Label, allowing you to carry one inline without having to carry the other. I'm keeping Version with Flow Label simply to maintain byte alignment. But since Version and Flow Label span Traffic Class, there's no real ordering that can be had there. Thanks. -- Jonathan Hui > > > Best regards, > Yuichi > > Jonathan Hui wrote: > >> >> Feedback/suggestions welcome. >> >> Thanks. >> >> -- >> Jonathan Hui >> >> >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: July 28, 2008 2:15:48 AM PDT >>> To: jhui@archrock.com >>> Subject: New Version Notification for draft-hui-6lowpan-nd-00 >>> >>> >>> A new version of I-D, draft-hui-6lowpan-nd-00.txt has been >>> successfuly submitted by Jonathan Hui and posted to the IETF >>> repository. >>> >>> Filename: draft-hui-6lowpan-nd >>> Revision: 00 >>> Title: Neighbor Discovery and Autoconfiguration for Route-Over >>> 6LoWPAN Networks >>> Creation_date: 2008-07-28 >>> WG ID: Independent Submission >>> Number_of_pages: 24 >>> >>> Abstract: >>> This document specifies a simple version of IPv6 Neighbor Discovery >>> for route-over 6LoWPAN networks. 6LoWPAN ND allows nodes to discover >>> routers, discover network configuration parameters, and IPv6 >>> prefixes >>> for use with stateless address autoconfiguration and context-based >>> 6LoWPAN compression for IPv6 headers. This document also specifies >>> autoconfiguration mechanism for use in 6LoWPAN networks. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > > > -- > Hitachi, Ltd., Systems Development Laboratory > IGARASHI Yuichi > Mail： yuichi.igarashi.hb@.hitachi.com > Tel ： +81-(0)45-860-3080 > FAX ： +81-(0)45-860-1674 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 29 04:58:39 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8295A3A697D; Tue, 29 Jul 2008 04:58:39 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D6593A6AA3 for <6lowpan@core3.amsl.com>; Tue, 29 Jul 2008 04:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AyhdTPv2p23 for <6lowpan@core3.amsl.com>; Tue, 29 Jul 2008 04:58:36 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id ED5763A6A93 for <6lowpan@ietf.org>; Tue, 29 Jul 2008 04:58:36 -0700 (PDT) Received: from [130.129.18.222] (helo=aeolus.meeting.ietf.org) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KNnqq-0005w5-Gm for 6lowpan@ietf.org; Tue, 29 Jul 2008 04:58:49 -0700 Message-Id: <58AEC951-94DA-4FA7-BDEA-0EB0629895CB@cs.stanford.edu> From: Philip Levis To: 6lowpan@ietf.org Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 29 Jul 2008 12:58:46 +0100 X-Mailer: Apple Mail (2.926) X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 Subject: [6lowpan] Trickle X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org I'm sorry I couldn't make the 6lowpan meeting today; I was over at alto. Jonathan mentioned that a lot of people were interested in Trickle. Luckily, the July issue of CACM has it as a research highlight. This means it's a 7-page paper written for a larger audience. I'm happy to answer any questions people have about it. It's a research highlight because it's been in heavy use for about five years now in the TinyOS community, and so was not only a big splash when it came out but has also held up to the test of time. Here's the URL: http://mags.acm.org/communications/200807/ You want the article entitled "The Emergence of a Networking Primitive in Wireless Sensor Networks." The basic thrust of it is Trickle is a way to establish eventual consistency quickly, cheaply, and with excellent (logarithmic) scaling properties. This is the abstract of the paper: "The wireless sensor network community approached networking abstractions as an open question, allowing answers to emerge with time and experience. The Trickle algorithm has become a basic mechanism used in numerous protocols and systems. Trickle brings nodes to eventual consistency quickly and efficiently while remaining remarkably robust to variations in network density, topology, and dynamics. Instead of flooding a network with packets, Trickle uses a ``polite gossip'' policy to control send rates so each node hears just enough packets to stay consistent. This simple mechanism enables Trickle to scale to thousand-fold changes in network density, reach consistency in seconds, and require only a few bytes of state yet impose a maintenance cost of a few sends an hour. Originally designed for disseminating new code, experience has shown Trickle to have much broader applicability, including route maintenance and neighbor discovery. This paper provides an overview of the research challenges wireless sensor networks face, describes the Trickle algorithm, and outlines several ways it is used today." Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 31 08:56:22 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4B328C1A4; Thu, 31 Jul 2008 08:56:22 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F9328C1AB for <6lowpan@core3.amsl.com>; Thu, 31 Jul 2008 08:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plO3mrqbmDXC for <6lowpan@core3.amsl.com>; Thu, 31 Jul 2008 08:56:17 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 1A98E28C1A4 for <6lowpan@ietf.org>; Thu, 31 Jul 2008 08:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m6VFuMWb005946; Thu, 31 Jul 2008 17:56:25 +0200 (CEST) Message-Id: <1BCE963E-642A-482E-A9DC-B64628D45544@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 31 Jul 2008 16:56:21 +0100 X-Mailer: Apple Mail (2.926) Cc: Carsten Bormann Subject: [6lowpan] Address compression examples X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Lowpanners, in the meeting, we have been discussing draft-hui-6lowpan-hc-01.txt (which I'll call "HC-01" here) with respect to the way to obtain the context required. I'd like to move back to the specific kinds of compression we can get. Let's recap HC1, which has four different modes for each direction, which lets us independently switch on prefix and IID compression: 00: PI, II 01: PI, IC 10: PC, II 11: PC, IC PI/II means we actually encode the prefix and IID parts, respectively, in the packet. PC means the prefix is compressed by assuming it is FE80::, IC means the IID is taken/constructed from the appropriate L2 information, or, if present, the "mesh addressing" field. HC-01 has a couple more modes, gated on AC (SAC/DAC) and AM (SAM/DAM). AM can be: 00: All 128 bits of Source Address are carried in-line. 01: 64-bit Compressed IPv6 address. 10: 16-bit Compressed IPv6 address. 11: All 128 bits of Source Address are elided. AC can be 00 (FE80::) or a context that is presumably giving a global prefix. CBHC-00 has: Context Prefix Number Length 0 0 (uncompressed) 1-3 TBD 4-7 /64 8-11 /112 12-15 /128 CBHC-00 clearly forgot link-local, so let me amend that to include a second constant context: 1 FE80::/64 CBHC also needs to have the IC flag from 4944 for the contexts 1 and 4-7; so I'll need to rejuggle the bits a bit (say, use context 2 for FE80::/64 with IC, and the rest split up between IC=0 and IC=1). Now let's see some examples. I'll ignore 16-bit addresses for now (I think HC-01 has set this up nicely, but examples would help verify that). The global prefix for our 6lowpan is 2345:: For simplicity, I'll abbreviate the IIDs as 2:1:1:1, 2:2:2:2, 2:3:3:3, or "own" if this is the L2 IID; 2:1:1:1 is the border router. The 6lowpan is communicating with a single correspondent network somewhere in the Internet, with addresses 2468::5, 2468::6, 268::7. We could have the following addresses in a packet: FE80::own FE80::2:1:1:1 FE80::2:2:2:2 FE80::2:3:3:3 2345::own 2345::2:1:1:1 2345::2:2:2:2 2345::2:3:3:3 2468::5 2468::6 The assumption in CBHC would be that the context is set up as follows: 4: 2345::/64 8: 2468::/112 12: 2468::5/128 13: 2468::6/128 14: 2468::7/128 15: 2345::2:1:1:1 8 and 12/13/14 are somewhat redundant here, but in practice there probably will be more nodes in the correspondent network, so I wanted to show both alternatives for CBHC (there may also be multiple correspondent networks, of course). Note that the encoding of the context can be done in such a way that there is no redundancy between 4 and 15. In HC-01, the context might be set up as: 1: 2345::2:1:1:1 2: 2468::5 3: 2468::6 Now let's encode: 4944 CBHC HC-01 FE80::own 11, 0 ctx=1, II=1, [] am=11, ac=0 FE80::2:1:1:1 10, [2:1:1:1] ctx=1, II=0, [2:1:1:1] am=01, ac=0, [2:1:1:1] FE80::2:2:2:2 10, [2:2:2:2] ctx=1, II=0, [2:2:2:2] am=01, ac=0, [2:2:2:2] FE80::2:3:3:3 10, [2:3:3:3] ctx=1, II=0, [2:3:3:3] am=01, ac=0, [2:3:3:3] 2345::own 01, [2345::] ctx=4, II=1 am=11, ac=0, [own] 2345::2:1:1:1 00, (uncompr) ctx=15 am=11, ac=1 2345::2:2:2:2 00, (uncompr) ctx=4, II=0, [2:2:2:2] am=01, ac=1, [2:2:2:2] 2345::2:3:3:3 00, (uncompr) ctx=4, II=0, [2:3:3:3] am=01, ac=1, [2:3:3:3] 2468::5 00, (uncompr) ctx=12 (or 8, [5]) am=11, ac=2 2468::6 00, (uncompr) ctx=13 (or 8, [6]) am=11, ac=3 2468::7 00, (uncompr) ctx=14 (or 8, [7]) am=10, ac=2, [7] I have no idea whether I correctly interpreted HC-01, and I obviously have to fix CBHC, so I'm looking forward to discussion. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 31 09:56:18 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDEE28C1E3; Thu, 31 Jul 2008 09:56:18 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C55728C1B1 for <6lowpan@core3.amsl.com>; Thu, 31 Jul 2008 09:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUwOeOPIwACV for <6lowpan@core3.amsl.com>; Thu, 31 Jul 2008 09:56:14 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 66F2A28C1C9 for <6lowpan@ietf.org>; Thu, 31 Jul 2008 09:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m6VGuGfW014220; Thu, 31 Jul 2008 18:56:19 +0200 (CEST) Message-Id: <804EEBA5-44A0-4421-B47F-430094A81EDC@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 31 Jul 2008 17:56:15 +0100 X-Mailer: Apple Mail (2.926) Cc: Carsten Bormann Subject: [6lowpan] HC-01 ready to advance to WG document? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Lowpanners, we were so pressed for time at the WG meeting that the chairs forgot to ask "the question": Do we believe that draft-hui-6lowpan-hc-01.txt is now ready to become the WG document for charter item 2, "6LoWPAN Improved Header Compression"? Note that moving the document to WG document status does not mean we have to agree with every detail in there. We just need to agree that it is a good basis for the remaining work. (Moving to WG document status also means that all further changes should be the result of work in the WG, so it also removes a little flexibility that the authors of an individual draft have.) I believe there was tacit agreement in the room in Dublin, and I now want to make the agreement explicit on the mailing list. As the document has been pretty non-contentious, I'm looking forward to comments until Monday 1800 UTC. If there are no objections by this time, I'll ask Jonathan to resubmit the draft as a WG document (possibly with the changes resulting from this meeting). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 31 10:21:33 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3501B3A6A7B; Thu, 31 Jul 2008 10:21:33 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD7F28C28F for <6lowpan@core3.amsl.com>; Thu, 31 Jul 2008 10:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[AWL=0.884, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAwSTnzUuOy3 for <6lowpan@core3.amsl.com>; Thu, 31 Jul 2008 10:21:30 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2222428C273 for <6lowpan@ietf.org>; Thu, 31 Jul 2008 10:21:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="16141263" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Jul 2008 17:21:47 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6VHLl4J000476; Thu, 31 Jul 2008 13:21:47 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6VHLlr6021172; Thu, 31 Jul 2008 17:21:47 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 13:21:47 -0400 Received: from 10.61.96.43 ([10.61.96.43]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Jul 2008 17:21:47 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 31 Jul 2008 18:21:46 +0100 From: JP Vasseur To: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Message-ID: Thread-Topic: [6lowpan] HC-01 ready to advance to WG document? Thread-Index: AcjzMeiEafq89YJhh0Sg+PtBtV0ETA== In-Reply-To: <804EEBA5-44A0-4421-B47F-430094A81EDC@tzi.org> Mime-version: 1.0 X-OriginalArrivalTime: 31 Jul 2008 17:21:47.0420 (UTC) FILETIME=[E95D1DC0:01C8F331] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1339; t=1217524907; x=1218388907; 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]=20HC-01=20ready=20to=20advanc e=20to=20WG=20document? |Sender:=20 |To:=20Carsten=20Bormann=20,=206lowpan=20<6lo wpan@ietf.org>; bh=SZ/7IwM2PImHLp+8fI9Qb0onkKhdaeGhajhFLcXTtrE=; b=tfTOWsF7ilpnI/I4TA/qaXTO00MMYK/lS48gRWgKtjdgF6ahyAtUFUUtXp Bb1hM/qgvMfoh38+UGVTIA/8X3UUDyrjO0kFaiZHVC79tp38I9oQLz9aU/AA vCiKstMxzA; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [6lowpan] HC-01 ready to advance to WG document? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org In favor ! JP. On 7/31/08 5:56 PM, "Carsten Bormann" wrote: > Lowpanners, > > we were so pressed for time at the WG meeting that the chairs forgot > to ask "the question": > > Do we believe that draft-hui-6lowpan-hc-01.txt is now ready to become > the WG document for charter item 2, "6LoWPAN Improved Header > Compression"? > > Note that moving the document to WG document status does not mean we > have to agree with every detail in there. > We just need to agree that it is a good basis for the remaining work. > (Moving to WG document status also means that all further changes > should be the result of work in the WG, so it also removes a little > flexibility that the authors of an individual draft have.) > I believe there was tacit agreement in the room in Dublin, and I now > want to make the agreement explicit on the mailing list. > > As the document has been pretty non-contentious, I'm looking forward > to comments until Monday 1800 UTC. > If there are no objections by this time, I'll ask Jonathan to resubmit > the draft as a WG document (possibly with the changes resulting from > this meeting). > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 31 11:29:08 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A8E28C2BD; Thu, 31 Jul 2008 11:29:08 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E392F28C2AF for <6lowpan@core3.amsl.com>; Thu, 31 Jul 2008 11:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74gr41Tr7Ce8 for <6lowpan@core3.amsl.com>; Thu, 31 Jul 2008 11:29:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2724728C2C3 for <6lowpan@ietf.org>; Thu, 31 Jul 2008 11:29:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="15945670" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2008 18:29:10 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6VITAl9009309; Thu, 31 Jul 2008 20:29:10 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6VIT9k3010232; Thu, 31 Jul 2008 18:29:09 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 20:29:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jul 2008 20:27:49 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC060811EF@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] HC-01 ready to advance to WG document? Thread-Index: AcjzMeiEafq89YJhh0Sg+PtBtV0ETAACSlKg References: <804EEBA5-44A0-4421-B47F-430094A81EDC@tzi.org> From: "Pascal Thubert (pthubert)" To: "Jean Philippe Vasseur (jvasseur)" , "Carsten Bormann" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 31 Jul 2008 18:29:09.0826 (UTC) FILETIME=[52D35220:01C8F33B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1861; t=1217528950; x=1218392950; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20HC-01=20ready=20to=20advanc e=20to=20WG=20document? |Sender:=20; bh=SxQ3RBX5sPV4Kk18/CSttlZsthl00ucGDKav6zBGrCg=; b=Ij8/rikjp3v/RUdcFom/O7FdT3Vgiz6E1ZZWbvfuHSdFEF3trLGGFNXTLN 3YBreJTeUIiwhwDRwvemyjRD25S/D4xKHQQlGtF3gRohmTpcJVrn5amGsk6Z W45sg+LuON; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [6lowpan] HC-01 ready to advance to WG document? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org +1: We really need to move forward with this document! Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur >(jvasseur) >Sent: jeudi 31 juillet 2008 19:22 >To: Carsten Bormann; 6lowpan >Subject: Re: [6lowpan] HC-01 ready to advance to WG document? > >In favor ! > >JP. > > >On 7/31/08 5:56 PM, "Carsten Bormann" wrote: > >> Lowpanners, >> >> we were so pressed for time at the WG meeting that the chairs forgot >> to ask "the question": >> >> Do we believe that draft-hui-6lowpan-hc-01.txt is now ready to become >> the WG document for charter item 2, "6LoWPAN Improved Header >> Compression"? >> >> Note that moving the document to WG document status does not mean we >> have to agree with every detail in there. >> We just need to agree that it is a good basis for the remaining work. >> (Moving to WG document status also means that all further changes >> should be the result of work in the WG, so it also removes a little >> flexibility that the authors of an individual draft have.) >> I believe there was tacit agreement in the room in Dublin, and I now >> want to make the agreement explicit on the mailing list. >> >> As the document has been pretty non-contentious, I'm looking forward >> to comments until Monday 1800 UTC. >> If there are no objections by this time, I'll ask Jonathan to resubmit >> the draft as a WG document (possibly with the changes resulting from >> this meeting). >> >> Gruesse, Carsten >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 31 13:09:07 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3169D28C2F7; Thu, 31 Jul 2008 13:09:07 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFDDA28C2F7 for <6lowpan@core3.amsl.com>; Thu, 31 Jul 2008 13:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugcKgYD5yDzN for <6lowpan@core3.amsl.com>; Thu, 31 Jul 2008 13:09:06 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 1849728C2CA for <6lowpan@ietf.org>; Thu, 31 Jul 2008 13:09:06 -0700 (PDT) Received: from [76.14.71.180] (helo=[192.168.2.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KOeSh-0004FK-04; Thu, 31 Jul 2008 13:09:23 -0700 In-Reply-To: <804EEBA5-44A0-4421-B47F-430094A81EDC@tzi.org> References: <804EEBA5-44A0-4421-B47F-430094A81EDC@tzi.org> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <1FB2D5D5-8DF2-4A19-B092-F0E5E546B776@cs.stanford.edu> From: Philip Levis Date: Thu, 31 Jul 2008 13:08:39 -0700 To: Carsten Bormann X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] HC-01 ready to advance to WG document? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Jul 31, 2008, at 9:56 AM, Carsten Bormann wrote: > Lowpanners, > > we were so pressed for time at the WG meeting that the chairs > forgot to ask "the question": > > Do we believe that draft-hui-6lowpan-hc-01.txt is now ready to > become the WG document for charter item 2, "6LoWPAN Improved Header > Compression"? > +1. This is exactly the kind of improvement after a few months of experience that makes the IETF process so successful. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan