From 6lowpan-bounces@ietf.org Sun Mar 2 02:37:52 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6425A28C10E; Sun, 2 Mar 2008 02:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 k338+56ifygk; Sun, 2 Mar 2008 02:37:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22B03A6966; Sun, 2 Mar 2008 02:37:46 -0800 (PST) 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 6529C3A6966 for <6lowpan@core3.amsl.com>; Sun, 2 Mar 2008 02:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 kBqUHWoU5Lrg for <6lowpan@core3.amsl.com>; Sun, 2 Mar 2008 02:37:45 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 994153A6C47 for <6lowpan@ietf.org>; Sun, 2 Mar 2008 02:37:41 -0800 (PST) Received: from [127.0.0.1] (pptp-11.sics.se [193.10.64.171]) by letter.sics.se (Postfix) with ESMTP id 66998400CE for <6lowpan@ietf.org>; Sun, 2 Mar 2008 11:37:32 +0100 (CET) Message-ID: <47CA8369.8050302@sics.se> Date: Sun, 02 Mar 2008 11:37:29 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] "Zigbee Alliance Aiming at IPv6 Support" 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 Don't know if you've already seen these news, but I thought it might be interesting to people here: "ZIGBEE ALLIANCE CONTINUES EXPANDING THE INTERNET OF THINGS, Alliance Forming New Group Chartered To Expand Existing ZigBee IP Capabilities": http://www.zigbee.org/imwp/idms/popups/pop_download.asp?ContentID=12725 "This new initiative will make it easier for developers and system integrators to deploy ZigBee and to add additional features and functions, including IPv6 support." "ZigBee Alliance charters new group to explore Internet solutions": http://www.wirelessnetdesignline.com/206901000?cid=RSSfeed_wirelessnetdesignline_wndlRSS "Zigbee Alliance Aiming at IPv6 Support": http://freaklabs.org/index.php/Zigbee/zigbee-alliance-aiming-at-IP6-support.html Sounds like a direct answer to 6lowpan. /adam -- Adam Dunkels http://www.sics.se/~adam/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Mar 2 04:55:33 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECFA03A6DF7; Sun, 2 Mar 2008 04:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 wWNAY9ztfixj; Sun, 2 Mar 2008 04:55:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775393A6D4E; Sun, 2 Mar 2008 04:55:28 -0800 (PST) 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 623B23A6A6B for <6lowpan@core3.amsl.com>; Sun, 2 Mar 2008 04:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 2DeMVteuBosL for <6lowpan@core3.amsl.com>; Sun, 2 Mar 2008 04:55:26 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D634C3A6D86 for <6lowpan@ietf.org>; Sun, 2 Mar 2008 04:55:25 -0800 (PST) Received: from [10.0.1.3] (oul119-35.netplaza.fi [80.75.105.35]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m22CsxAR019088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Sun, 2 Mar 2008 14:54:59 +0200 Message-ID: <47CAA39E.4020201@sensinode.com> Date: Sun, 02 Mar 2008 14:54:54 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: 6lowpan@ietf.org References: <47CA8369.8050302@sics.se> In-Reply-To: <47CA8369.8050302@sics.se> Subject: Re: [6lowpan] "Zigbee Alliance Aiming at IPv6 Support" 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 Adam, This is funny actually. In a recent conference keynote I gave (EWSN 2008) I predicted that ZigBee will give up its proprietary framing and switch to RFC4944 by 2010. Seems they reacted? Anyways, this is the same old ZigBee philosophy "we can gateway anything" and who cares if its an ugly proxy cludge that needs to be updated for each new application... and we know how slow it takes to get a new profile... Someone should comment on that blog at least, the guy seems a bit confused about how 6lowpan works (double-back-flip to fit IPv6 in 802.15.4?). Maybe David should answer as the blogger wanted to know what Arch Rock thought of it ;-) - Zach Adam Dunkels wrote: > Don't know if you've already seen these news, but I thought it might be > interesting to people here: > > "ZIGBEE ALLIANCE CONTINUES EXPANDING THE INTERNET OF THINGS, Alliance > Forming New Group Chartered To Expand Existing ZigBee IP Capabilities": > http://www.zigbee.org/imwp/idms/popups/pop_download.asp?ContentID=12725 > > "This new initiative will make it easier for developers > and system integrators to deploy ZigBee and to add additional features > and functions, including IPv6 > support." > > "ZigBee Alliance charters new group to explore Internet solutions": > http://www.wirelessnetdesignline.com/206901000?cid=RSSfeed_wirelessnetdesignline_wndlRSS > > "Zigbee Alliance Aiming at IPv6 Support": > http://freaklabs.org/index.php/Zigbee/zigbee-alliance-aiming-at-IP6-support.html > > Sounds like a direct answer to 6lowpan. > > /adam -- Zach Shelby | CTO | +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 Sun Mar 2 06:29:35 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E97B28C12F; Sun, 2 Mar 2008 06:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 R-iIzAKt9bls; Sun, 2 Mar 2008 06:29:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632513A6825; Sun, 2 Mar 2008 06:29:34 -0800 (PST) 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 894F23A68AA for <6lowpan@core3.amsl.com>; Sun, 2 Mar 2008 06:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 tfZTHbNxa+Ah for <6lowpan@core3.amsl.com>; Sun, 2 Mar 2008 06:29:27 -0800 (PST) Received: from smtpout.eastlink.ca (smtpout.eastlink.ca [24.222.0.30]) by core3.amsl.com (Postfix) with ESMTP id C99EB3A6825 for <6lowpan@ietf.org>; Sun, 2 Mar 2008 06:28:34 -0800 (PST) Received: from ip03.eastlink.ca ([24.222.39.36]) by mta02.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JX300ISJXJBMLO1@mta02.eastlink.ca> for 6lowpan@ietf.org; Sun, 02 Mar 2008 10:28:23 -0400 (AST) Received: from blk-89-207-57.eastlink.ca (HELO [192.168.0.112]) ([24.89.207.57]) by ip03.eastlink.ca with ESMTP; Sun, 02 Mar 2008 09:54:23 -0400 Date: Sun, 02 Mar 2008 10:21:10 -0400 From: Colin O'Flynn To: 6lowpan@ietf.org Message-id: <200803021021.10955.coflynn@newae.com> Organization: NewAE MIME-version: 1.0 Content-disposition: inline X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPJIykcYWc85/2dsb2JhbAAIqiY X-IronPort-AV: E=Sophos;i="4.25,434,1199678400"; d="scan'208";a="286831289" User-Agent: KMail/1.9.6 (enterprise 0.20071204.744707) Subject: [6lowpan] Syncronized Wake 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 Hello All, First a quick question - I found this list on the IETF site. I assume it's a public list, you don't have to be a member of the working group to submit? Anyway, a few of us are working on doing a 6lowpan implementation. I was looking at doing a 'syncronized wake' to help save power yet get reasonable response times. By my calculations you could wake every few seconds and still have an exceptional battery life (year+). Since some nodes might need to wake up more often than others they might have different schedules, and obviously you'd need some sort of beacon to syncronize. The idea is each node has a "wake schedule" that nearby nodes know, and will be listening at that time. But any node can TX at almost any time. I don't want to do GTS though, as nodes can talk at any time. But I need a way to (a) sync nodes and (b) transmit wake schedule. So the question: would their be a standards-compliant way to do this? Or is it worth it trying to be standards compliant at this stage? It would be easy enough to make some simple protocol up to do this for testing. Warm Regards, -Colin O'Flynn PS: If you are interested: hardware is 8-bit AVR devices, using uIP for IPv6 implementation. The gateway router is AVR32 device, which can route over ethernet. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 3 04:39:41 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC9928C59D; Mon, 3 Mar 2008 04:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=-1.397, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 RB+R9AROrIvl; Mon, 3 Mar 2008 04:39:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B307A28C564; Mon, 3 Mar 2008 04:39:33 -0800 (PST) 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 BE1F33A6BC1 for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 04:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 wjv5nX53YPue for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 04:39:29 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A3F3E3A6D94 for <6lowpan@ietf.org>; Mon, 3 Mar 2008 04:37:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,438,1199660400"; d="scan'208";a="2354768" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Mar 2008 13:37:29 +0100 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 m23CbTIf012613; Mon, 3 Mar 2008 13:37:29 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m23CbEkm013061; Mon, 3 Mar 2008 12:37:16 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, 3 Mar 2008 13:37:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Mar 2008 13:36:45 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05482A60@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compressing HC1 and HC2 into HC3 thread-index: Ach9Kz3V709Gmew6Q3iJrMT+0p7uhA== From: "Pascal Thubert (pthubert)" To: "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 03 Mar 2008 12:37:14.0009 (UTC) FILETIME=[4EDAD890:01C87D2B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1536; t=1204547849; x=1205411849; 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:=20Compressing=20HC1=20and=20HC2=20into=20HC3 |Sender:=20; bh=rmUsEpRrI14i4GDg9uwNAwa3e/95wadGRRVvx55hdAs=; b=pqZ34Sun9tyb3B1eWR0nCcAT908VmmkcPAeR0wIh95dIYJ5md36xNLggVj eYssr0NtQAw8VE6wPHBkoq3bEq70lLLde4dT1d2lw7XrEeJUFONC2OWdC1Bc bd7itzv099; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: enns@stanfordalumni.org, Jay Werb Subject: [6lowpan] Compressing HC1 and HC2 into HC3 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 6LoWPANers, Though HC1 and HC2 provide us with the capability to express any combination of compression, the most expected (or at least shot for) case does not lead to a better compression of the HC headers themselves. Seems that we could define an HC3 that would compress the pair of HC1 and HC2 for that best case. My proposal for doing this would be to: - define a new dispatch | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and transport - define HC3 itself to: - implicitly say that the first 5 bits of HC1 are all ones - carry HC1 bits 5 and 6 (Next Header) - replace HC2 so bit 7 of HC1 is useless - provide transport specific bits such as those defined for HC-UDP, then again assuming a predefined best case if room is missing An example of what the HC3 octet could be: bits 0 1 2-3 4-7 +------------------+-------------+-----------------+-------------------- ---------------------+ | reserved | reserved | Next Header | transport specific control bits | +------------------+-------------+-----------------+-------------------- ---------------------+ Next header: as defined in HC1, bits 5 and 6 transport specific control bits for UDP: bit 4 echoes HC-UDP bit 0 on UDP source port bit 5 echoes HC-UDP bit 1 on UDP destination port bit 6 echoes HC-UDP bit 2 on UDP length bit 7 is reserved What do you think? Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 3 05:07:08 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99FF328C221; Mon, 3 Mar 2008 05:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=-1.273, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 Ltw7X7A-ekF9; Mon, 3 Mar 2008 05:07:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE97A28C586; Mon, 3 Mar 2008 05:06:38 -0800 (PST) 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 1ABDB28C567 for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 05:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 C0USa3rmksss for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 05:06:32 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C94B828C5DF for <6lowpan@ietf.org>; Mon, 3 Mar 2008 05:06:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,438,1199660400"; d="scan'208";a="2358754" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Mar 2008 14:05:58 +0100 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 m23D5wDs029338; Mon, 3 Mar 2008 14:05:58 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m23D5uks024539; Mon, 3 Mar 2008 13:05:58 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, 3 Mar 2008 14:05:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Mar 2008 14:05:30 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05482A8B@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compressing the IPv6 hop limit thread-index: Ach9L0H1mbBUN/ZsTcOOLzrs6zeIXg== From: "Pascal Thubert (pthubert)" To: "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 03 Mar 2008 13:05:58.0168 (UTC) FILETIME=[5288A180:01C87D2F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2504; t=1204549558; x=1205413558; 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:=20Compressing=20the=20IPv6=20hop=20limit |Sender:=20; bh=JyEIDrjMxNkkBKoociyBlq1S6pOPbq7EtUjlAnUr/Jg=; b=Ui0V5rxLXx3szicJHRlkcZjB/ralGk94Eb3G9FgJYCRwoB0HjYK0LIwyk6 qdFx1sYsgbYeEDoptQcsFbcr5eRFmhV0l8/sws/7mvHj+n8RPsQ8OYa14jmx lSJLqc2khv; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: enns@stanfordalumni.org, Jay Werb Subject: [6lowpan] Compressing the IPv6 hop limit 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: Per RFC 4944: "The only field in the IPv6 header that always needs to be carried in full is the Hop Limit (8 bits)." We understand the reason but I'd wish to point out that more often than not, an 802.15.4 network will be a stub, as opposed to a transit network. In other words, packets generated inside the LoWPAN can get out of the LoWPAN, but packets coming in will stay in. Still in other words, whatever the hop limit in a packet, when it comes into the LoWPAN it is as good as 1. So, if the LoWPAN is a stub, all we really need to know for loop avoidance is whether the packet is an inbound or an outbound packet, in order to make sure that inbound packets are discarded rather than be routed back outside the LoWPAN. We can define a default-hop-limit value (say 63) that the backbone router uses as it expands a 6LOWPAN header to forward the packet outside the LoWPAN. As a result, we can compress the hop limit in stub LoWPANs if we have 2 control bits, one bit to say that we're doing it in the first place, and one bit to express whether the packet is coming from the outside in which case it will have to stay in. If we consider my HC3 proposal, then we can reuse the first 2 bits of HC3 for this purpose: bits 0 1 2-3 4-7 +------------------+-------------+-----------------+-------------------- ---------------------+ | hop-limit elided | inbound | Next Header | transport specific control bits | +------------------+-------------+-----------------+-------------------- ---------------------+ Hop limit: set if the IPv6 hop limit is elided. This can be done iff: - the LowPAN is NOT a transit network - a default value (say 63) can be assumed for outbound packet by the backbone router Inbound: set for an inbound packet (that is a packet coming from outside the LoWPAN). Reset for a packet that is issued by a LoWPAN node to be sent to a LoWPAN node or to the Internet via a backbone router that terminates the 6LoWPAN encoding. For instance, a field device always leaves the inbound bit to zero. A backbone router that is encoding a packet coming from another interface will set the bit to one. A backbone router will discard a packet coming from a LoWPAN interface with the bit set rather than route it over another interface. What do you think? Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 3 05:26:07 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2BE28C477; Mon, 3 Mar 2008 05:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[AWL=-1.122, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 k1V9jXp4CuYn; Mon, 3 Mar 2008 05:26:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F503A6B1E; Mon, 3 Mar 2008 05:26:02 -0800 (PST) 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 3630228C244 for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 05:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 6OyZIZShVfBq for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 05:26:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2432F3A6A16 for <6lowpan@ietf.org>; Mon, 3 Mar 2008 05:26:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,438,1199660400"; d="scan'208";a="2361612" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Mar 2008 14:25:48 +0100 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 m23DPk24029633; Mon, 3 Mar 2008 14:25:46 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m23DPel4002771; Mon, 3 Mar 2008 13:25:46 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, 3 Mar 2008 14:25:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Mar 2008 14:25:02 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05482ABE@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compressing the UDP checksum thread-index: Ach9MfzQcZ+CLn1ZTD2VIeJAtNRC6Q== From: "Pascal Thubert (pthubert)" To: "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 03 Mar 2008 13:25:33.0933 (UTC) FILETIME=[0F5821D0:01C87D32] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1241; t=1204550746; x=1205414746; 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:=20Compressing=20the=20UDP=20checksum |Sender:=20; bh=zZdBuobPYO76UelHCgcRUvayxI8Xinz4LbT7IOvrIkw=; b=VwXItFjTB3OyT36GXXk7NufV9YgisY+oHEQQav7+biwETBVy300cqjbyDF DY8R1TN4X/88SIha+SK2Fs4BvcYBy2uKVINsIlierK+Sc+IGL91otZLWEW8A lT8mMBT9ea; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: enns@stanfordalumni.org, Jay Werb Subject: [6lowpan] Compressing the UDP checksum 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: Per RFC 4944: "The UDP header's checksum field is not compressed and is therefore carried in full." The UDP checksum is not the only way to protect the IP pseudo header, the UDP header and the payload. ISA 100.11a is defining a transport-level security that does all this and more, since it has a larger signature and provides mutual authentication at the same time. Also, the ISA100.11a transport-level security is usually hardware-assisted, so it requires little power or CPU time on the field device, whereas UDP checksum will be a costly CPU operation. So ISA100.11a is an example where the UDP checksum could and actually should be compressed over the LoWPAN, leaving it up to be reconstructed by a backbone router should the packet go any further than the LOWPAN itself. Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to standardize it to mean that the UDP checksum is compressed, provided that the headers and payload are equally or better protected than if the checksum was used. Note: that would be bit 7 in my HC3 proposal. As a result, the complete HC3 proposal could save us up to 4 additional bytes over RFC 4944 for a UDP packet. What do you think? Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 3 09:23:45 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB92C3A6CBB; Mon, 3 Mar 2008 09:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 KtxsFIMhx2uo; Mon, 3 Mar 2008 09:23:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390EF3A6A68; Mon, 3 Mar 2008 09:23:40 -0800 (PST) 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 EB2153A6A44 for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 09:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 pWmCh6oIsuJF for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 09:23:33 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id F35423A69E3 for <6lowpan@ietf.org>; Mon, 3 Mar 2008 09:23:26 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m23HNE6o027142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Mar 2008 09:23:16 -0800 (PST) Message-ID: <47CC33FD.4060008@eecs.berkeley.edu> Date: Mon, 03 Mar 2008 09:23:09 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC05482ABE@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05482ABE@xmb-ams-337.emea.cisco.com> Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing the UDP checksum 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 - this is a clear and coherent description of why UDP checksum should be elided in some circumstances. Much better than my efforts earlier, and I think that you've addressed most of the concerns that were raised then. I think it's a great idea. ksjp Pascal Thubert (pthubert) wrote: > Hi: > > Per RFC 4944: > "The UDP header's checksum field is not compressed and is therefore > carried in full." > > The UDP checksum is not the only way to protect the IP pseudo header, > the UDP header and the payload. > ISA 100.11a is defining a transport-level security that does all this > and more, since it has a larger signature and provides mutual > authentication at the same time. > > Also, the ISA100.11a transport-level security is usually > hardware-assisted, so it requires little power or CPU time on the field > device, whereas UDP checksum will be a costly CPU operation. > > So ISA100.11a is an example where the UDP checksum could and actually > should be compressed over the LoWPAN, leaving it up to be reconstructed > by a backbone router should the packet go any further than the LOWPAN > itself. > > Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to > standardize it to mean that the UDP checksum is compressed, provided > that the headers and payload are equally or better protected than if the > checksum was used. > > Note: that would be bit 7 in my HC3 proposal. As a result, the complete > HC3 proposal could save us up to 4 additional bytes over RFC 4944 for a > UDP packet. > > What do you think? > > Pascal > _______________________________________________ > 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 Mar 3 10:11:50 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD2128C1CC; Mon, 3 Mar 2008 10:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=-2.465, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 iZSqXh+donrM; Mon, 3 Mar 2008 10:11:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AAE328C26A; Mon, 3 Mar 2008 10:11:45 -0800 (PST) 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 CBD3F28C10A for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 10:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 4940mU0PKQ9f for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 10:11:38 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 764B928C1CC for <6lowpan@ietf.org>; Mon, 3 Mar 2008 10:11:38 -0800 (PST) Received: from dnab4221d0.stanford.edu ([171.66.33.208]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1JWF8L-0007sb-9K; Mon, 03 Mar 2008 10:11:29 -0800 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05482ABE@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC05482ABE@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <4227B749-0F47-4ED6-BBEE-6EFF5F89252A@cs.stanford.edu> From: Philip Levis Date: Mon, 3 Mar 2008 10:11:29 -0800 To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.753) X-Scan-Signature: 3e263c829a24e9e508d860775f9d44fb Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing the UDP checksum 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 On Mar 3, 2008, at 5:25 AM, Pascal Thubert (pthubert) wrote: > Hi: > > Per RFC 4944: > "The UDP header's checksum field is not compressed and is > therefore > carried in full." > > The UDP checksum is not the only way to protect the IP pseudo header, > the UDP header and the payload. > ISA 100.11a is defining a transport-level security that does all this > and more, since it has a larger signature and provides mutual > authentication at the same time. > > Also, the ISA100.11a transport-level security is usually > hardware-assisted, so it requires little power or CPU time on the > field > device, whereas UDP checksum will be a costly CPU operation. > > So ISA100.11a is an example where the UDP checksum could and actually > should be compressed over the LoWPAN, leaving it up to be > reconstructed > by a backbone router should the packet go any further than the LOWPAN > itself. > > Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to > standardize it to mean that the UDP checksum is compressed, provided > that the headers and payload are equally or better protected than > if the > checksum was used. > > Note: that would be bit 7 in my HC3 proposal. As a result, the > complete > HC3 proposal could save us up to 4 additional bytes over RFC 4944 > for a > UDP packet. > > What do you think? I'm wary of all of these very aggressive compression approaches. They shave off a few bits, but add to complexity. One of the challenges in lowpans is that their protocols need to remain simple. This isn't to say that saving four bytes isn't great; rather, it's a tradeoff to protocol complexity (read: code size requirement), and that tradeoff shouldn't be ignored. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 3 12:10:51 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9EF3A6A40; Mon, 3 Mar 2008 12:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.819 X-Spam-Level: X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 25NxMrmcJc4e; Mon, 3 Mar 2008 12:10:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B0C3A6C06; Mon, 3 Mar 2008 12:10:47 -0800 (PST) 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 C8C3A3A6C37 for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 12:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 kVohdy5gtzqv for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 12:10:40 -0800 (PST) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 5AC0D3A6B93 for <6lowpan@ietf.org>; Mon, 3 Mar 2008 12:10:12 -0800 (PST) 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 m23K9WgN018830; Mon, 3 Mar 2008 13:09:33 -0700 (MST) From: Geoff Mulligan To: Philip Levis In-Reply-To: <4227B749-0F47-4ED6-BBEE-6EFF5F89252A@cs.stanford.edu> References: <7892795E1A87F04CADFCCF41FADD00FC05482ABE@xmb-ams-337.emea.cisco.com> <4227B749-0F47-4ED6-BBEE-6EFF5F89252A@cs.stanford.edu> Date: Mon, 03 Mar 2008 13:09:32 -0700 Message-Id: <1204574972.5609.28.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Cc: Jay Werb , 6lowpan <6lowpan@ietf.org>, enns@stanfordalumni.org Subject: Re: [6lowpan] Compressing the UDP checksum 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 While a agree with Phil, I think that Pascal does have an interesting suggestion in using one of reserved bits to indicated that the UDP checksum has been elided because the protocol being used provides protection of the same headers and data with at least the same strength. It would then be required by any bridge/router that is expanding the packet to calculate the UDP checksum and insert it. geoff On Mon, 2008-03-03 at 10:11 -0800, Philip Levis wrote: > On Mar 3, 2008, at 5:25 AM, Pascal Thubert (pthubert) wrote: > > > Hi: > > > > Per RFC 4944: > > "The UDP header's checksum field is not compressed and is > > therefore > > carried in full." > > > > The UDP checksum is not the only way to protect the IP pseudo header, > > the UDP header and the payload. > > ISA 100.11a is defining a transport-level security that does all this > > and more, since it has a larger signature and provides mutual > > authentication at the same time. > > > > Also, the ISA100.11a transport-level security is usually > > hardware-assisted, so it requires little power or CPU time on the > > field > > device, whereas UDP checksum will be a costly CPU operation. > > > > So ISA100.11a is an example where the UDP checksum could and actually > > should be compressed over the LoWPAN, leaving it up to be > > reconstructed > > by a backbone router should the packet go any further than the LOWPAN > > itself. > > > > Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to > > standardize it to mean that the UDP checksum is compressed, provided > > that the headers and payload are equally or better protected than > > if the > > checksum was used. > > > > Note: that would be bit 7 in my HC3 proposal. As a result, the > > complete > > HC3 proposal could save us up to 4 additional bytes over RFC 4944 > > for a > > UDP packet. > > > > What do you think? > > I'm wary of all of these very aggressive compression approaches. They > shave off a few bits, but add to complexity. One of the challenges in > lowpans is that their protocols need to remain simple. This isn't to > say that saving four bytes isn't great; rather, it's a tradeoff to > protocol complexity (read: code size requirement), and that tradeoff > shouldn't be ignored. > > Phil > _______________________________________________ > 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 Mar 3 13:44:24 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E50628C342; Mon, 3 Mar 2008 13:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 uqQDf1k-MMVE; Mon, 3 Mar 2008 13:44:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD90C3A6D9D; Mon, 3 Mar 2008 13:44:18 -0800 (PST) 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 DCB7D28C264 for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 13:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 GBeC77if-eYZ for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 13:44:12 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id CEC3728C35C for <6lowpan@ietf.org>; Mon, 3 Mar 2008 13:43:52 -0800 (PST) Received: from dnab4220a4.stanford.edu ([171.66.32.164]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1JWIRj-0008Ug-Rp; Mon, 03 Mar 2008 13:43:44 -0800 In-Reply-To: <1204574972.5609.28.camel@dellx1> References: <7892795E1A87F04CADFCCF41FADD00FC05482ABE@xmb-ams-337.emea.cisco.com> <4227B749-0F47-4ED6-BBEE-6EFF5F89252A@cs.stanford.edu> <1204574972.5609.28.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Levis Date: Mon, 3 Mar 2008 13:43:41 -0800 To: Geoff Mulligan X-Mailer: Apple Mail (2.753) X-Scan-Signature: b64bce576883819501cf77c9371f4538 Cc: Jay Werb , 6lowpan <6lowpan@ietf.org>, enns@stanfordalumni.org Subject: Re: [6lowpan] Compressing the UDP checksum 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 On Mar 3, 2008, at 12:09 PM, Geoff Mulligan wrote: > While a agree with Phil, I think that Pascal does have an interesting > suggestion in using one of reserved bits to indicated that the UDP > checksum has been elided because the protocol being used provides > protection of the same headers and data with at least the same > strength. > It would then be required by any bridge/router that is expanding the > packet to calculate the UDP checksum and insert it. Right. I'm not trying to argue that none of these optimizations are worth it. Rather, I'm just trying to point out that on paper you see their benefits but not their costs, and so we should keep the costs in mind. The UDP checksum versus message authentication codes does boil down to very different error resilience, however. I haven't seen experimental results for 15.4, but experimental results for 802.11 from MIT indicate that many bit errors are in short bursts[1], something CRCs are better at catching than cryptographic operations are. Not all check bits are equivalent in their error detection properties. Phil [1] Allen Miu et al., "Improving Loss Resilience with Multi-Radio Diversity in Wireless Networks," MOBICOM 2005. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 3 20:17:01 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28AA428C31D; Mon, 3 Mar 2008 20:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 eT3FGGDcYrMz; Mon, 3 Mar 2008 20:16:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD56C28C1A6; Mon, 3 Mar 2008 20:16:55 -0800 (PST) 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 63B013A69C8 for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 20:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 jBG9mHzXUvmQ for <6lowpan@core3.amsl.com>; Mon, 3 Mar 2008 20:16:49 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id EF24928C1A6 for <6lowpan@ietf.org>; Mon, 3 Mar 2008 20:16:48 -0800 (PST) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m244GWAJ010270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Mar 2008 20:16:37 -0800 (PST) Message-ID: <47CCCD6F.4040700@eecs.berkeley.edu> Date: Mon, 03 Mar 2008 20:17:51 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Colin O'Flynn" References: <200803021021.10955.coflynn@newae.com> In-Reply-To: <200803021021.10955.coflynn@newae.com> Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Syncronized Wake 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 Colin - there are basically 3 camps: * 15.4 beacons * some flavor of preamble sampling * time synchronized, e.g. SCP, Dozer, and TSMP If you wanted to do something really useful, you'd find an abstraction of their layer-two features and limitations that makes it easy for layer-3 and up to do useful things with them. ksjp Colin O'Flynn wrote: > Hello All, > > First a quick question - I found this list on the IETF site. I assume it's a > public list, you don't have to be a member of the working group to submit? > > Anyway, a few of us are working on doing a 6lowpan implementation. I was > looking at doing a 'syncronized wake' to help save power yet get reasonable > response times. By my calculations you could wake every few seconds and still > have an exceptional battery life (year+). > > Since some nodes might need to wake up more often than others they might have > different schedules, and obviously you'd need some sort of beacon to > syncronize. The idea is each node has a "wake schedule" that nearby nodes > know, and will be listening at that time. But any node can TX at almost any > time. > > I don't want to do GTS though, as nodes can talk at any time. But I need a way > to (a) sync nodes and (b) transmit wake schedule. > > So the question: would their be a standards-compliant way to do this? Or is it > worth it trying to be standards compliant at this stage? It would be easy > enough to make some simple protocol up to do this for testing. > > Warm Regards, > > -Colin O'Flynn > > PS: If you are interested: hardware is 8-bit AVR devices, using uIP for IPv6 > implementation. The gateway router is AVR32 device, which can route over > ethernet. > _______________________________________________ > 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 Mar 4 01:51:53 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71BD63A6F13; Tue, 4 Mar 2008 01:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 KjfimGb6YHfq; Tue, 4 Mar 2008 01:51:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDBF83A6F28; Tue, 4 Mar 2008 01:51:47 -0800 (PST) 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 152293A6F28 for <6lowpan@core3.amsl.com>; Tue, 4 Mar 2008 01:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 bYtNNIUfayEn for <6lowpan@core3.amsl.com>; Tue, 4 Mar 2008 01:51:46 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AC5D83A6F13 for <6lowpan@ietf.org>; Tue, 4 Mar 2008 01:51:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,443,1199660400"; d="scan'208";a="2442400" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Mar 2008 10:51:36 +0100 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 m249pZfm004987; Tue, 4 Mar 2008 10:51:35 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m249pPHE006416; Tue, 4 Mar 2008 09:51:25 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); Tue, 4 Mar 2008 10:51:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Mar 2008 10:50:54 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05482E8D@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Compressing the UDP checksum thread-index: Ach9d7+FqbkO16K/TDSFK3jjV4MdtwAWMskA From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Geoff Mulligan" X-OriginalArrivalTime: 04 Mar 2008 09:51:25.0102 (UTC) FILETIME=[4F41DCE0:01C87DDD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2296; t=1204624296; x=1205488296; 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]=20Compressing=20the=20UDP=20c hecksum |Sender:=20; bh=nY0n0npw7YYMq9S8eu0Sy3U26AR6kPByypdme9bL93g=; b=hTYRgc02RVa0v3Hs3K4yELyn4AiLKuY4HVpUh0HJA6g+6j9UM8xovJotMw yfQiuyEXOy0+8fi9GHSoS0T8RCJk9rwnNzY9hMbC7+yV2+1s/Ht9itCeJcWO NAh+rd8squ; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing the UDP checksum 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 Phil: For this thread and this forum, I'm not sure that an academic discussion on the exact properties of CRC vs. other MIC techniques are appropriate. But at the end of the day, I have trouble believing that 16 bits of CRC will do better than the 32 to 128 bits MIC used in ISA100.11a. In fact, I have a very vivid memory that 16 bits CRC can be dramatically unsufficient, but that's another story... What I really want on the specific topic of UDP checksum compression is reach acceptance in this group that it can be reasonable to compress the checksum over the 6LoWPAN network, with its logical consequence of assigning bit 3 in the HC-UDP header for that purpose; note that the bit is wasted anyway. So can we get consensus on this? Pascal >-----Original Message----- >From: Philip Levis [mailto:pal@cs.stanford.edu] >Sent: lundi 3 mars 2008 22:44 >To: Geoff Mulligan >Cc: Pascal Thubert (pthubert); enns@stanfordalumni.org; 6lowpan; Jay Werb >Subject: Re: [6lowpan] Compressing the UDP checksum > > >On Mar 3, 2008, at 12:09 PM, Geoff Mulligan wrote: > >> While a agree with Phil, I think that Pascal does have an interesting >> suggestion in using one of reserved bits to indicated that the UDP >> checksum has been elided because the protocol being used provides >> protection of the same headers and data with at least the same >> strength. >> It would then be required by any bridge/router that is expanding the >> packet to calculate the UDP checksum and insert it. > >Right. I'm not trying to argue that none of these optimizations are >worth it. Rather, I'm just trying to point out that on paper you see >their benefits but not their costs, and so we should keep the costs >in mind. > >The UDP checksum versus message authentication codes does boil down >to very different error resilience, however. I haven't seen >experimental results for 15.4, but experimental results for 802.11 >from MIT indicate that many bit errors are in short bursts[1], >something CRCs are better at catching than cryptographic operations >are. Not all check bits are equivalent in their error detection >properties. > >Phil > >[1] Allen Miu et al., "Improving Loss Resilience with Multi-Radio >Diversity in Wireless Networks," MOBICOM 2005. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 4 09:14:27 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823DE28C66D; Tue, 4 Mar 2008 09:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 T9itrHDKncJT; Tue, 4 Mar 2008 09:14:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F8028C781; Tue, 4 Mar 2008 09:09:31 -0800 (PST) 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 C9E2628C765 for <6lowpan@core3.amsl.com>; Tue, 4 Mar 2008 09:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 PUj61rK6i54P for <6lowpan@core3.amsl.com>; Tue, 4 Mar 2008 09:09:24 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 4951128C7B5 for <6lowpan@ietf.org>; Tue, 4 Mar 2008 09:05:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 19554A92FF; Tue, 4 Mar 2008 09:05:16 -0800 (PST) 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 PuuWt48fsApD; Tue, 4 Mar 2008 09:05:09 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 0959DA92FE; Tue, 4 Mar 2008 09:05:08 -0800 (PST) Message-ID: <47CD8140.1080407@archrock.com> Date: Tue, 04 Mar 2008 09:05:04 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC05482A60@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05482A60@xmb-ams-337.emea.cisco.com> Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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 Pascal, Thanks for sharing your thoughts. By assuming the first 5 bits in HC1 are '1', you're staking a claim that mesh-under link-local communication within a PAN is going to be most common case and the one we've "shot for". If link-local is all we focus on, then we are missing the point of IP. Frankly, I don't see much benefit of IP if communication is limited to the PAN. W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN nodes will communicate via route-over using routable addresses (e.g. ROLL). This brings us back to a broader topic of route-under vs. mesh-under. While both will probably exist for some time, it raises the question of whether 6LoWPAN implementations can support one or do they have to support both. W.r.t compressing Hop Limit, I don't quite understand why you're using a bit in HC3 to indicate where the message originated. If you're assuming link-local communication, then messages shouldn't be forwarded across links anyway. I do agree that there is work to do on compression and agree that there are cases where HC1 and HC2 are not sufficient. This is why I've been working, albeit slowly, on HC1g. -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Dear 6LoWPANers, > > Though HC1 and HC2 provide us with the capability to express any > combination of compression, the most expected (or at least shot for) > case does not lead to a better compression of the HC headers themselves. > > Seems that we could define an HC3 that would compress the pair of HC1 > and HC2 for that best case. My proposal for doing this would be to: > > - define a new dispatch > | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and > transport > > - define HC3 itself to: > > - implicitly say that the first 5 bits of HC1 are all ones > - carry HC1 bits 5 and 6 (Next Header) > - replace HC2 so bit 7 of HC1 is useless > - provide transport specific bits such as those defined for > HC-UDP, > then again assuming a predefined best case if room is missing > > An example of what the HC3 octet could be: > > bits 0 1 2-3 > 4-7 > > +------------------+-------------+-----------------+-------------------- > ---------------------+ > | reserved | reserved | Next Header | transport > specific control bits | > > +------------------+-------------+-----------------+-------------------- > ---------------------+ > > Next header: as defined in HC1, bits 5 and 6 > > transport specific control bits for UDP: > bit 4 echoes HC-UDP bit 0 on UDP source port > bit 5 echoes HC-UDP bit 1 on UDP destination port > bit 6 echoes HC-UDP bit 2 on UDP length > bit 7 is reserved > > What do you think? > > Pascal > _______________________________________________ > 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 Mar 4 09:21:34 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4563528C6E8; Tue, 4 Mar 2008 09:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.728 X-Spam-Level: X-Spam-Status: No, score=-0.728 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 BdEcQNLwe6pa; Tue, 4 Mar 2008 09:21:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F0828C742; Tue, 4 Mar 2008 09:19:20 -0800 (PST) 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 6123128C730 for <6lowpan@core3.amsl.com>; Tue, 4 Mar 2008 09:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 INxIe442Olyf for <6lowpan@core3.amsl.com>; Tue, 4 Mar 2008 09:19:18 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id B4EED28C784 for <6lowpan@ietf.org>; Tue, 4 Mar 2008 09:17:01 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 9607CA9345; Tue, 4 Mar 2008 09:16:52 -0800 (PST) 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 5S2v3GqZVKEW; Tue, 4 Mar 2008 09:16:45 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 2C6C0A92F3; Tue, 4 Mar 2008 09:16:45 -0800 (PST) Message-ID: <47CD83FA.1090409@archrock.com> Date: Tue, 04 Mar 2008 09:16:42 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC05482ABE@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05482ABE@xmb-ams-337.emea.cisco.com> Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing the UDP checksum 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 Yes, when Kris originally proposed this earlier, we came agreement that there are cases where the UDP checksum may be elided simply because it's matched or exceeded by other mechanisms. On the topic of security, I'm not so sure I would've chosen a method closer to TLS, by putting it on top of UDP. I would've preferred a method that is closer to IPsec, removing any binding to transport layer yet still remains end-to-end. While I agree that IPsec, as specified, is a little heavyweight. I think it's reasonable for us to mirror IPsec ESP, as in RFC4309, except using less bytes for IV and ICV. Key management, of course, is a different beast, and I'm not proposing to support IKE on 6LoWPAN nodes. -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi: > > Per RFC 4944: > "The UDP header's checksum field is not compressed and is therefore > carried in full." > > The UDP checksum is not the only way to protect the IP pseudo header, > the UDP header and the payload. > ISA 100.11a is defining a transport-level security that does all this > and more, since it has a larger signature and provides mutual > authentication at the same time. > > Also, the ISA100.11a transport-level security is usually > hardware-assisted, so it requires little power or CPU time on the field > device, whereas UDP checksum will be a costly CPU operation. > > So ISA100.11a is an example where the UDP checksum could and actually > should be compressed over the LoWPAN, leaving it up to be reconstructed > by a backbone router should the packet go any further than the LOWPAN > itself. > > Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to > standardize it to mean that the UDP checksum is compressed, provided > that the headers and payload are equally or better protected than if the > checksum was used. > > Note: that would be bit 7 in my HC3 proposal. As a result, the complete > HC3 proposal could save us up to 4 additional bytes over RFC 4944 for a > UDP packet. > > What do you think? > > Pascal > _______________________________________________ > 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 Mar 4 23:50:25 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F9928C4EC; Tue, 4 Mar 2008 23:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 mbAtIWyO0OIs; Tue, 4 Mar 2008 23:50:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25DD28C6B3; Tue, 4 Mar 2008 23:48:28 -0800 (PST) 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 58ACD28C6B3 for <6lowpan@core3.amsl.com>; Tue, 4 Mar 2008 23:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 T9Esbd8KsV7r for <6lowpan@core3.amsl.com>; Tue, 4 Mar 2008 23:48:25 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6B1983A68D3 for <6lowpan@ietf.org>; Tue, 4 Mar 2008 23:47:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,448,1199660400"; d="scan'208";a="2544887" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2008 08:47:18 +0100 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 m257lIqa010111; Wed, 5 Mar 2008 08:47:18 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m257krHW001139; Wed, 5 Mar 2008 07:47:17 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); Wed, 5 Mar 2008 08:47:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 08:46:39 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC054832F7@xmb-ams-337.emea.cisco.com> In-Reply-To: <47CD8140.1080407@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Compressing HC1 and HC2 into HC3 thread-index: Ach+GiD2MK1abvxmRaOWlhwq5mPCxgAdPg2Q From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 05 Mar 2008 07:47:14.0236 (UTC) FILETIME=[209BAFC0:01C87E95] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4562; t=1204703238; x=1205567238; 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]=20Compressing=20HC1=20and=20H C2=20into=20HC3 |Sender:=20; bh=/WiAfUZ24+QtfEKQHdb7aKuUJNXcVf02Goo7uRUv/fY=; b=smIhUhu0PR7pKi2U73JwND/yRiO6XUU0GAATxr1PnX0ulbFDp1C/X5QT9l OBAlEdh4MuVZ9ibdcUStRWTaFuMvPuiqohRMPHMyUtYVPByreQZLF46Y1uN1 woPMHImCFr; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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: You are assuming explicitly that I am assuming implicitly... mesh under... Hum. Please have a look at http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router -00.txt and it should be apparent that I'm not. In particular the backbone router is the device that will set and use the hop limit bit. So will all those interconnecting devices used in pseudowire, split bridges, IP Mobility, etc... if they are deployed in this space. What I'm really assuming is a gateway or an edge server on the link. It's there in most architectures that I know of at this point that's why I included it in the case we shoot for and saved 2 bits. Note that when the ULA and global addresses are used on top of link local, it makes sense that we define a mechanism to compress them as well. But this is not what HC3 is about. The goal of my initial proposal is illustrative, to foster this very discussion around the idea that we can shoot for a favorite case and make an HC3 out of HC1 and HC2 for that case. Now, if we as a group think that the GW assumption is not reasonable, then, fine, let us affect 2 bits in HC3 to indicate whether the addresses are compressed. What do the others think? Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mardi 4 mars 2008 18:05 >To: Pascal Thubert (pthubert) >Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 > > >Hi Pascal, > >Thanks for sharing your thoughts. > >By assuming the first 5 bits in HC1 are '1', you're staking a claim that >mesh-under link-local communication within a PAN is going to be most >common case and the one we've "shot for". If link-local is all we focus >on, then we are missing the point of IP. Frankly, I don't see much >benefit of IP if communication is limited to the PAN. > >W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN >nodes will communicate via route-over using routable addresses (e.g. >ROLL). This brings us back to a broader topic of route-under vs. >mesh-under. While both will probably exist for some time, it raises the >question of whether 6LoWPAN implementations can support one or do they >have to support both. > >W.r.t compressing Hop Limit, I don't quite understand why you're using a >bit in HC3 to indicate where the message originated. If you're assuming >link-local communication, then messages shouldn't be forwarded across >links anyway. > >I do agree that there is work to do on compression and agree that there >are cases where HC1 and HC2 are not sufficient. This is why I've been >working, albeit slowly, on HC1g. > >-- >Jonathan Hui > > >Pascal Thubert (pthubert) wrote: >> Dear 6LoWPANers, >> >> Though HC1 and HC2 provide us with the capability to express any >> combination of compression, the most expected (or at least shot for) >> case does not lead to a better compression of the HC headers themselves. >> >> Seems that we could define an HC3 that would compress the pair of HC1 >> and HC2 for that best case. My proposal for doing this would be to: >> >> - define a new dispatch >> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >> transport >> >> - define HC3 itself to: >> >> - implicitly say that the first 5 bits of HC1 are all ones >> - carry HC1 bits 5 and 6 (Next Header) >> - replace HC2 so bit 7 of HC1 is useless >> - provide transport specific bits such as those defined for >> HC-UDP, >> then again assuming a predefined best case if room is missing >> >> An example of what the HC3 octet could be: >> >> bits 0 1 2-3 >> 4-7 >> >> +------------------+-------------+-----------------+-------------------- >> ---------------------+ >> | reserved | reserved | Next Header | transport >> specific control bits | >> >> +------------------+-------------+-----------------+-------------------- >> ---------------------+ >> >> Next header: as defined in HC1, bits 5 and 6 >> >> transport specific control bits for UDP: >> bit 4 echoes HC-UDP bit 0 on UDP source port >> bit 5 echoes HC-UDP bit 1 on UDP destination port >> bit 6 echoes HC-UDP bit 2 on UDP length >> bit 7 is reserved >> >> What do you think? >> >> Pascal >> _______________________________________________ >> 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 Mar 4 23:59:27 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799023A6C01; Tue, 4 Mar 2008 23:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 mi96dYA0bs6o; Tue, 4 Mar 2008 23:59:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77BA43A6DF5; Tue, 4 Mar 2008 23:59:26 -0800 (PST) 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 DCB7E3A6BAA for <6lowpan@core3.amsl.com>; Tue, 4 Mar 2008 23:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 B2o+EiVTLtnU for <6lowpan@core3.amsl.com>; Tue, 4 Mar 2008 23:59:24 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 0475A3A6C01 for <6lowpan@ietf.org>; Tue, 4 Mar 2008 23:59:24 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 6BAFDA9347; Tue, 4 Mar 2008 23:59:14 -0800 (PST) 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 xTOOS-tFa+Cc; Tue, 4 Mar 2008 23:59:07 -0800 (PST) Received: from [192.168.1.104] (adsl-71-142-65-177.dsl.pltn13.pacbell.net [71.142.65.177]) by mail.sf.archrock.com (Postfix) with ESMTP id 5BE9BA9345; Tue, 4 Mar 2008 23:59:07 -0800 (PST) Message-ID: <47CE52C7.2060103@archrock.com> Date: Tue, 04 Mar 2008 23:59:03 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC054832F7@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC054832F7@xmb-ams-337.emea.cisco.com> Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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 your draft, you claim that 6LoWPAN nodes address each other and the backbone router using link-local addresses. If that occurs over multiple radio hops, that sounds like mesh under to me... In other words, you are assuming that an entire PAN functions as a single IP link (the IPv6 definition of a link). Am I missing something here? -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi Jonathan: > > You are assuming explicitly that I am assuming implicitly... mesh > under... Hum. > > Please have a look at > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router > -00.txt and it should be apparent that I'm not. In particular the > backbone router is the device that will set and use the hop limit bit. > So will all those interconnecting devices used in pseudowire, split > bridges, IP Mobility, etc... if they are deployed in this space. > > What I'm really assuming is a gateway or an edge server on the link. > It's there in most architectures that I know of at this point that's why > I included it in the case we shoot for and saved 2 bits. Note that when > the ULA and global addresses are used on top of link local, it makes > sense that we define a mechanism to compress them as well. But this is > not what HC3 is about. > > The goal of my initial proposal is illustrative, to foster this very > discussion around the idea that we can shoot for a favorite case and > make an HC3 out of HC1 and HC2 for that case. Now, if we as a group > think that the GW assumption is not reasonable, then, fine, let us > affect 2 bits in HC3 to indicate whether the addresses are compressed. > > What do the others think? > > Pascal >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: mardi 4 mars 2008 18:05 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >> >> >> Hi Pascal, >> >> Thanks for sharing your thoughts. >> >> By assuming the first 5 bits in HC1 are '1', you're staking a claim > that >> mesh-under link-local communication within a PAN is going to be most >> common case and the one we've "shot for". If link-local is all we focus >> on, then we are missing the point of IP. Frankly, I don't see much >> benefit of IP if communication is limited to the PAN. >> >> W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN >> nodes will communicate via route-over using routable addresses (e.g. >> ROLL). This brings us back to a broader topic of route-under vs. >> mesh-under. While both will probably exist for some time, it raises the >> question of whether 6LoWPAN implementations can support one or do they >> have to support both. >> >> W.r.t compressing Hop Limit, I don't quite understand why you're using > a >> bit in HC3 to indicate where the message originated. If you're assuming >> link-local communication, then messages shouldn't be forwarded across >> links anyway. >> >> I do agree that there is work to do on compression and agree that there >> are cases where HC1 and HC2 are not sufficient. This is why I've been >> working, albeit slowly, on HC1g. >> >> -- >> Jonathan Hui >> >> >> Pascal Thubert (pthubert) wrote: >>> Dear 6LoWPANers, >>> >>> Though HC1 and HC2 provide us with the capability to express any >>> combination of compression, the most expected (or at least shot for) >>> case does not lead to a better compression of the HC headers > themselves. >>> Seems that we could define an HC3 that would compress the pair of HC1 >>> and HC2 for that best case. My proposal for doing this would be to: >>> >>> - define a new dispatch >>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>> transport >>> >>> - define HC3 itself to: >>> >>> - implicitly say that the first 5 bits of HC1 are all ones >>> - carry HC1 bits 5 and 6 (Next Header) >>> - replace HC2 so bit 7 of HC1 is useless >>> - provide transport specific bits such as those defined for >>> HC-UDP, >>> then again assuming a predefined best case if room is missing >>> >>> An example of what the HC3 octet could be: >>> >>> bits 0 1 2-3 >>> 4-7 >>> >>> > +------------------+-------------+-----------------+-------------------- >>> ---------------------+ >>> | reserved | reserved | Next Header | > transport >>> specific control bits | >>> >>> > +------------------+-------------+-----------------+-------------------- >>> ---------------------+ >>> >>> Next header: as defined in HC1, bits 5 and 6 >>> >>> transport specific control bits for UDP: >>> bit 4 echoes HC-UDP bit 0 on UDP source port >>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>> bit 6 echoes HC-UDP bit 2 on UDP length >>> bit 7 is reserved >>> >>> What do you think? >>> >>> Pascal >>> _______________________________________________ >>> 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 Mar 5 00:29:44 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 387E428C46F; Wed, 5 Mar 2008 00:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.296 X-Spam-Level: X-Spam-Status: No, score=-0.296 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 bZUQ-oqT6asH; Wed, 5 Mar 2008 00:29:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD0328C6BD; Wed, 5 Mar 2008 00:29:38 -0800 (PST) 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 F369928C6A5 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 00:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 oFEEV-phl+cV for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 00:29:35 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id E4BD728C6F0 for <6lowpan@ietf.org>; Wed, 5 Mar 2008 00:28:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 65B8DA933D; Wed, 5 Mar 2008 00:28:20 -0800 (PST) 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 ghe5IY8+vDgM; Wed, 5 Mar 2008 00:28:13 -0800 (PST) Received: from [192.168.1.104] (adsl-71-142-65-177.dsl.pltn13.pacbell.net [71.142.65.177]) by mail.sf.archrock.com (Postfix) with ESMTP id 260EDA933C; Wed, 5 Mar 2008 00:28:13 -0800 (PST) Message-ID: <47CE5996.7080805@archrock.com> Date: Wed, 05 Mar 2008 00:28:06 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC054832F7@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC054832F7@xmb-ams-337.emea.cisco.com> Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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 Regarding the GW assumption on the link, I think we need to take a step back for a second. While it is true that most architectures up until this point follow this assumption, most architectures that I know of haven't been built using IP. ZigBee nodes, for example, only communicate with ZigBee nodes at every hop and there isn't any effort to do internetworking. But now that we actually have IP, we are no longer constrained to a single link technology. Rather, nodes can communicate with each other, directly using 802.15.4, or over other technologies such as WiFi, Ethernet, GPRS, etc. This really opens up the network architecture possibilities, and there are many cases where adding these additional links are desirable. I know that ISA's proposed backbone routers provide this functionality, but I'd rather support such networks at the IP layer, rather than abstracting a combination of link technologies as single IP link and defining any new machinery to do so. BTW it's great that we're having this discussion. It is long overdue. -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi Jonathan: > > You are assuming explicitly that I am assuming implicitly... mesh > under... Hum. > > Please have a look at > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router > -00.txt and it should be apparent that I'm not. In particular the > backbone router is the device that will set and use the hop limit bit. > So will all those interconnecting devices used in pseudowire, split > bridges, IP Mobility, etc... if they are deployed in this space. > > What I'm really assuming is a gateway or an edge server on the link. > It's there in most architectures that I know of at this point that's why > I included it in the case we shoot for and saved 2 bits. Note that when > the ULA and global addresses are used on top of link local, it makes > sense that we define a mechanism to compress them as well. But this is > not what HC3 is about. > > The goal of my initial proposal is illustrative, to foster this very > discussion around the idea that we can shoot for a favorite case and > make an HC3 out of HC1 and HC2 for that case. Now, if we as a group > think that the GW assumption is not reasonable, then, fine, let us > affect 2 bits in HC3 to indicate whether the addresses are compressed. > > What do the others think? > > Pascal >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: mardi 4 mars 2008 18:05 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >> >> >> Hi Pascal, >> >> Thanks for sharing your thoughts. >> >> By assuming the first 5 bits in HC1 are '1', you're staking a claim > that >> mesh-under link-local communication within a PAN is going to be most >> common case and the one we've "shot for". If link-local is all we focus >> on, then we are missing the point of IP. Frankly, I don't see much >> benefit of IP if communication is limited to the PAN. >> >> W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN >> nodes will communicate via route-over using routable addresses (e.g. >> ROLL). This brings us back to a broader topic of route-under vs. >> mesh-under. While both will probably exist for some time, it raises the >> question of whether 6LoWPAN implementations can support one or do they >> have to support both. >> >> W.r.t compressing Hop Limit, I don't quite understand why you're using > a >> bit in HC3 to indicate where the message originated. If you're assuming >> link-local communication, then messages shouldn't be forwarded across >> links anyway. >> >> I do agree that there is work to do on compression and agree that there >> are cases where HC1 and HC2 are not sufficient. This is why I've been >> working, albeit slowly, on HC1g. >> >> -- >> Jonathan Hui >> >> >> Pascal Thubert (pthubert) wrote: >>> Dear 6LoWPANers, >>> >>> Though HC1 and HC2 provide us with the capability to express any >>> combination of compression, the most expected (or at least shot for) >>> case does not lead to a better compression of the HC headers > themselves. >>> Seems that we could define an HC3 that would compress the pair of HC1 >>> and HC2 for that best case. My proposal for doing this would be to: >>> >>> - define a new dispatch >>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>> transport >>> >>> - define HC3 itself to: >>> >>> - implicitly say that the first 5 bits of HC1 are all ones >>> - carry HC1 bits 5 and 6 (Next Header) >>> - replace HC2 so bit 7 of HC1 is useless >>> - provide transport specific bits such as those defined for >>> HC-UDP, >>> then again assuming a predefined best case if room is missing >>> >>> An example of what the HC3 octet could be: >>> >>> bits 0 1 2-3 >>> 4-7 >>> >>> > +------------------+-------------+-----------------+-------------------- >>> ---------------------+ >>> | reserved | reserved | Next Header | > transport >>> specific control bits | >>> >>> > +------------------+-------------+-----------------+-------------------- >>> ---------------------+ >>> >>> Next header: as defined in HC1, bits 5 and 6 >>> >>> transport specific control bits for UDP: >>> bit 4 echoes HC-UDP bit 0 on UDP source port >>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>> bit 6 echoes HC-UDP bit 2 on UDP length >>> bit 7 is reserved >>> >>> What do you think? >>> >>> Pascal >>> _______________________________________________ >>> 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 Mar 5 04:08:30 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624CD28C541; Wed, 5 Mar 2008 04:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.937 X-Spam-Level: X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 XS2cPolFMTTQ; Wed, 5 Mar 2008 04:08:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F50728C150; Wed, 5 Mar 2008 04:08:28 -0800 (PST) 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 2E2673A6865 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 04:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 U5bRlY42jKXI for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 04:08:24 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 473893A68D9 for <6lowpan@ietf.org>; Wed, 5 Mar 2008 04:07:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,450,1199660400"; d="scan'208";a="2582347" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2008 13:07:17 +0100 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 m25C7HMq013346; Wed, 5 Mar 2008 13:07:17 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m25C72HG021307; Wed, 5 Mar 2008 12:07:12 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); Wed, 5 Mar 2008 13:07:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 13:06:34 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC054834A3@xmb-ams-337.emea.cisco.com> In-Reply-To: <47CE52C7.2060103@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mesh Under vs. ND proxy (was: Compressing HC1 and HC2 into HC3) thread-index: Ach+lwNVkv14MeLGTj264/Hm+rioBAAHXMKg From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 05 Mar 2008 12:07:02.0194 (UTC) FILETIME=[6BC15120:01C87EB9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7468; t=1204718837; x=1205582837; 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:=20Mesh=20Under=20vs.=20ND=20proxy=20(was=3A=20Com pressing=20HC1=20and=20HC2=20into=20HC3) |Sender:=20; bh=r4DkZhgbkWfL7dGRwaUKueH6EpwXmZP6GD9N1dgVXOc=; b=bmDbCk5NErjm68NIxb4oJvbz8W30ECgkC/AwQoRGYPX7zeqn5+GQe074YZ NJE/7z10Ji6efvcD4THh4TRvMYduyTB7tsxWiYvVJC99Au0jUqgpXZDf7IL0 hReBx3BUKb; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: [6lowpan] Mesh Under vs. ND proxy (was: Compressing HC1 and HC2 into HC3) 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: The Backbone Router (BbR) draft makes no assumption that I am aware of on whether there is or not more than one radio hop over a LoWPAN; both cases are supported. Now I think it's fair to make a distinction between radio hops over the LowPAN and hops over the backbone: - First, the backbone is not supposed to be of the same technology as the LoWPAN. A backbone router is thus expected to expand the 6LoWPAN compressed packets and reassemble the fragments. The backbone can a simple ethernet cable, but it might as well be a mesh of tunnels over a WAN. The packet might be delivered to an IPv6 node sitting on the backbone, or be forwarded across a destination LoWPAN via another backbone router. Because the destination LoWPAN might be different in nature from the source LoWPAN, uncompressed IP is the esperanto over the backbone. - Second, the routing protocol is somewhat different. The backbone router uses proxy ND techniques to represent its field devices over the link abstraction that is the backbone and make routing decision to forward over the LoWPAN vs. over the backbone; and the types of routing that sustains the backbone itself can be virtually anything from spanning tree to BGP. The goal for this draft is to federate multiple small LoWPANs into one larger IPv6 link over a backbone of any sort that is also part of the link. The single link requirement matches the current applications that I know of and enables a field device to move from one BrB to another one on the same link while retaining transparently its address and active connections. The backbone router is the router that enables that LoWPAN interconnection, and proxy ND is the technique that is proposed to achieve the goal above. Other techniques such as NETLMM/proxy MIP were discussed but seemed overkill for the desired result and the constraints of the LoWPAN. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mercredi 5 mars 2008 08:59 >To: Pascal Thubert (pthubert) >Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 > > >In your draft, you claim that 6LoWPAN nodes address each other and the >backbone router using link-local addresses. If that occurs over multiple >radio hops, that sounds like mesh under to me... In other words, you are >assuming that an entire PAN functions as a single IP link (the IPv6 >definition of a link). Am I missing something here? > >-- >Jonathan Hui > > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >> You are assuming explicitly that I am assuming implicitly... mesh >> under... Hum. >> >> Please have a look at >> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >> -00.txt and it should be apparent that I'm not. In particular the >> backbone router is the device that will set and use the hop limit bit. >> So will all those interconnecting devices used in pseudowire, split >> bridges, IP Mobility, etc... if they are deployed in this space. >> >> What I'm really assuming is a gateway or an edge server on the link. >> It's there in most architectures that I know of at this point that's why >> I included it in the case we shoot for and saved 2 bits. Note that when >> the ULA and global addresses are used on top of link local, it makes >> sense that we define a mechanism to compress them as well. But this is >> not what HC3 is about. >> >> The goal of my initial proposal is illustrative, to foster this very >> discussion around the idea that we can shoot for a favorite case and >> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >> think that the GW assumption is not reasonable, then, fine, let us >> affect 2 bits in HC3 to indicate whether the addresses are compressed. >> >> What do the others think? >> >> Pascal >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: mardi 4 mars 2008 18:05 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>> >>> >>> Hi Pascal, >>> >>> Thanks for sharing your thoughts. >>> >>> By assuming the first 5 bits in HC1 are '1', you're staking a claim >> that >>> mesh-under link-local communication within a PAN is going to be most >>> common case and the one we've "shot for". If link-local is all we focus >>> on, then we are missing the point of IP. Frankly, I don't see much >>> benefit of IP if communication is limited to the PAN. >>> >>> W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN >>> nodes will communicate via route-over using routable addresses (e.g. >>> ROLL). This brings us back to a broader topic of route-under vs. >>> mesh-under. While both will probably exist for some time, it raises the >>> question of whether 6LoWPAN implementations can support one or do they >>> have to support both. >>> >>> W.r.t compressing Hop Limit, I don't quite understand why you're using >> a >>> bit in HC3 to indicate where the message originated. If you're assuming >>> link-local communication, then messages shouldn't be forwarded across >>> links anyway. >>> >>> I do agree that there is work to do on compression and agree that there >>> are cases where HC1 and HC2 are not sufficient. This is why I've been >>> working, albeit slowly, on HC1g. >>> >>> -- >>> Jonathan Hui >>> >>> >>> Pascal Thubert (pthubert) wrote: >>>> Dear 6LoWPANers, >>>> >>>> Though HC1 and HC2 provide us with the capability to express any >>>> combination of compression, the most expected (or at least shot for) >>>> case does not lead to a better compression of the HC headers >> themselves. >>>> Seems that we could define an HC3 that would compress the pair of HC1 >>>> and HC2 for that best case. My proposal for doing this would be to: >>>> >>>> - define a new dispatch >>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>>> transport >>>> >>>> - define HC3 itself to: >>>> >>>> - implicitly say that the first 5 bits of HC1 are all ones >>>> - carry HC1 bits 5 and 6 (Next Header) >>>> - replace HC2 so bit 7 of HC1 is useless >>>> - provide transport specific bits such as those defined for >>>> HC-UDP, >>>> then again assuming a predefined best case if room is missing >>>> >>>> An example of what the HC3 octet could be: >>>> >>>> bits 0 1 2-3 >>>> 4-7 >>>> >>>> >> +------------------+-------------+-----------------+-------------------- >>>> ---------------------+ >>>> | reserved | reserved | Next Header | >> transport >>>> specific control bits | >>>> >>>> >> +------------------+-------------+-----------------+-------------------- >>>> ---------------------+ >>>> >>>> Next header: as defined in HC1, bits 5 and 6 >>>> >>>> transport specific control bits for UDP: >>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>> bit 7 is reserved >>>> >>>> What do you think? >>>> >>>> Pascal >>>> _______________________________________________ >>>> 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 Mar 5 04:20:41 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEBEC3A68FC; Wed, 5 Mar 2008 04:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.912 X-Spam-Level: X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 YlEx-nEMdreH; Wed, 5 Mar 2008 04:20:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B241228C228; Wed, 5 Mar 2008 04:20:40 -0800 (PST) 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 18EE128C2F7 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 04:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 B1JrNPdub8rz for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 04:20:38 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 563DA3A68D9 for <6lowpan@ietf.org>; Wed, 5 Mar 2008 04:20:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,450,1199660400"; d="scan'208";a="2584042" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2008 13:20:28 +0100 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 m25CKSix017575; Wed, 5 Mar 2008 13:20:28 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m25CKHHE026155; Wed, 5 Mar 2008 12:20:28 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); Wed, 5 Mar 2008 13:20:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 13:15:55 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC054834BC@xmb-ams-337.emea.cisco.com> In-Reply-To: <47CE5996.7080805@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Compressing HC1 and HC2 into HC3 thread-index: Ach+muTJPeKmeFb1SFaF9wWsQTSnqwAHuxJQ From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 05 Mar 2008 12:20:23.0684 (UTC) FILETIME=[497AFC40:01C87EBB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6847; t=1204719628; x=1205583628; 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]=20Compressing=20HC1=20and=20H C2=20into=20HC3 |Sender:=20; bh=2s+YnDQSEAwEQHA5edv4eXle2sSimxDV8XN3YYZebvw=; b=cnDFmGNec/ybnwGEi13vRW4IuylrPOw3FQPYuLqPuNcprn7rqIhL0sikpY BbxOq8VSEHzkI2vsaK7xrXhxn+ur3qBv0yeSzX2rafsrWSBZhhmU+QvOgxbd ijWfbisCAp; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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 agree it's great we are having this discussion :) Multiple thread could spawn from it because there are multiple topic. And some of this might belong to ROLL as you pointed out earlier. I'd wish to keep this thread for its original question on whether it is desirable, in the context of what we already have, to further compress HC1 and HC2 into a single HC3. For that specific thread, I retain that you do not oppose but that you vote for retaining some information on whether the addresses are elided or not. Is that fair? Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mercredi 5 mars 2008 09:28 >To: Pascal Thubert (pthubert) >Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 > > >Regarding the GW assumption on the link, I think we need to take a step >back for a second. While it is true that most architectures up until >this point follow this assumption, most architectures that I know of >haven't been built using IP. ZigBee nodes, for example, only communicate >with ZigBee nodes at every hop and there isn't any effort to do >internetworking. > >But now that we actually have IP, we are no longer constrained to a >single link technology. Rather, nodes can communicate with each other, >directly using 802.15.4, or over other technologies such as WiFi, >Ethernet, GPRS, etc. This really opens up the network architecture >possibilities, and there are many cases where adding these additional >links are desirable. I know that ISA's proposed backbone routers provide >this functionality, but I'd rather support such networks at the IP >layer, rather than abstracting a combination of link technologies as >single IP link and defining any new machinery to do so. > >BTW it's great that we're having this discussion. It is long overdue. > >-- >Jonathan Hui > > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >> You are assuming explicitly that I am assuming implicitly... mesh >> under... Hum. >> >> Please have a look at >> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >> -00.txt and it should be apparent that I'm not. In particular the >> backbone router is the device that will set and use the hop limit bit. >> So will all those interconnecting devices used in pseudowire, split >> bridges, IP Mobility, etc... if they are deployed in this space. >> >> What I'm really assuming is a gateway or an edge server on the link. >> It's there in most architectures that I know of at this point that's why >> I included it in the case we shoot for and saved 2 bits. Note that when >> the ULA and global addresses are used on top of link local, it makes >> sense that we define a mechanism to compress them as well. But this is >> not what HC3 is about. >> >> The goal of my initial proposal is illustrative, to foster this very >> discussion around the idea that we can shoot for a favorite case and >> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >> think that the GW assumption is not reasonable, then, fine, let us >> affect 2 bits in HC3 to indicate whether the addresses are compressed. >> >> What do the others think? >> >> Pascal >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: mardi 4 mars 2008 18:05 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>> >>> >>> Hi Pascal, >>> >>> Thanks for sharing your thoughts. >>> >>> By assuming the first 5 bits in HC1 are '1', you're staking a claim >> that >>> mesh-under link-local communication within a PAN is going to be most >>> common case and the one we've "shot for". If link-local is all we focus >>> on, then we are missing the point of IP. Frankly, I don't see much >>> benefit of IP if communication is limited to the PAN. >>> >>> W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN >>> nodes will communicate via route-over using routable addresses (e.g. >>> ROLL). This brings us back to a broader topic of route-under vs. >>> mesh-under. While both will probably exist for some time, it raises the >>> question of whether 6LoWPAN implementations can support one or do they >>> have to support both. >>> >>> W.r.t compressing Hop Limit, I don't quite understand why you're using >> a >>> bit in HC3 to indicate where the message originated. If you're assuming >>> link-local communication, then messages shouldn't be forwarded across >>> links anyway. >>> >>> I do agree that there is work to do on compression and agree that there >>> are cases where HC1 and HC2 are not sufficient. This is why I've been >>> working, albeit slowly, on HC1g. >>> >>> -- >>> Jonathan Hui >>> >>> >>> Pascal Thubert (pthubert) wrote: >>>> Dear 6LoWPANers, >>>> >>>> Though HC1 and HC2 provide us with the capability to express any >>>> combination of compression, the most expected (or at least shot for) >>>> case does not lead to a better compression of the HC headers >> themselves. >>>> Seems that we could define an HC3 that would compress the pair of HC1 >>>> and HC2 for that best case. My proposal for doing this would be to: >>>> >>>> - define a new dispatch >>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>>> transport >>>> >>>> - define HC3 itself to: >>>> >>>> - implicitly say that the first 5 bits of HC1 are all ones >>>> - carry HC1 bits 5 and 6 (Next Header) >>>> - replace HC2 so bit 7 of HC1 is useless >>>> - provide transport specific bits such as those defined for >>>> HC-UDP, >>>> then again assuming a predefined best case if room is missing >>>> >>>> An example of what the HC3 octet could be: >>>> >>>> bits 0 1 2-3 >>>> 4-7 >>>> >>>> >> +------------------+-------------+-----------------+-------------------- >>>> ---------------------+ >>>> | reserved | reserved | Next Header | >> transport >>>> specific control bits | >>>> >>>> >> +------------------+-------------+-----------------+-------------------- >>>> ---------------------+ >>>> >>>> Next header: as defined in HC1, bits 5 and 6 >>>> >>>> transport specific control bits for UDP: >>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>> bit 7 is reserved >>>> >>>> What do you think? >>>> >>>> Pascal >>>> _______________________________________________ >>>> 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 Mar 5 04:22:10 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA8D3A6CFE; Wed, 5 Mar 2008 04:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 RDMxHUQHEZ3X; Wed, 5 Mar 2008 04:22:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2991728C0D7; Wed, 5 Mar 2008 04:22:09 -0800 (PST) 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 8B30F3A6D21 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 04:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 5AcJmum6Fx-g for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 04:22:03 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D65A73A6CFE for <6lowpan@ietf.org>; Wed, 5 Mar 2008 04:22:02 -0800 (PST) Received: from [10.0.1.2] (oul119-35.netplaza.fi [80.75.105.35]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m25CLkq6027654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2008 14:21:46 +0200 Message-ID: <47CE905A.6090802@sensinode.com> Date: Wed, 05 Mar 2008 14:21:46 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC054832F7@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC054832F7@xmb-ams-337.emea.cisco.com> Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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 Very nice discussion. I see the logic in going after a more aggressive HC3 compression for use within the 6lowpan network. It also would incorporate elided CRC which I would also like to see it for local use. So far from my implementation and use experience HC3 would cover 95% of our use of 6lowpan. Why wouldn't the HC3 proposal work with both mesh under or route over? e.g. MANET routing protocols are also mainly using flat IP addressing within the MANET. So in reality route-over would likely use the MAC address of the interface and elide the IPv6 address when using 6lowpan at least, just as in 6lowpan "mesh under" as long as the destination address is in the same subnet. It would be quite easy to switch to HC1+HC2 or HC1g in the case that you detect that the destination address has a different non link-local prefix. Please correct me if I am wrong here... Of course both HC3 and HC1g would be needed in such networks, as HC1g allows us to communicate outside the 6lowpan network with minimal overhead. So I am in favor of both. Of course there is the question if we would have a place for HC3 in the new charter? - Zach Pascal Thubert (pthubert) wrote: > Hi Jonathan: > > You are assuming explicitly that I am assuming implicitly... mesh > under... Hum. > > Please have a look at > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router > -00.txt and it should be apparent that I'm not. In particular the > backbone router is the device that will set and use the hop limit bit. > So will all those interconnecting devices used in pseudowire, split > bridges, IP Mobility, etc... if they are deployed in this space. > > What I'm really assuming is a gateway or an edge server on the link. > It's there in most architectures that I know of at this point that's why > I included it in the case we shoot for and saved 2 bits. Note that when > the ULA and global addresses are used on top of link local, it makes > sense that we define a mechanism to compress them as well. But this is > not what HC3 is about. > > The goal of my initial proposal is illustrative, to foster this very > discussion around the idea that we can shoot for a favorite case and > make an HC3 out of HC1 and HC2 for that case. Now, if we as a group > think that the GW assumption is not reasonable, then, fine, let us > affect 2 bits in HC3 to indicate whether the addresses are compressed. > > What do the others think? > > Pascal >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: mardi 4 mars 2008 18:05 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >> >> >> Hi Pascal, >> >> Thanks for sharing your thoughts. >> >> By assuming the first 5 bits in HC1 are '1', you're staking a claim > that >> mesh-under link-local communication within a PAN is going to be most >> common case and the one we've "shot for". If link-local is all we focus >> on, then we are missing the point of IP. Frankly, I don't see much >> benefit of IP if communication is limited to the PAN. >> >> W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN >> nodes will communicate via route-over using routable addresses (e.g. >> ROLL). This brings us back to a broader topic of route-under vs. >> mesh-under. While both will probably exist for some time, it raises the >> question of whether 6LoWPAN implementations can support one or do they >> have to support both. >> >> W.r.t compressing Hop Limit, I don't quite understand why you're using > a >> bit in HC3 to indicate where the message originated. If you're assuming >> link-local communication, then messages shouldn't be forwarded across >> links anyway. >> >> I do agree that there is work to do on compression and agree that there >> are cases where HC1 and HC2 are not sufficient. This is why I've been >> working, albeit slowly, on HC1g. >> >> -- >> Jonathan Hui >> >> >> Pascal Thubert (pthubert) wrote: >>> Dear 6LoWPANers, >>> >>> Though HC1 and HC2 provide us with the capability to express any >>> combination of compression, the most expected (or at least shot for) >>> case does not lead to a better compression of the HC headers > themselves. >>> Seems that we could define an HC3 that would compress the pair of HC1 >>> and HC2 for that best case. My proposal for doing this would be to: >>> >>> - define a new dispatch >>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>> transport >>> >>> - define HC3 itself to: >>> >>> - implicitly say that the first 5 bits of HC1 are all ones >>> - carry HC1 bits 5 and 6 (Next Header) >>> - replace HC2 so bit 7 of HC1 is useless >>> - provide transport specific bits such as those defined for >>> HC-UDP, >>> then again assuming a predefined best case if room is missing >>> >>> An example of what the HC3 octet could be: >>> >>> bits 0 1 2-3 >>> 4-7 >>> >>> > +------------------+-------------+-----------------+-------------------- >>> ---------------------+ >>> | reserved | reserved | Next Header | > transport >>> specific control bits | >>> >>> > +------------------+-------------+-----------------+-------------------- >>> ---------------------+ >>> >>> Next header: as defined in HC1, bits 5 and 6 >>> >>> transport specific control bits for UDP: >>> bit 4 echoes HC-UDP bit 0 on UDP source port >>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>> bit 6 echoes HC-UDP bit 2 on UDP length >>> bit 7 is reserved >>> >>> What do you think? >>> >>> Pascal >>> _______________________________________________ >>> 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 | CTO | +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 Wed Mar 5 04:43:38 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04DCC3A6E46; Wed, 5 Mar 2008 04:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 PxhAsIIRoIR7; Wed, 5 Mar 2008 04:43:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487F328C1D3; Wed, 5 Mar 2008 04:43:34 -0800 (PST) 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 808B628C484 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 04:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 mu+b1W4Gi93B for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 04:43:30 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5C5FF28C71F for <6lowpan@ietf.org>; Wed, 5 Mar 2008 04:43:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,450,1199660400"; d="scan'208";a="2587137" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2008 13:42:51 +0100 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 m25CgpqX017598; Wed, 5 Mar 2008 13:42:51 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m25CgbHI005362; Wed, 5 Mar 2008 12:42:49 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); Wed, 5 Mar 2008 13:42:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 13:42:10 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC054834E7@xmb-ams-337.emea.cisco.com> In-Reply-To: <47CE5996.7080805@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The ISA backbone router (was: Compressing HC1 and HC2 into HC3) thread-index: Ach+muTJPeKmeFb1SFaF9wWsQTSnqwAIKjzA From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 05 Mar 2008 12:42:37.0840 (UTC) FILETIME=[64B30900:01C87EBE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7728; t=1204720971; x=1205584971; 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:=20The=20ISA=20backbone=20router=20(was=3A=20Compr essing=20HC1=20and=20HC2=20into=20HC3) |Sender:=20; bh=Ct7GdjIPqSDC/IYz+Ej2SdtH4Q6mqdPYCv6Vya9NRIM=; b=RJCSWHp6AwLKFPzR3Ef6OYnx2qsbWG1xXWzuLVY+F787nj+QT+Pcc0zWpp 0E791eio9ug3NSCmeHUaRKeJgMKTHYDIh5ry2fdkC8klW9ob6yV8krdU3qKp pXEzBm5UbH; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: [6lowpan] The ISA backbone router (was: Compressing HC1 and HC2 into HC3) 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 do not see the backbone router as an ISA thing. I see that ISA requires a functionality and that some people at 6LoWPAN (that obviously includes me but I hope there's more) are willing to work on an IETF solution to help them out. So the requirement is ISA100 but the solution draft is 6LoWPAN for sure. I'm very positive with ROLL and I'll help as much as I can there; I agree with all your points about architecture. Now, the problems to be solved are quite complex and that's certainly quite a lot of work ahead to get all the basic ingredients in place to propose a global solution. Just the compression of the addresses across multiple hops will be an interesting challenge. Will we use 2 bytes addresses as labels? Centralize routing? Now if we consider the time frames, the specs that we have available (that's mostly RFC 4944) and the cases that must be solved in the near term, then the single link with a gateway is a reasonable first step to crystallize what we have - though I'm 100% with you that it is certainly not the end of the way. So I'm looking for an HC3 that is an immediate improvement on HC1 and 2 as we know them for a very practical application that we have already in front of us waiting. Thus the proposals that you have seen. I do not see that as a threat for the future end-to-end IPv6 which will definitely come in time. Do we seem to agree after all? Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mercredi 5 mars 2008 09:28 >To: Pascal Thubert (pthubert) >Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 > > >Regarding the GW assumption on the link, I think we need to take a step >back for a second. While it is true that most architectures up until >this point follow this assumption, most architectures that I know of >haven't been built using IP. ZigBee nodes, for example, only communicate >with ZigBee nodes at every hop and there isn't any effort to do >internetworking. > >But now that we actually have IP, we are no longer constrained to a >single link technology. Rather, nodes can communicate with each other, >directly using 802.15.4, or over other technologies such as WiFi, >Ethernet, GPRS, etc. This really opens up the network architecture >possibilities, and there are many cases where adding these additional >links are desirable. I know that ISA's proposed backbone routers provide >this functionality, but I'd rather support such networks at the IP >layer, rather than abstracting a combination of link technologies as >single IP link and defining any new machinery to do so. > >BTW it's great that we're having this discussion. It is long overdue. > >-- >Jonathan Hui > > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >> You are assuming explicitly that I am assuming implicitly... mesh >> under... Hum. >> >> Please have a look at >> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >> -00.txt and it should be apparent that I'm not. In particular the >> backbone router is the device that will set and use the hop limit bit. >> So will all those interconnecting devices used in pseudowire, split >> bridges, IP Mobility, etc... if they are deployed in this space. >> >> What I'm really assuming is a gateway or an edge server on the link. >> It's there in most architectures that I know of at this point that's why >> I included it in the case we shoot for and saved 2 bits. Note that when >> the ULA and global addresses are used on top of link local, it makes >> sense that we define a mechanism to compress them as well. But this is >> not what HC3 is about. >> >> The goal of my initial proposal is illustrative, to foster this very >> discussion around the idea that we can shoot for a favorite case and >> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >> think that the GW assumption is not reasonable, then, fine, let us >> affect 2 bits in HC3 to indicate whether the addresses are compressed. >> >> What do the others think? >> >> Pascal >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: mardi 4 mars 2008 18:05 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>> >>> >>> Hi Pascal, >>> >>> Thanks for sharing your thoughts. >>> >>> By assuming the first 5 bits in HC1 are '1', you're staking a claim >> that >>> mesh-under link-local communication within a PAN is going to be most >>> common case and the one we've "shot for". If link-local is all we focus >>> on, then we are missing the point of IP. Frankly, I don't see much >>> benefit of IP if communication is limited to the PAN. >>> >>> W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN >>> nodes will communicate via route-over using routable addresses (e.g. >>> ROLL). This brings us back to a broader topic of route-under vs. >>> mesh-under. While both will probably exist for some time, it raises the >>> question of whether 6LoWPAN implementations can support one or do they >>> have to support both. >>> >>> W.r.t compressing Hop Limit, I don't quite understand why you're using >> a >>> bit in HC3 to indicate where the message originated. If you're assuming >>> link-local communication, then messages shouldn't be forwarded across >>> links anyway. >>> >>> I do agree that there is work to do on compression and agree that there >>> are cases where HC1 and HC2 are not sufficient. This is why I've been >>> working, albeit slowly, on HC1g. >>> >>> -- >>> Jonathan Hui >>> >>> >>> Pascal Thubert (pthubert) wrote: >>>> Dear 6LoWPANers, >>>> >>>> Though HC1 and HC2 provide us with the capability to express any >>>> combination of compression, the most expected (or at least shot for) >>>> case does not lead to a better compression of the HC headers >> themselves. >>>> Seems that we could define an HC3 that would compress the pair of HC1 >>>> and HC2 for that best case. My proposal for doing this would be to: >>>> >>>> - define a new dispatch >>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>>> transport >>>> >>>> - define HC3 itself to: >>>> >>>> - implicitly say that the first 5 bits of HC1 are all ones >>>> - carry HC1 bits 5 and 6 (Next Header) >>>> - replace HC2 so bit 7 of HC1 is useless >>>> - provide transport specific bits such as those defined for >>>> HC-UDP, >>>> then again assuming a predefined best case if room is missing >>>> >>>> An example of what the HC3 octet could be: >>>> >>>> bits 0 1 2-3 >>>> 4-7 >>>> >>>> >> +------------------+-------------+-----------------+-------------------- >>>> ---------------------+ >>>> | reserved | reserved | Next Header | >> transport >>>> specific control bits | >>>> >>>> >> +------------------+-------------+-----------------+-------------------- >>>> ---------------------+ >>>> >>>> Next header: as defined in HC1, bits 5 and 6 >>>> >>>> transport specific control bits for UDP: >>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>> bit 7 is reserved >>>> >>>> What do you think? >>>> >>>> Pascal >>>> _______________________________________________ >>>> 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 Mar 5 05:06:21 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4886E28C609; Wed, 5 Mar 2008 05:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[AWL=-1.264, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, J_CHICKENPOX_33=0.6, RDNS_NONE=0.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 BHFgipSgPZu5; Wed, 5 Mar 2008 05:06:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5D83A6C56; Wed, 5 Mar 2008 05:06:19 -0800 (PST) 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 485DD28C22F for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 05:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 fNRhxBVXLp2K for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 05:06:13 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5A61A3A6C56 for <6lowpan@ietf.org>; Wed, 5 Mar 2008 05:06:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,450,1199660400"; d="scan'208";a="2590294" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2008 14:06:02 +0100 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 m25D62C7025356; Wed, 5 Mar 2008 14:06:02 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m25D5qHC014339; Wed, 5 Mar 2008 13:05:52 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); Wed, 5 Mar 2008 14:05:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 14:05:24 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05483517@xmb-ams-337.emea.cisco.com> In-Reply-To: <47CE905A.6090802@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Compressing HC1 and HC2 into HC3 thread-index: Ach+u5BXxuulcVCbSK+GhlFHFyWsxQABEGoA From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "Jonathan Hui" X-OriginalArrivalTime: 05 Mar 2008 13:05:52.0222 (UTC) FILETIME=[A3D0D7E0:01C87EC1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7125; t=1204722362; x=1205586362; 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]=20Compressing=20HC1=20and=20H C2=20into=20HC3 |Sender:=20; bh=HTF+J+q7UFjfbykz84kLvPl1tRAwwcMoxwSpESPGO8M=; b=Tu353+7JtgS1bAO01U4w9GJEEQy6WNrDRsFp/0AqcsRNeF/ECjMSgPg3Al tuHYSH5eL/W9TsLSO43REgtraw0OcX83u7KMVikBdpAq1XVHJefVh/Ik28jX ZHuM90+bBF; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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; I'd be glad to work with Jonathan in pushing some benefits from HC1g into HC3 if that's what this group wishes to do. Seems to me that the configuration that makes most sense for ULA and global addresses is that the local prefix and suffix are compressed but the remote is not at all. If that's so then one bit in HC3 is enough just to say LLA versus ULA|GLO, expecting that in the former case both addresses are compressed and in the latter only the local side is elided. What do you think? Pascal >-----Original Message----- >From: Zach Shelby [mailto:zach@sensinode.com] >Sent: mercredi 5 mars 2008 13:22 >To: Pascal Thubert (pthubert) >Cc: enns@stanfordalumni.org; 6lowpan; Jay Werb >Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 > >Very nice discussion. > >I see the logic in going after a more aggressive HC3 compression for use >within the 6lowpan network. It also would incorporate elided CRC which I >would also like to see it for local use. So far from my implementation >and use experience HC3 would cover 95% of our use of 6lowpan. > >Why wouldn't the HC3 proposal work with both mesh under or route over? >e.g. MANET routing protocols are also mainly using flat IP addressing >within the MANET. So in reality route-over would likely use the MAC >address of the interface and elide the IPv6 address when using 6lowpan >at least, just as in 6lowpan "mesh under" as long as the destination >address is in the same subnet. It would be quite easy to switch to >HC1+HC2 or HC1g in the case that you detect that the destination address >has a different non link-local prefix. Please correct me if I am wrong >here... > >Of course both HC3 and HC1g would be needed in such networks, as HC1g >allows us to communicate outside the 6lowpan network with minimal >overhead. So I am in favor of both. Of course there is the question if >we would have a place for HC3 in the new charter? > >- Zach > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >> You are assuming explicitly that I am assuming implicitly... mesh >> under... Hum. >> >> Please have a look at >> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >> -00.txt and it should be apparent that I'm not. In particular the >> backbone router is the device that will set and use the hop limit bit. >> So will all those interconnecting devices used in pseudowire, split >> bridges, IP Mobility, etc... if they are deployed in this space. >> >> What I'm really assuming is a gateway or an edge server on the link. >> It's there in most architectures that I know of at this point that's why >> I included it in the case we shoot for and saved 2 bits. Note that when >> the ULA and global addresses are used on top of link local, it makes >> sense that we define a mechanism to compress them as well. But this is >> not what HC3 is about. >> >> The goal of my initial proposal is illustrative, to foster this very >> discussion around the idea that we can shoot for a favorite case and >> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >> think that the GW assumption is not reasonable, then, fine, let us >> affect 2 bits in HC3 to indicate whether the addresses are compressed. >> >> What do the others think? >> >> Pascal >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: mardi 4 mars 2008 18:05 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>> >>> >>> Hi Pascal, >>> >>> Thanks for sharing your thoughts. >>> >>> By assuming the first 5 bits in HC1 are '1', you're staking a claim >> that >>> mesh-under link-local communication within a PAN is going to be most >>> common case and the one we've "shot for". If link-local is all we focus >>> on, then we are missing the point of IP. Frankly, I don't see much >>> benefit of IP if communication is limited to the PAN. >>> >>> W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN >>> nodes will communicate via route-over using routable addresses (e.g. >>> ROLL). This brings us back to a broader topic of route-under vs. >>> mesh-under. While both will probably exist for some time, it raises the >>> question of whether 6LoWPAN implementations can support one or do they >>> have to support both. >>> >>> W.r.t compressing Hop Limit, I don't quite understand why you're using >> a >>> bit in HC3 to indicate where the message originated. If you're assuming >>> link-local communication, then messages shouldn't be forwarded across >>> links anyway. >>> >>> I do agree that there is work to do on compression and agree that there >>> are cases where HC1 and HC2 are not sufficient. This is why I've been >>> working, albeit slowly, on HC1g. >>> >>> -- >>> Jonathan Hui >>> >>> >>> Pascal Thubert (pthubert) wrote: >>>> Dear 6LoWPANers, >>>> >>>> Though HC1 and HC2 provide us with the capability to express any >>>> combination of compression, the most expected (or at least shot for) >>>> case does not lead to a better compression of the HC headers >> themselves. >>>> Seems that we could define an HC3 that would compress the pair of HC1 >>>> and HC2 for that best case. My proposal for doing this would be to: >>>> >>>> - define a new dispatch >>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>>> transport >>>> >>>> - define HC3 itself to: >>>> >>>> - implicitly say that the first 5 bits of HC1 are all ones >>>> - carry HC1 bits 5 and 6 (Next Header) >>>> - replace HC2 so bit 7 of HC1 is useless >>>> - provide transport specific bits such as those defined for >>>> HC-UDP, >>>> then again assuming a predefined best case if room is missing >>>> >>>> An example of what the HC3 octet could be: >>>> >>>> bits 0 1 2-3 >>>> 4-7 >>>> >>>> >> +------------------+-------------+-----------------+-------------------- >>>> ---------------------+ >>>> | reserved | reserved | Next Header | >> transport >>>> specific control bits | >>>> >>>> >> +------------------+-------------+-----------------+-------------------- >>>> ---------------------+ >>>> >>>> Next header: as defined in HC1, bits 5 and 6 >>>> >>>> transport specific control bits for UDP: >>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>> bit 7 is reserved >>>> >>>> What do you think? >>>> >>>> Pascal >>>> _______________________________________________ >>>> 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 | CTO | +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 Wed Mar 5 08:26:55 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B998F28C7EF; Wed, 5 Mar 2008 08:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 hkcv+etEKCn0; Wed, 5 Mar 2008 08:26:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E1728C770; Wed, 5 Mar 2008 08:26:50 -0800 (PST) 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 83A6F28C75E for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 08:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 qwAvYhZD5xLj for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 08:26:48 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 5F2B33A6E73 for <6lowpan@ietf.org>; Wed, 5 Mar 2008 08:26:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id B8FF6A9323; Wed, 5 Mar 2008 08:26:38 -0800 (PST) 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 EmYY0iK5MmHJ; Wed, 5 Mar 2008 08:26:31 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id BF5EAA92FC; Wed, 5 Mar 2008 08:26:30 -0800 (PST) Message-ID: <47CEC9B3.207@archrock.com> Date: Wed, 05 Mar 2008 08:26:27 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC054834A3@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC054834A3@xmb-ams-337.emea.cisco.com> Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Mesh Under vs. ND proxy 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 Pascal, I think our definition of 'mesh-under' is conflicting. What I mean by 'mesh-under' is that forwarding occurs below IP, that is, the Hop Limit does not get decremented by intermediate forwarding nodes. 'Route-over' on the other hand is simply IP routing - nodes forwarding datagrams also decrement the Hop Limit. As you state, the goal of BbR is to abstract one or more PANs to appear as a single IP link, possibly with the support of other link technologies. Given this definition of 'mesh-under', would you agree that BbR is supporting mesh-under? -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi Jonathan: > > The Backbone Router (BbR) draft makes no assumption that I am aware of > on whether there is or not more than one radio hop over a LoWPAN; both > cases are supported. Now I think it's fair to make a distinction between > radio hops over the LowPAN and hops over the backbone: > > - First, the backbone is not supposed to be of the same technology as > the LoWPAN. A backbone router is thus expected to expand the 6LoWPAN > compressed packets and reassemble the fragments. The backbone can a > simple ethernet cable, but it might as well be a mesh of tunnels over a > WAN. The packet might be delivered to an IPv6 node sitting on the > backbone, or be forwarded across a destination LoWPAN via another > backbone router. Because the destination LoWPAN might be different in > nature from the source LoWPAN, uncompressed IP is the esperanto over the > backbone. > > - Second, the routing protocol is somewhat different. The backbone > router uses proxy ND techniques to represent its field devices over the > link abstraction that is the backbone and make routing decision to > forward over the LoWPAN vs. over the backbone; and the types of routing > that sustains the backbone itself can be virtually anything from > spanning tree to BGP. > > The goal for this draft is to federate multiple small LoWPANs into one > larger IPv6 link over a backbone of any sort that is also part of the > link. The single link requirement matches the current applications that > I know of and enables a field device to move from one BrB to another one > on the same link while retaining transparently its address and active > connections. > > The backbone router is the router that enables that LoWPAN > interconnection, and proxy ND is the technique that is proposed to > achieve the goal above. Other techniques such as NETLMM/proxy MIP were > discussed but seemed overkill for the desired result and the constraints > of the LoWPAN. > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: mercredi 5 mars 2008 08:59 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >> >> >> In your draft, you claim that 6LoWPAN nodes address each other and the >> backbone router using link-local addresses. If that occurs over > multiple >> radio hops, that sounds like mesh under to me... In other words, you > are >> assuming that an entire PAN functions as a single IP link (the IPv6 >> definition of a link). Am I missing something here? >> >> -- >> Jonathan Hui >> >> >> Pascal Thubert (pthubert) wrote: >>> Hi Jonathan: >>> >>> You are assuming explicitly that I am assuming implicitly... mesh >>> under... Hum. >>> >>> Please have a look at >>> > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>> -00.txt and it should be apparent that I'm not. In particular the >>> backbone router is the device that will set and use the hop limit > bit. >>> So will all those interconnecting devices used in pseudowire, split >>> bridges, IP Mobility, etc... if they are deployed in this space. >>> >>> What I'm really assuming is a gateway or an edge server on the link. >>> It's there in most architectures that I know of at this point that's > why >>> I included it in the case we shoot for and saved 2 bits. Note that > when >>> the ULA and global addresses are used on top of link local, it makes >>> sense that we define a mechanism to compress them as well. But this > is >>> not what HC3 is about. >>> >>> The goal of my initial proposal is illustrative, to foster this very >>> discussion around the idea that we can shoot for a favorite case and >>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >>> think that the GW assumption is not reasonable, then, fine, let us >>> affect 2 bits in HC3 to indicate whether the addresses are > compressed. >>> What do the others think? >>> >>> Pascal >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: mardi 4 mars 2008 18:05 >>>> To: Pascal Thubert (pthubert) >>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>> >>>> >>>> Hi Pascal, >>>> >>>> Thanks for sharing your thoughts. >>>> >>>> By assuming the first 5 bits in HC1 are '1', you're staking a claim >>> that >>>> mesh-under link-local communication within a PAN is going to be most >>>> common case and the one we've "shot for". If link-local is all we > focus >>>> on, then we are missing the point of IP. Frankly, I don't see much >>>> benefit of IP if communication is limited to the PAN. >>>> >>>> W.r.t mesh-under, there are efforts within the IETF that assume > 6LoWPAN >>>> nodes will communicate via route-over using routable addresses (e.g. >>>> ROLL). This brings us back to a broader topic of route-under vs. >>>> mesh-under. While both will probably exist for some time, it raises > the >>>> question of whether 6LoWPAN implementations can support one or do > they >>>> have to support both. >>>> >>>> W.r.t compressing Hop Limit, I don't quite understand why you're > using >>> a >>>> bit in HC3 to indicate where the message originated. If you're > assuming >>>> link-local communication, then messages shouldn't be forwarded > across >>>> links anyway. >>>> >>>> I do agree that there is work to do on compression and agree that > there >>>> are cases where HC1 and HC2 are not sufficient. This is why I've > been >>>> working, albeit slowly, on HC1g. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> Pascal Thubert (pthubert) wrote: >>>>> Dear 6LoWPANers, >>>>> >>>>> Though HC1 and HC2 provide us with the capability to express any >>>>> combination of compression, the most expected (or at least shot > for) >>>>> case does not lead to a better compression of the HC headers >>> themselves. >>>>> Seems that we could define an HC3 that would compress the pair of > HC1 >>>>> and HC2 for that best case. My proposal for doing this would be to: >>>>> >>>>> - define a new dispatch >>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>>>> transport >>>>> >>>>> - define HC3 itself to: >>>>> >>>>> - implicitly say that the first 5 bits of HC1 are all ones >>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>> - replace HC2 so bit 7 of HC1 is useless >>>>> - provide transport specific bits such as those defined for >>>>> HC-UDP, >>>>> then again assuming a predefined best case if room is > missing >>>>> An example of what the HC3 octet could be: >>>>> >>>>> bits 0 1 2-3 >>>>> 4-7 >>>>> >>>>> > +------------------+-------------+-----------------+-------------------- >>>>> ---------------------+ >>>>> | reserved | reserved | Next Header | >>> transport >>>>> specific control bits | >>>>> >>>>> > +------------------+-------------+-----------------+-------------------- >>>>> ---------------------+ >>>>> >>>>> Next header: as defined in HC1, bits 5 and 6 >>>>> >>>>> transport specific control bits for UDP: >>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>> bit 7 is reserved >>>>> >>>>> What do you think? >>>>> >>>>> Pascal >>>>> _______________________________________________ >>>>> 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 Mar 5 08:26:56 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8916A28C7EF; Wed, 5 Mar 2008 08:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 ew1DN+KEiZdn; Wed, 5 Mar 2008 08:26:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18CC928C7D7; Wed, 5 Mar 2008 08:26:55 -0800 (PST) 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 F203B28C26B for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 08:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 KK87s1-3Lb84 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 08:26:52 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id CFBA828C7D7 for <6lowpan@ietf.org>; Wed, 5 Mar 2008 08:26:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 50A25A92FC; Wed, 5 Mar 2008 08:26:43 -0800 (PST) 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 CP8LbHxcEiYh; Wed, 5 Mar 2008 08:26:36 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 5A6B0A9303; Wed, 5 Mar 2008 08:26:36 -0800 (PST) Message-ID: <47CEC9BA.9060909@archrock.com> Date: Wed, 05 Mar 2008 08:26:34 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Zach Shelby References: <7892795E1A87F04CADFCCF41FADD00FC054832F7@xmb-ams-337.emea.cisco.com> <47CE905A.6090802@sensinode.com> In-Reply-To: <47CE905A.6090802@sensinode.com> Cc: Jay Werb , 6lowpan <6lowpan@ietf.org>, enns@stanfordalumni.org Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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. See below: Zach Shelby wrote: > Very nice discussion. > > I see the logic in going after a more aggressive HC3 compression for use > within the 6lowpan network. It also would incorporate elided CRC which I > would also like to see it for local use. So far from my implementation > and use experience HC3 would cover 95% of our use of 6lowpan. This completely depends on how you implement your 6LoWPAN network. I can see how HC3 would work well for mesh-under networks where one or more 802.15.4 networks are abstracted as a single IP link. However, HC3 does not work well if we assume route-over, where every link/radio hop is an IP hop. Because I've been working with route-over networks, I can say that HC3 is insufficient for 95% of my use cases. > Why wouldn't the HC3 proposal work with both mesh under or route over? > e.g. MANET routing protocols are also mainly using flat IP addressing > within the MANET. So in reality route-over would likely use the MAC > address of the interface and elide the IPv6 address when using 6lowpan > at least, just as in 6lowpan "mesh under" as long as the destination > address is in the same subnet. It would be quite easy to switch to > HC1+HC2 or HC1g in the case that you detect that the destination address > has a different non link-local prefix. Please correct me if I am wrong > here... In my view, one difference between mesh-under and route-over is whether or not the 6LoWPAN Mesh Addressing header is used. In mesh-under, the Mesh Addressing header is used to deliver a datagram over multiple L2 hops but only a single IP hop, and when link-local addresses are used, both addresses in the IP header can be completely elided. In route-over, no Mesh Addressing header is used, every L2 hop is an IP hop, and the source and destination addresses are carried directly in the IP header. Given this difference, I don't see how HC3 would support carrying addresses in the IP header. Now, as you state, ad-hoc routing does often boil down to host based routing. For that very point, I think the difference between forwarding at L2 vs. forwarding at L3 is less than we think. At some level, it's about where do the addresses go. The goal of HC1g is to provide a way to express both extended and short addresses in the IP header, with the assumption that the Mesh Addressing header will not be used. -- Jonathan Hui > Of course both HC3 and HC1g would be needed in such networks, as HC1g > allows us to communicate outside the 6lowpan network with minimal > overhead. So I am in favor of both. Of course there is the question if > we would have a place for HC3 in the new charter? > > - Zach > > Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >> You are assuming explicitly that I am assuming implicitly... mesh >> under... Hum. >> >> Please have a look at >> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >> -00.txt and it should be apparent that I'm not. In particular the >> backbone router is the device that will set and use the hop limit bit. >> So will all those interconnecting devices used in pseudowire, split >> bridges, IP Mobility, etc... if they are deployed in this space. >> >> What I'm really assuming is a gateway or an edge server on the link. >> It's there in most architectures that I know of at this point that's why >> I included it in the case we shoot for and saved 2 bits. Note that when >> the ULA and global addresses are used on top of link local, it makes >> sense that we define a mechanism to compress them as well. But this is >> not what HC3 is about. >> >> The goal of my initial proposal is illustrative, to foster this very >> discussion around the idea that we can shoot for a favorite case and >> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >> think that the GW assumption is not reasonable, then, fine, let us >> affect 2 bits in HC3 to indicate whether the addresses are compressed. >> >> What do the others think? >> >> Pascal >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: mardi 4 mars 2008 18:05 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>> >>> >>> Hi Pascal, >>> >>> Thanks for sharing your thoughts. >>> >>> By assuming the first 5 bits in HC1 are '1', you're staking a claim >> that >>> mesh-under link-local communication within a PAN is going to be most >>> common case and the one we've "shot for". If link-local is all we focus >>> on, then we are missing the point of IP. Frankly, I don't see much >>> benefit of IP if communication is limited to the PAN. >>> >>> W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN >>> nodes will communicate via route-over using routable addresses (e.g. >>> ROLL). This brings us back to a broader topic of route-under vs. >>> mesh-under. While both will probably exist for some time, it raises the >>> question of whether 6LoWPAN implementations can support one or do they >>> have to support both. >>> >>> W.r.t compressing Hop Limit, I don't quite understand why you're using >> a >>> bit in HC3 to indicate where the message originated. If you're assuming >>> link-local communication, then messages shouldn't be forwarded across >>> links anyway. >>> >>> I do agree that there is work to do on compression and agree that there >>> are cases where HC1 and HC2 are not sufficient. This is why I've been >>> working, albeit slowly, on HC1g. >>> >>> -- >>> Jonathan Hui >>> >>> >>> Pascal Thubert (pthubert) wrote: >>>> Dear 6LoWPANers, >>>> >>>> Though HC1 and HC2 provide us with the capability to express any >>>> combination of compression, the most expected (or at least shot for) >>>> case does not lead to a better compression of the HC headers >> themselves. >>>> Seems that we could define an HC3 that would compress the pair of HC1 >>>> and HC2 for that best case. My proposal for doing this would be to: >>>> >>>> - define a new dispatch >>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>>> transport >>>> >>>> - define HC3 itself to: >>>> >>>> - implicitly say that the first 5 bits of HC1 are all ones >>>> - carry HC1 bits 5 and 6 (Next Header) >>>> - replace HC2 so bit 7 of HC1 is useless >>>> - provide transport specific bits such as those defined for >>>> HC-UDP, >>>> then again assuming a predefined best case if room is missing >>>> >>>> An example of what the HC3 octet could be: >>>> >>>> bits 0 1 2-3 >>>> 4-7 >>>> >>>> >> +------------------+-------------+-----------------+-------------------- >>>> ---------------------+ >>>> | reserved | reserved | Next Header | >> transport >>>> specific control bits | >>>> >>>> >> +------------------+-------------+-----------------+-------------------- >>>> ---------------------+ >>>> >>>> Next header: as defined in HC1, bits 5 and 6 >>>> >>>> transport specific control bits for UDP: >>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>> bit 7 is reserved >>>> >>>> What do you think? >>>> >>>> Pascal >>>> _______________________________________________ >>>> 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 Mar 5 08:31:28 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2D528C7E6; Wed, 5 Mar 2008 08:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.227 X-Spam-Level: X-Spam-Status: No, score=-0.227 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 aPGU2rAHHKJq; Wed, 5 Mar 2008 08:31:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B0528C75E; Wed, 5 Mar 2008 08:31:24 -0800 (PST) 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 0ECBC3A6F00 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 08:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 d5pVSdMlSyCn for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 08:31:21 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id DD5CA3A6E73 for <6lowpan@ietf.org>; Wed, 5 Mar 2008 08:31:21 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 2B66EA92F3; Wed, 5 Mar 2008 08:31:12 -0800 (PST) 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 HODjGwOzIKn0; Wed, 5 Mar 2008 08:31:05 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id EC0D1A92EE; Wed, 5 Mar 2008 08:31:04 -0800 (PST) Message-ID: <47CECAC4.8010807@archrock.com> Date: Wed, 05 Mar 2008 08:31:00 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC054834BC@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC054834BC@xmb-ams-337.emea.cisco.com> Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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 it's fair to say that we should continue working on IP header compression. However, I also think we must evaluate whether we are willing to specialize such compression schemes for route-over vs. mesh-under networks. I don't have a problem with such specialization, but I would have a problem if we required any 6LoWPAN implementation to support specialized schemes for both mesh-under and route-over simultaneously. -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi Jonathan > > I agree it's great we are having this discussion :) > > Multiple thread could spawn from it because there are multiple topic. > And some of this might belong to ROLL as you pointed out earlier. > > I'd wish to keep this thread for its original question on whether it is > desirable, in the context of what we already have, to further compress > HC1 and HC2 into a single HC3. For that specific thread, I retain that > you do not oppose but that you vote for retaining some information on > whether the addresses are elided or not. > > Is that fair? > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: mercredi 5 mars 2008 09:28 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >> >> >> Regarding the GW assumption on the link, I think we need to take a step >> back for a second. While it is true that most architectures up until >> this point follow this assumption, most architectures that I know of >> haven't been built using IP. ZigBee nodes, for example, only > communicate >> with ZigBee nodes at every hop and there isn't any effort to do >> internetworking. >> >> But now that we actually have IP, we are no longer constrained to a >> single link technology. Rather, nodes can communicate with each other, >> directly using 802.15.4, or over other technologies such as WiFi, >> Ethernet, GPRS, etc. This really opens up the network architecture >> possibilities, and there are many cases where adding these additional >> links are desirable. I know that ISA's proposed backbone routers > provide >> this functionality, but I'd rather support such networks at the IP >> layer, rather than abstracting a combination of link technologies as >> single IP link and defining any new machinery to do so. >> >> BTW it's great that we're having this discussion. It is long overdue. >> >> -- >> Jonathan Hui >> >> >> Pascal Thubert (pthubert) wrote: >>> Hi Jonathan: >>> >>> You are assuming explicitly that I am assuming implicitly... mesh >>> under... Hum. >>> >>> Please have a look at >>> > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>> -00.txt and it should be apparent that I'm not. In particular the >>> backbone router is the device that will set and use the hop limit > bit. >>> So will all those interconnecting devices used in pseudowire, split >>> bridges, IP Mobility, etc... if they are deployed in this space. >>> >>> What I'm really assuming is a gateway or an edge server on the link. >>> It's there in most architectures that I know of at this point that's > why >>> I included it in the case we shoot for and saved 2 bits. Note that > when >>> the ULA and global addresses are used on top of link local, it makes >>> sense that we define a mechanism to compress them as well. But this > is >>> not what HC3 is about. >>> >>> The goal of my initial proposal is illustrative, to foster this very >>> discussion around the idea that we can shoot for a favorite case and >>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >>> think that the GW assumption is not reasonable, then, fine, let us >>> affect 2 bits in HC3 to indicate whether the addresses are > compressed. >>> What do the others think? >>> >>> Pascal >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: mardi 4 mars 2008 18:05 >>>> To: Pascal Thubert (pthubert) >>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>> >>>> >>>> Hi Pascal, >>>> >>>> Thanks for sharing your thoughts. >>>> >>>> By assuming the first 5 bits in HC1 are '1', you're staking a claim >>> that >>>> mesh-under link-local communication within a PAN is going to be most >>>> common case and the one we've "shot for". If link-local is all we > focus >>>> on, then we are missing the point of IP. Frankly, I don't see much >>>> benefit of IP if communication is limited to the PAN. >>>> >>>> W.r.t mesh-under, there are efforts within the IETF that assume > 6LoWPAN >>>> nodes will communicate via route-over using routable addresses (e.g. >>>> ROLL). This brings us back to a broader topic of route-under vs. >>>> mesh-under. While both will probably exist for some time, it raises > the >>>> question of whether 6LoWPAN implementations can support one or do > they >>>> have to support both. >>>> >>>> W.r.t compressing Hop Limit, I don't quite understand why you're > using >>> a >>>> bit in HC3 to indicate where the message originated. If you're > assuming >>>> link-local communication, then messages shouldn't be forwarded > across >>>> links anyway. >>>> >>>> I do agree that there is work to do on compression and agree that > there >>>> are cases where HC1 and HC2 are not sufficient. This is why I've > been >>>> working, albeit slowly, on HC1g. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> Pascal Thubert (pthubert) wrote: >>>>> Dear 6LoWPANers, >>>>> >>>>> Though HC1 and HC2 provide us with the capability to express any >>>>> combination of compression, the most expected (or at least shot > for) >>>>> case does not lead to a better compression of the HC headers >>> themselves. >>>>> Seems that we could define an HC3 that would compress the pair of > HC1 >>>>> and HC2 for that best case. My proposal for doing this would be to: >>>>> >>>>> - define a new dispatch >>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>>>> transport >>>>> >>>>> - define HC3 itself to: >>>>> >>>>> - implicitly say that the first 5 bits of HC1 are all ones >>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>> - replace HC2 so bit 7 of HC1 is useless >>>>> - provide transport specific bits such as those defined for >>>>> HC-UDP, >>>>> then again assuming a predefined best case if room is > missing >>>>> An example of what the HC3 octet could be: >>>>> >>>>> bits 0 1 2-3 >>>>> 4-7 >>>>> >>>>> > +------------------+-------------+-----------------+-------------------- >>>>> ---------------------+ >>>>> | reserved | reserved | Next Header | >>> transport >>>>> specific control bits | >>>>> >>>>> > +------------------+-------------+-----------------+-------------------- >>>>> ---------------------+ >>>>> >>>>> Next header: as defined in HC1, bits 5 and 6 >>>>> >>>>> transport specific control bits for UDP: >>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>> bit 7 is reserved >>>>> >>>>> What do you think? >>>>> >>>>> Pascal >>>>> _______________________________________________ >>>>> 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 Mar 5 08:59:12 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531CC3A6C9B; Wed, 5 Mar 2008 08:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.75 X-Spam-Level: X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 e72vPOIProOD; Wed, 5 Mar 2008 08:59:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0853A6F33; Wed, 5 Mar 2008 08:59:10 -0800 (PST) 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 0DE5A3A6F33 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 08:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 gTXPh34SBd2D for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 08:59:07 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1CC103A6CFE for <6lowpan@ietf.org>; Wed, 5 Mar 2008 08:59:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,451,1199660400"; d="scan'208";a="2623325" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2008 17:58:47 +0100 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 m25GwlRJ017771; Wed, 5 Mar 2008 17:58:47 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m25GwIHQ021603; Wed, 5 Mar 2008 16:58: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); Wed, 5 Mar 2008 17:58:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 17:57:57 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0548364C@xmb-ams-337.emea.cisco.com> In-Reply-To: <47CEC9B3.207@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mesh Under vs. ND proxy thread-index: Ach+3eDsuaeNzuq6Qze7/fV81I+JTwAAUQ0A From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 05 Mar 2008 16:58:25.0612 (UTC) FILETIME=[20AF30C0:01C87EE2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9758; t=1204736327; x=1205600327; 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=20Mesh=20Under=20vs.=20ND=20proxy |Sender:=20; bh=Dr9BbGLFG0iy2pEa0PvZiGkjo+B8TY7H3TwsUw/Ggvs=; b=kUYvKZnUc98C35eUMQqM1CEW18v318M5qbO6twnT/WhA0EgxqUvNbA7jjI VZj2txUd8IPX+ud5btbJk8xwbEW8NRIFRzobTcg+jCqinoyS6zKpyZ8UxxT7 Bv15N6pbLk; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Mesh Under vs. ND proxy 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 see what you're saying and you are certainly correct from that perspective. You got me quite confused because there's that other mail to Zach when you associate mesh-under with a mesh header, and that definition is actually way closer to mine. A mesh is a radio topology and mesh-under is about routing at L2 on that topology. Note that proxy-ND is still ND, in other words it is a layer 3 operation, not a 'below IP' thing. Proxy-ND is a L3 tool that enables to merge the link local addressing spaces of 2 links into a single, larger one. And the backbone router is a real L3 gateway, that terminates a Layer 2 network to route packets onto another one. For the rest I see what you're saying and I'm certainly willing to modify HC3 to satisfy the routing over case you're talking about; I made a step in another thread; let's see how it goes: I'd wish to hear other opinions. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mercredi 5 mars 2008 17:26 >To: Pascal Thubert (pthubert) >Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >Subject: Re: Mesh Under vs. ND proxy > > >Hi Pascal, > >I think our definition of 'mesh-under' is conflicting. What I mean by >'mesh-under' is that forwarding occurs below IP, that is, the Hop Limit >does not get decremented by intermediate forwarding nodes. 'Route-over' >on the other hand is simply IP routing - nodes forwarding datagrams also >decrement the Hop Limit. As you state, the goal of BbR is to abstract >one or more PANs to appear as a single IP link, possibly with the >support of other link technologies. > >Given this definition of 'mesh-under', would you agree that BbR is >supporting mesh-under? > >-- >Jonathan Hui > > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >> The Backbone Router (BbR) draft makes no assumption that I am aware of >> on whether there is or not more than one radio hop over a LoWPAN; both >> cases are supported. Now I think it's fair to make a distinction between >> radio hops over the LowPAN and hops over the backbone: >> >> - First, the backbone is not supposed to be of the same technology as >> the LoWPAN. A backbone router is thus expected to expand the 6LoWPAN >> compressed packets and reassemble the fragments. The backbone can a >> simple ethernet cable, but it might as well be a mesh of tunnels over a >> WAN. The packet might be delivered to an IPv6 node sitting on the >> backbone, or be forwarded across a destination LoWPAN via another >> backbone router. Because the destination LoWPAN might be different in >> nature from the source LoWPAN, uncompressed IP is the esperanto over the >> backbone. >> >> - Second, the routing protocol is somewhat different. The backbone >> router uses proxy ND techniques to represent its field devices over the >> link abstraction that is the backbone and make routing decision to >> forward over the LoWPAN vs. over the backbone; and the types of routing >> that sustains the backbone itself can be virtually anything from >> spanning tree to BGP. >> >> The goal for this draft is to federate multiple small LoWPANs into one >> larger IPv6 link over a backbone of any sort that is also part of the >> link. The single link requirement matches the current applications that >> I know of and enables a field device to move from one BrB to another one >> on the same link while retaining transparently its address and active >> connections. >> >> The backbone router is the router that enables that LoWPAN >> interconnection, and proxy ND is the technique that is proposed to >> achieve the goal above. Other techniques such as NETLMM/proxy MIP were >> discussed but seemed overkill for the desired result and the constraints >> of the LoWPAN. >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: mercredi 5 mars 2008 08:59 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>> >>> >>> In your draft, you claim that 6LoWPAN nodes address each other and the >>> backbone router using link-local addresses. If that occurs over >> multiple >>> radio hops, that sounds like mesh under to me... In other words, you >> are >>> assuming that an entire PAN functions as a single IP link (the IPv6 >>> definition of a link). Am I missing something here? >>> >>> -- >>> Jonathan Hui >>> >>> >>> Pascal Thubert (pthubert) wrote: >>>> Hi Jonathan: >>>> >>>> You are assuming explicitly that I am assuming implicitly... mesh >>>> under... Hum. >>>> >>>> Please have a look at >>>> >> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>>> -00.txt and it should be apparent that I'm not. In particular the >>>> backbone router is the device that will set and use the hop limit >> bit. >>>> So will all those interconnecting devices used in pseudowire, split >>>> bridges, IP Mobility, etc... if they are deployed in this space. >>>> >>>> What I'm really assuming is a gateway or an edge server on the link. >>>> It's there in most architectures that I know of at this point that's >> why >>>> I included it in the case we shoot for and saved 2 bits. Note that >> when >>>> the ULA and global addresses are used on top of link local, it makes >>>> sense that we define a mechanism to compress them as well. But this >> is >>>> not what HC3 is about. >>>> >>>> The goal of my initial proposal is illustrative, to foster this very >>>> discussion around the idea that we can shoot for a favorite case and >>>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >>>> think that the GW assumption is not reasonable, then, fine, let us >>>> affect 2 bits in HC3 to indicate whether the addresses are >> compressed. >>>> What do the others think? >>>> >>>> Pascal >>>>> -----Original Message----- >>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>> Sent: mardi 4 mars 2008 18:05 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>> >>>>> >>>>> Hi Pascal, >>>>> >>>>> Thanks for sharing your thoughts. >>>>> >>>>> By assuming the first 5 bits in HC1 are '1', you're staking a claim >>>> that >>>>> mesh-under link-local communication within a PAN is going to be most >>>>> common case and the one we've "shot for". If link-local is all we >> focus >>>>> on, then we are missing the point of IP. Frankly, I don't see much >>>>> benefit of IP if communication is limited to the PAN. >>>>> >>>>> W.r.t mesh-under, there are efforts within the IETF that assume >> 6LoWPAN >>>>> nodes will communicate via route-over using routable addresses (e.g. >>>>> ROLL). This brings us back to a broader topic of route-under vs. >>>>> mesh-under. While both will probably exist for some time, it raises >> the >>>>> question of whether 6LoWPAN implementations can support one or do >> they >>>>> have to support both. >>>>> >>>>> W.r.t compressing Hop Limit, I don't quite understand why you're >> using >>>> a >>>>> bit in HC3 to indicate where the message originated. If you're >> assuming >>>>> link-local communication, then messages shouldn't be forwarded >> across >>>>> links anyway. >>>>> >>>>> I do agree that there is work to do on compression and agree that >> there >>>>> are cases where HC1 and HC2 are not sufficient. This is why I've >> been >>>>> working, albeit slowly, on HC1g. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> Pascal Thubert (pthubert) wrote: >>>>>> Dear 6LoWPANers, >>>>>> >>>>>> Though HC1 and HC2 provide us with the capability to express any >>>>>> combination of compression, the most expected (or at least shot >> for) >>>>>> case does not lead to a better compression of the HC headers >>>> themselves. >>>>>> Seems that we could define an HC3 that would compress the pair of >> HC1 >>>>>> and HC2 for that best case. My proposal for doing this would be to: >>>>>> >>>>>> - define a new dispatch >>>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>>>>> transport >>>>>> >>>>>> - define HC3 itself to: >>>>>> >>>>>> - implicitly say that the first 5 bits of HC1 are all ones >>>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>>> - replace HC2 so bit 7 of HC1 is useless >>>>>> - provide transport specific bits such as those defined for >>>>>> HC-UDP, >>>>>> then again assuming a predefined best case if room is >> missing >>>>>> An example of what the HC3 octet could be: >>>>>> >>>>>> bits 0 1 2-3 >>>>>> 4-7 >>>>>> >>>>>> >> +------------------+-------------+-----------------+-------------------- >>>>>> ---------------------+ >>>>>> | reserved | reserved | Next Header | >>>> transport >>>>>> specific control bits | >>>>>> >>>>>> >> +------------------+-------------+-----------------+-------------------- >>>>>> ---------------------+ >>>>>> >>>>>> Next header: as defined in HC1, bits 5 and 6 >>>>>> >>>>>> transport specific control bits for UDP: >>>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>>> bit 7 is reserved >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Pascal >>>>>> _______________________________________________ >>>>>> 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 Mar 5 09:15:40 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9A928C787; Wed, 5 Mar 2008 09:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.692 X-Spam-Level: X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 2-Y8pM3U2eBg; Wed, 5 Mar 2008 09:15:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AD2F3A6C6E; Wed, 5 Mar 2008 09:15:36 -0800 (PST) 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 9FD813A6B71 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 09:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 lmHvbJTeTouW for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 09:15:32 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5124E28C214 for <6lowpan@ietf.org>; Wed, 5 Mar 2008 09:15:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,451,1199660400"; d="scan'208";a="2625339" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2008 18:15:21 +0100 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 m25HFKKf015022; Wed, 5 Mar 2008 18:15:20 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m25HFAHG028382; Wed, 5 Mar 2008 17:15:18 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); Wed, 5 Mar 2008 18:15:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 18:14:50 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05483662@xmb-ams-337.emea.cisco.com> In-Reply-To: <47CECAC4.8010807@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Compressing HC1 and HC2 into HC3 thread-index: Ach+3nB56EiQr5kWRUSKG418C6Aq6QAA8k2w From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 05 Mar 2008 17:15:18.0004 (UTC) FILETIME=[7C1DF340:01C87EE4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9371; t=1204737320; x=1205601320; 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]=20Compressing=20HC1=20and=20H C2=20into=20HC3 |Sender:=20; bh=Ivc3iRUrXIj6FVt6Kzkm7Yx1wn8oaUS3TCI9ixHhcdI=; b=IgvYOGt//vQ4nL3WoWD3BXvqY16DXp46DwVs8F3020gBG9d5BnYko6T+wS E1R3nwl+f42vpbbvP2AGtD5CWmOc9Ui5eg3Ek9AboAO27CiS3dFwDrVmNzmt tPfpkHTvX1; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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'm certainly not willing to specialize HC3 to mesh-under whatever your definition of the term. I'm willing to specialize HC3 to elide a number off "always on" bits so that when these bits are on, HC3 is used instead of HC1 and HC2. I hope this much is clear by now. Consider this: even HC1g is specialized; it is specilized to the case when only the terminating networks are LoWPANs. For instance, how do you compress a packet in a LoWPAN that would sit between the source LoWPAN and the destination LoWPAN - that's ROLL for you? Like I said in another mail, this is a pretty difficult issue, maybe more complex than laying labels. My point is we do not know what ROLL will be made of; it will certainly be very interesting but it would be hazardous at this point to reserve bits for assumptions we could make on it. Let's look at what we have, which are the most important toggles and fit those in HC3. I'll be glad to define that the address that designs a node on this LoWPAN (the local address) is elided but is not a link-local-address and that the remote address is not elided. Or something else that makes sense like the local address is elided and is the one that unabiguously matches the scope of the remote address. So what's the case you're shooting for? Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mercredi 5 mars 2008 17:31 >To: Pascal Thubert (pthubert) >Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 > > >I think it's fair to say that we should continue working on IP header >compression. However, I also think we must evaluate whether we are >willing to specialize such compression schemes for route-over vs. >mesh-under networks. I don't have a problem with such specialization, >but I would have a problem if we required any 6LoWPAN implementation to >support specialized schemes for both mesh-under and route-over >simultaneously. > >-- >Jonathan Hui > > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan >> >> I agree it's great we are having this discussion :) >> >> Multiple thread could spawn from it because there are multiple topic. >> And some of this might belong to ROLL as you pointed out earlier. >> >> I'd wish to keep this thread for its original question on whether it is >> desirable, in the context of what we already have, to further compress >> HC1 and HC2 into a single HC3. For that specific thread, I retain that >> you do not oppose but that you vote for retaining some information on >> whether the addresses are elided or not. >> >> Is that fair? >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: mercredi 5 mars 2008 09:28 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>> >>> >>> Regarding the GW assumption on the link, I think we need to take a step >>> back for a second. While it is true that most architectures up until >>> this point follow this assumption, most architectures that I know of >>> haven't been built using IP. ZigBee nodes, for example, only >> communicate >>> with ZigBee nodes at every hop and there isn't any effort to do >>> internetworking. >>> >>> But now that we actually have IP, we are no longer constrained to a >>> single link technology. Rather, nodes can communicate with each other, >>> directly using 802.15.4, or over other technologies such as WiFi, >>> Ethernet, GPRS, etc. This really opens up the network architecture >>> possibilities, and there are many cases where adding these additional >>> links are desirable. I know that ISA's proposed backbone routers >> provide >>> this functionality, but I'd rather support such networks at the IP >>> layer, rather than abstracting a combination of link technologies as >>> single IP link and defining any new machinery to do so. >>> >>> BTW it's great that we're having this discussion. It is long overdue. >>> >>> -- >>> Jonathan Hui >>> >>> >>> Pascal Thubert (pthubert) wrote: >>>> Hi Jonathan: >>>> >>>> You are assuming explicitly that I am assuming implicitly... mesh >>>> under... Hum. >>>> >>>> Please have a look at >>>> >> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>>> -00.txt and it should be apparent that I'm not. In particular the >>>> backbone router is the device that will set and use the hop limit >> bit. >>>> So will all those interconnecting devices used in pseudowire, split >>>> bridges, IP Mobility, etc... if they are deployed in this space. >>>> >>>> What I'm really assuming is a gateway or an edge server on the link. >>>> It's there in most architectures that I know of at this point that's >> why >>>> I included it in the case we shoot for and saved 2 bits. Note that >> when >>>> the ULA and global addresses are used on top of link local, it makes >>>> sense that we define a mechanism to compress them as well. But this >> is >>>> not what HC3 is about. >>>> >>>> The goal of my initial proposal is illustrative, to foster this very >>>> discussion around the idea that we can shoot for a favorite case and >>>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >>>> think that the GW assumption is not reasonable, then, fine, let us >>>> affect 2 bits in HC3 to indicate whether the addresses are >> compressed. >>>> What do the others think? >>>> >>>> Pascal >>>>> -----Original Message----- >>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>> Sent: mardi 4 mars 2008 18:05 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>> >>>>> >>>>> Hi Pascal, >>>>> >>>>> Thanks for sharing your thoughts. >>>>> >>>>> By assuming the first 5 bits in HC1 are '1', you're staking a claim >>>> that >>>>> mesh-under link-local communication within a PAN is going to be most >>>>> common case and the one we've "shot for". If link-local is all we >> focus >>>>> on, then we are missing the point of IP. Frankly, I don't see much >>>>> benefit of IP if communication is limited to the PAN. >>>>> >>>>> W.r.t mesh-under, there are efforts within the IETF that assume >> 6LoWPAN >>>>> nodes will communicate via route-over using routable addresses (e.g. >>>>> ROLL). This brings us back to a broader topic of route-under vs. >>>>> mesh-under. While both will probably exist for some time, it raises >> the >>>>> question of whether 6LoWPAN implementations can support one or do >> they >>>>> have to support both. >>>>> >>>>> W.r.t compressing Hop Limit, I don't quite understand why you're >> using >>>> a >>>>> bit in HC3 to indicate where the message originated. If you're >> assuming >>>>> link-local communication, then messages shouldn't be forwarded >> across >>>>> links anyway. >>>>> >>>>> I do agree that there is work to do on compression and agree that >> there >>>>> are cases where HC1 and HC2 are not sufficient. This is why I've >> been >>>>> working, albeit slowly, on HC1g. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> Pascal Thubert (pthubert) wrote: >>>>>> Dear 6LoWPANers, >>>>>> >>>>>> Though HC1 and HC2 provide us with the capability to express any >>>>>> combination of compression, the most expected (or at least shot >> for) >>>>>> case does not lead to a better compression of the HC headers >>>> themselves. >>>>>> Seems that we could define an HC3 that would compress the pair of >> HC1 >>>>>> and HC2 for that best case. My proposal for doing this would be to: >>>>>> >>>>>> - define a new dispatch >>>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>>>>> transport >>>>>> >>>>>> - define HC3 itself to: >>>>>> >>>>>> - implicitly say that the first 5 bits of HC1 are all ones >>>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>>> - replace HC2 so bit 7 of HC1 is useless >>>>>> - provide transport specific bits such as those defined for >>>>>> HC-UDP, >>>>>> then again assuming a predefined best case if room is >> missing >>>>>> An example of what the HC3 octet could be: >>>>>> >>>>>> bits 0 1 2-3 >>>>>> 4-7 >>>>>> >>>>>> >> +------------------+-------------+-----------------+-------------------- >>>>>> ---------------------+ >>>>>> | reserved | reserved | Next Header | >>>> transport >>>>>> specific control bits | >>>>>> >>>>>> >> +------------------+-------------+-----------------+-------------------- >>>>>> ---------------------+ >>>>>> >>>>>> Next header: as defined in HC1, bits 5 and 6 >>>>>> >>>>>> transport specific control bits for UDP: >>>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>>> bit 7 is reserved >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Pascal >>>>>> _______________________________________________ >>>>>> 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 Mar 5 09:31:58 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03BD628C77C; Wed, 5 Mar 2008 09:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.231 X-Spam-Level: X-Spam-Status: No, score=-0.231 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 EAC5O-ifjaHt; Wed, 5 Mar 2008 09:31:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9983E3A6C25; Wed, 5 Mar 2008 09:31:56 -0800 (PST) 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 4C79F3A6C25 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 09:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 NRd3mkJUPkoo for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 09:31:54 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 0E45D3A6B71 for <6lowpan@ietf.org>; Wed, 5 Mar 2008 09:31:53 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 09908A9368; Wed, 5 Mar 2008 09:31:44 -0800 (PST) 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 S7ovc7WthG7V; Wed, 5 Mar 2008 09:31:36 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 27CE2A9364; Wed, 5 Mar 2008 09:31:36 -0800 (PST) Message-ID: <47CED8F4.5080802@archrock.com> Date: Wed, 05 Mar 2008 09:31:32 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC05483662@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05483662@xmb-ams-337.emea.cisco.com> Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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 Pascal, see below: Pascal Thubert (pthubert) wrote: > Hi Jonathan: > > I'm certainly not willing to specialize HC3 to mesh-under whatever your > definition of the term. I'm willing to specialize HC3 to elide a number > off "always on" bits so that when these bits are on, HC3 is used instead > of HC1 and HC2. I hope this much is clear by now. Yes, this is clear now. > Consider this: even HC1g is specialized; it is specilized to the case > when only the terminating networks are LoWPANs. For instance, how do you > compress a packet in a LoWPAN that would sit between the source LoWPAN > and the destination LoWPAN - that's ROLL for you? I never said that HC1g wasn't specialized. Any compression scheme must make assumptions about the underlying pattern, otherwise there is no compression to be had. ROLL for me is where every node operates as an IP router. HC1g is trying to address a PAN where each L2 hop is an IP hop. However, it is not trying to address cases where the PAN is a transit network for external networks that can have arbitrary prefixes. In other words, any messages going into the PAN will be destined for those nodes in the PAN, and similarly any messages leaving the PAN will be sourced by a node in the PAN. But in both cases, the addresses used are routable addresses. This is the case I'm shooting for. Is this scenario realistic to you? -- Jonathan Hui > Like I said in another mail, this is a pretty difficult issue, maybe > more complex than laying labels. My point is we do not know what ROLL > will be made of; it will certainly be very interesting but it would be > hazardous at this point to reserve bits for assumptions we could make on > it. > > Let's look at what we have, which are the most important toggles and fit > those in HC3. I'll be glad to define that the address that designs a > node on this LoWPAN (the local address) is elided but is not a > link-local-address and that the remote address is not elided. Or > something else that makes sense like the local address is elided and is > the one that unabiguously matches the scope of the remote address. > > So what's the case you're shooting for? > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: mercredi 5 mars 2008 17:31 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >> >> >> I think it's fair to say that we should continue working on IP header >> compression. However, I also think we must evaluate whether we are >> willing to specialize such compression schemes for route-over vs. >> mesh-under networks. I don't have a problem with such specialization, >> but I would have a problem if we required any 6LoWPAN implementation to >> support specialized schemes for both mesh-under and route-over >> simultaneously. >> >> -- >> Jonathan Hui >> >> >> Pascal Thubert (pthubert) wrote: >>> Hi Jonathan >>> >>> I agree it's great we are having this discussion :) >>> >>> Multiple thread could spawn from it because there are multiple topic. >>> And some of this might belong to ROLL as you pointed out earlier. >>> >>> I'd wish to keep this thread for its original question on whether it > is >>> desirable, in the context of what we already have, to further > compress >>> HC1 and HC2 into a single HC3. For that specific thread, I retain > that >>> you do not oppose but that you vote for retaining some information on >>> whether the addresses are elided or not. >>> >>> Is that fair? >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: mercredi 5 mars 2008 09:28 >>>> To: Pascal Thubert (pthubert) >>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>> >>>> >>>> Regarding the GW assumption on the link, I think we need to take a > step >>>> back for a second. While it is true that most architectures up until >>>> this point follow this assumption, most architectures that I know of >>>> haven't been built using IP. ZigBee nodes, for example, only >>> communicate >>>> with ZigBee nodes at every hop and there isn't any effort to do >>>> internetworking. >>>> >>>> But now that we actually have IP, we are no longer constrained to a >>>> single link technology. Rather, nodes can communicate with each > other, >>>> directly using 802.15.4, or over other technologies such as WiFi, >>>> Ethernet, GPRS, etc. This really opens up the network architecture >>>> possibilities, and there are many cases where adding these > additional >>>> links are desirable. I know that ISA's proposed backbone routers >>> provide >>>> this functionality, but I'd rather support such networks at the IP >>>> layer, rather than abstracting a combination of link technologies as >>>> single IP link and defining any new machinery to do so. >>>> >>>> BTW it's great that we're having this discussion. It is long > overdue. >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> Pascal Thubert (pthubert) wrote: >>>>> Hi Jonathan: >>>>> >>>>> You are assuming explicitly that I am assuming implicitly... mesh >>>>> under... Hum. >>>>> >>>>> Please have a look at >>>>> > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>>>> -00.txt and it should be apparent that I'm not. In particular the >>>>> backbone router is the device that will set and use the hop limit >>> bit. >>>>> So will all those interconnecting devices used in pseudowire, split >>>>> bridges, IP Mobility, etc... if they are deployed in this space. >>>>> >>>>> What I'm really assuming is a gateway or an edge server on the > link. >>>>> It's there in most architectures that I know of at this point > that's >>> why >>>>> I included it in the case we shoot for and saved 2 bits. Note that >>> when >>>>> the ULA and global addresses are used on top of link local, it > makes >>>>> sense that we define a mechanism to compress them as well. But this >>> is >>>>> not what HC3 is about. >>>>> >>>>> The goal of my initial proposal is illustrative, to foster this > very >>>>> discussion around the idea that we can shoot for a favorite case > and >>>>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >>>>> think that the GW assumption is not reasonable, then, fine, let us >>>>> affect 2 bits in HC3 to indicate whether the addresses are >>> compressed. >>>>> What do the others think? >>>>> >>>>> Pascal >>>>>> -----Original Message----- >>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>> Sent: mardi 4 mars 2008 18:05 >>>>>> To: Pascal Thubert (pthubert) >>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>> >>>>>> >>>>>> Hi Pascal, >>>>>> >>>>>> Thanks for sharing your thoughts. >>>>>> >>>>>> By assuming the first 5 bits in HC1 are '1', you're staking a > claim >>>>> that >>>>>> mesh-under link-local communication within a PAN is going to be > most >>>>>> common case and the one we've "shot for". If link-local is all we >>> focus >>>>>> on, then we are missing the point of IP. Frankly, I don't see much >>>>>> benefit of IP if communication is limited to the PAN. >>>>>> >>>>>> W.r.t mesh-under, there are efforts within the IETF that assume >>> 6LoWPAN >>>>>> nodes will communicate via route-over using routable addresses > (e.g. >>>>>> ROLL). This brings us back to a broader topic of route-under vs. >>>>>> mesh-under. While both will probably exist for some time, it > raises >>> the >>>>>> question of whether 6LoWPAN implementations can support one or do >>> they >>>>>> have to support both. >>>>>> >>>>>> W.r.t compressing Hop Limit, I don't quite understand why you're >>> using >>>>> a >>>>>> bit in HC3 to indicate where the message originated. If you're >>> assuming >>>>>> link-local communication, then messages shouldn't be forwarded >>> across >>>>>> links anyway. >>>>>> >>>>>> I do agree that there is work to do on compression and agree that >>> there >>>>>> are cases where HC1 and HC2 are not sufficient. This is why I've >>> been >>>>>> working, albeit slowly, on HC1g. >>>>>> >>>>>> -- >>>>>> Jonathan Hui >>>>>> >>>>>> >>>>>> Pascal Thubert (pthubert) wrote: >>>>>>> Dear 6LoWPANers, >>>>>>> >>>>>>> Though HC1 and HC2 provide us with the capability to express any >>>>>>> combination of compression, the most expected (or at least shot >>> for) >>>>>>> case does not lead to a better compression of the HC headers >>>>> themselves. >>>>>>> Seems that we could define an HC3 that would compress the pair of >>> HC1 >>>>>>> and HC2 for that best case. My proposal for doing this would be > to: >>>>>>> - define a new dispatch >>>>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 > and >>>>>>> transport >>>>>>> >>>>>>> - define HC3 itself to: >>>>>>> >>>>>>> - implicitly say that the first 5 bits of HC1 are all ones >>>>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>>>> - replace HC2 so bit 7 of HC1 is useless >>>>>>> - provide transport specific bits such as those defined for >>>>>>> HC-UDP, >>>>>>> then again assuming a predefined best case if room is >>> missing >>>>>>> An example of what the HC3 octet could be: >>>>>>> >>>>>>> bits 0 1 2-3 >>>>>>> 4-7 >>>>>>> >>>>>>> > +------------------+-------------+-----------------+-------------------- >>>>>>> ---------------------+ >>>>>>> | reserved | reserved | Next Header | >>>>> transport >>>>>>> specific control bits | >>>>>>> >>>>>>> > +------------------+-------------+-----------------+-------------------- >>>>>>> ---------------------+ >>>>>>> >>>>>>> Next header: as defined in HC1, bits 5 and 6 >>>>>>> >>>>>>> transport specific control bits for UDP: >>>>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>>>> bit 7 is reserved >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> Pascal >>>>>>> _______________________________________________ >>>>>>> 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 Mar 5 09:41:36 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049363A6F09; Wed, 5 Mar 2008 09:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 7KqWVioetLri; Wed, 5 Mar 2008 09:41:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35A63A6BED; Wed, 5 Mar 2008 09:41:31 -0800 (PST) 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 47CF528C234 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 09:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 7u8w7X+LLgGs for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 09:41:28 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 60D613A6BED for <6lowpan@ietf.org>; Wed, 5 Mar 2008 09:41:27 -0800 (PST) Received: from [192.168.0.74] (addr-213-139-165-97.baananet.fi [213.139.165.97]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m25Hf26A013396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2008 19:41:03 +0200 Message-ID: <47CEDB2F.3030209@sensinode.com> Date: Wed, 05 Mar 2008 19:41:03 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Jonathan Hui References: <7892795E1A87F04CADFCCF41FADD00FC054832F7@xmb-ams-337.emea.cisco.com> <47CE905A.6090802@sensinode.com> <47CEC9BA.9060909@archrock.com> In-Reply-To: <47CEC9BA.9060909@archrock.com> Cc: Jay Werb , 6lowpan <6lowpan@ietf.org>, enns@stanfordalumni.org Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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 Guys, I also would not like specialized solutions for mesh-under and route-over, and in fact with ROLL certainly going L3.. I am foreseeing already that the 6lowpan Mesh Header will depreciate eventually. So I agree with Jonathan that we need to allow for routing using (compressed) L3 addresses, and any further compression option should allow for this. I would encourage a combined HC3/HC1g which allows for route-over for current usage and UDP Checksum eliding combining the most common compression options. HC1g has been slow coming along, maybe this combination would give it the wider support needed? We are currently using the 6lowpan Mesh Header for routing but also employ ICMP messages with IPv6 hop-limit decrements, so it is really just a matter of where to store the addresses. Whose idea was the mesh header in the first place? ;-) It has at least used up tons of IETF mailing list bandwidth! - Zach Jonathan Hui wrote: > > Hi Zach. See below: > > Zach Shelby wrote: >> Very nice discussion. >> >> I see the logic in going after a more aggressive HC3 compression for >> use within the 6lowpan network. It also would incorporate elided CRC >> which I would also like to see it for local use. So far from my >> implementation and use experience HC3 would cover 95% of our use of >> 6lowpan. > > This completely depends on how you implement your 6LoWPAN network. I can > see how HC3 would work well for mesh-under networks where one or more > 802.15.4 networks are abstracted as a single IP link. However, HC3 does > not work well if we assume route-over, where every link/radio hop is an > IP hop. Because I've been working with route-over networks, I can say > that HC3 is insufficient for 95% of my use cases. > >> Why wouldn't the HC3 proposal work with both mesh under or route over? >> e.g. MANET routing protocols are also mainly using flat IP addressing >> within the MANET. So in reality route-over would likely use the MAC >> address of the interface and elide the IPv6 address when using 6lowpan >> at least, just as in 6lowpan "mesh under" as long as the destination >> address is in the same subnet. It would be quite easy to switch to >> HC1+HC2 or HC1g in the case that you detect that the destination >> address has a different non link-local prefix. Please correct me if I >> am wrong here... > > In my view, one difference between mesh-under and route-over is whether > or not the 6LoWPAN Mesh Addressing header is used. In mesh-under, the > Mesh Addressing header is used to deliver a datagram over multiple L2 > hops but only a single IP hop, and when link-local addresses are used, > both addresses in the IP header can be completely elided. In route-over, > no Mesh Addressing header is used, every L2 hop is an IP hop, and the > source and destination addresses are carried directly in the IP header. > > Given this difference, I don't see how HC3 would support carrying > addresses in the IP header. Now, as you state, ad-hoc routing does often > boil down to host based routing. For that very point, I think the > difference between forwarding at L2 vs. forwarding at L3 is less than we > think. At some level, it's about where do the addresses go. The goal of > HC1g is to provide a way to express both extended and short addresses in > the IP header, with the assumption that the Mesh Addressing header will > not be used. > > -- > Jonathan Hui > >> Of course both HC3 and HC1g would be needed in such networks, as HC1g >> allows us to communicate outside the 6lowpan network with minimal >> overhead. So I am in favor of both. Of course there is the question if >> we would have a place for HC3 in the new charter? >> >> - Zach >> >> Pascal Thubert (pthubert) wrote: >>> Hi Jonathan: >>> >>> You are assuming explicitly that I am assuming implicitly... mesh >>> under... Hum. >>> >>> Please have a look at >>> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>> -00.txt and it should be apparent that I'm not. In particular the >>> backbone router is the device that will set and use the hop limit bit. >>> So will all those interconnecting devices used in pseudowire, split >>> bridges, IP Mobility, etc... if they are deployed in this space. >>> >>> What I'm really assuming is a gateway or an edge server on the link. >>> It's there in most architectures that I know of at this point that's why >>> I included it in the case we shoot for and saved 2 bits. Note that when >>> the ULA and global addresses are used on top of link local, it makes >>> sense that we define a mechanism to compress them as well. But this is >>> not what HC3 is about. >>> >>> The goal of my initial proposal is illustrative, to foster this very >>> discussion around the idea that we can shoot for a favorite case and >>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >>> think that the GW assumption is not reasonable, then, fine, let us >>> affect 2 bits in HC3 to indicate whether the addresses are compressed. >>> What do the others think? >>> >>> Pascal >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: mardi 4 mars 2008 18:05 >>>> To: Pascal Thubert (pthubert) >>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>> >>>> >>>> Hi Pascal, >>>> >>>> Thanks for sharing your thoughts. >>>> >>>> By assuming the first 5 bits in HC1 are '1', you're staking a claim >>> that >>>> mesh-under link-local communication within a PAN is going to be most >>>> common case and the one we've "shot for". If link-local is all we focus >>>> on, then we are missing the point of IP. Frankly, I don't see much >>>> benefit of IP if communication is limited to the PAN. >>>> >>>> W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN >>>> nodes will communicate via route-over using routable addresses (e.g. >>>> ROLL). This brings us back to a broader topic of route-under vs. >>>> mesh-under. While both will probably exist for some time, it raises the >>>> question of whether 6LoWPAN implementations can support one or do they >>>> have to support both. >>>> >>>> W.r.t compressing Hop Limit, I don't quite understand why you're using >>> a >>>> bit in HC3 to indicate where the message originated. If you're assuming >>>> link-local communication, then messages shouldn't be forwarded across >>>> links anyway. >>>> >>>> I do agree that there is work to do on compression and agree that there >>>> are cases where HC1 and HC2 are not sufficient. This is why I've been >>>> working, albeit slowly, on HC1g. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> Pascal Thubert (pthubert) wrote: >>>>> Dear 6LoWPANers, >>>>> >>>>> Though HC1 and HC2 provide us with the capability to express any >>>>> combination of compression, the most expected (or at least shot for) >>>>> case does not lead to a better compression of the HC headers >>> themselves. >>>>> Seems that we could define an HC3 that would compress the pair of HC1 >>>>> and HC2 for that best case. My proposal for doing this would be to: >>>>> >>>>> - define a new dispatch >>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>>>> transport >>>>> >>>>> - define HC3 itself to: >>>>> >>>>> - implicitly say that the first 5 bits of HC1 are all ones >>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>> - replace HC2 so bit 7 of HC1 is useless >>>>> - provide transport specific bits such as those defined for >>>>> HC-UDP, >>>>> then again assuming a predefined best case if room is missing >>>>> >>>>> An example of what the HC3 octet could be: >>>>> >>>>> bits 0 1 2-3 >>>>> 4-7 >>>>> >>>>> >>> +------------------+-------------+-----------------+-------------------- >>>>> ---------------------+ >>>>> | reserved | reserved | Next Header | >>> transport >>>>> specific control bits | >>>>> >>>>> >>> +------------------+-------------+-----------------+-------------------- >>>>> ---------------------+ >>>>> >>>>> Next header: as defined in HC1, bits 5 and 6 >>>>> >>>>> transport specific control bits for UDP: >>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>> bit 7 is reserved >>>>> >>>>> What do you think? >>>>> >>>>> Pascal >>>>> _______________________________________________ >>>>> 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 | CTO | +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 Wed Mar 5 10:10:12 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BE028C2CF; Wed, 5 Mar 2008 10:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 fBb7Qf78wgaj; Wed, 5 Mar 2008 10:10:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C7D33A6CA5; Wed, 5 Mar 2008 10:10:10 -0800 (PST) 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 B20993A6AB5 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 10:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 yqT-ZIH3A8Vt for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 10:10:07 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 340C43A6CA5 for <6lowpan@ietf.org>; Wed, 5 Mar 2008 10:10:07 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 7D76BA9339; Wed, 5 Mar 2008 10:09:57 -0800 (PST) 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 fFt1eglZO5QM; Wed, 5 Mar 2008 10:09:50 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 2A6B0A932B; Wed, 5 Mar 2008 10:09:50 -0800 (PST) Message-ID: <47CEE1EA.80305@archrock.com> Date: Wed, 05 Mar 2008 10:09:46 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Zach Shelby References: <7892795E1A87F04CADFCCF41FADD00FC054832F7@xmb-ams-337.emea.cisco.com> <47CE905A.6090802@sensinode.com> <47CEC9BA.9060909@archrock.com> <47CEDB2F.3030209@sensinode.com> In-Reply-To: <47CEDB2F.3030209@sensinode.com> Cc: Jay Werb , 6lowpan <6lowpan@ietf.org>, enns@stanfordalumni.org Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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, I agree that we should have an approach that supports both mesh-under and route-over. I also think there is hope for us to get there. In moving toward that direction, I can rev the HC1g draft and incorporate some of the ideas mentioned recently on this list. I can incorporate the UDP checksum optimization, that is easy to do as HC1g uses the same HC2 header. I can also work with Pascal to find a way in incorporating his suggestions. In this case, the name will probably change from HC1g since it's no longer just about routable addresses. I wasn't able to generate much discussion about the initial draft on HC1g, so hopefully the new rev will stimulate more discussion :-). -- Jonathan Hui Zach Shelby wrote: > Guys, > > I also would not like specialized solutions for mesh-under and > route-over, and in fact with ROLL certainly going L3.. I am foreseeing > already that the 6lowpan Mesh Header will depreciate eventually. > > So I agree with Jonathan that we need to allow for routing using > (compressed) L3 addresses, and any further compression option should > allow for this. I would encourage a combined HC3/HC1g which allows for > route-over for current usage and UDP Checksum eliding combining the most > common compression options. HC1g has been slow coming along, maybe this > combination would give it the wider support needed? > > We are currently using the 6lowpan Mesh Header for routing but also > employ ICMP messages with IPv6 hop-limit decrements, so it is really > just a matter of where to store the addresses. Whose idea was the mesh > header in the first place? ;-) It has at least used up tons of IETF > mailing list bandwidth! > > - Zach > > Jonathan Hui wrote: >> >> Hi Zach. See below: >> >> Zach Shelby wrote: >>> Very nice discussion. >>> >>> I see the logic in going after a more aggressive HC3 compression for >>> use within the 6lowpan network. It also would incorporate elided CRC >>> which I would also like to see it for local use. So far from my >>> implementation and use experience HC3 would cover 95% of our use of >>> 6lowpan. >> >> This completely depends on how you implement your 6LoWPAN network. I >> can see how HC3 would work well for mesh-under networks where one or >> more 802.15.4 networks are abstracted as a single IP link. However, >> HC3 does not work well if we assume route-over, where every link/radio >> hop is an IP hop. Because I've been working with route-over networks, >> I can say that HC3 is insufficient for 95% of my use cases. >> >>> Why wouldn't the HC3 proposal work with both mesh under or route >>> over? e.g. MANET routing protocols are also mainly using flat IP >>> addressing within the MANET. So in reality route-over would likely >>> use the MAC address of the interface and elide the IPv6 address when >>> using 6lowpan at least, just as in 6lowpan "mesh under" as long as >>> the destination address is in the same subnet. It would be quite easy >>> to switch to HC1+HC2 or HC1g in the case that you detect that the >>> destination address has a different non link-local prefix. Please >>> correct me if I am wrong here... >> >> In my view, one difference between mesh-under and route-over is >> whether or not the 6LoWPAN Mesh Addressing header is used. In >> mesh-under, the Mesh Addressing header is used to deliver a datagram >> over multiple L2 hops but only a single IP hop, and when link-local >> addresses are used, both addresses in the IP header can be completely >> elided. In route-over, no Mesh Addressing header is used, every L2 hop >> is an IP hop, and the source and destination addresses are carried >> directly in the IP header. >> >> Given this difference, I don't see how HC3 would support carrying >> addresses in the IP header. Now, as you state, ad-hoc routing does >> often boil down to host based routing. For that very point, I think >> the difference between forwarding at L2 vs. forwarding at L3 is less >> than we think. At some level, it's about where do the addresses go. >> The goal of HC1g is to provide a way to express both extended and >> short addresses in the IP header, with the assumption that the Mesh >> Addressing header will >> not be used. >> >> -- >> Jonathan Hui >> >>> Of course both HC3 and HC1g would be needed in such networks, as HC1g >>> allows us to communicate outside the 6lowpan network with minimal >>> overhead. So I am in favor of both. Of course there is the question >>> if we would have a place for HC3 in the new charter? >>> >>> - Zach >>> >>> Pascal Thubert (pthubert) wrote: >>>> Hi Jonathan: >>>> >>>> You are assuming explicitly that I am assuming implicitly... mesh >>>> under... Hum. >>>> >>>> Please have a look at >>>> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>>> >>>> -00.txt and it should be apparent that I'm not. In particular the >>>> backbone router is the device that will set and use the hop limit bit. >>>> So will all those interconnecting devices used in pseudowire, split >>>> bridges, IP Mobility, etc... if they are deployed in this space. >>>> >>>> What I'm really assuming is a gateway or an edge server on the link. >>>> It's there in most architectures that I know of at this point that's >>>> why >>>> I included it in the case we shoot for and saved 2 bits. Note that when >>>> the ULA and global addresses are used on top of link local, it makes >>>> sense that we define a mechanism to compress them as well. But this is >>>> not what HC3 is about. >>>> >>>> The goal of my initial proposal is illustrative, to foster this very >>>> discussion around the idea that we can shoot for a favorite case and >>>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >>>> think that the GW assumption is not reasonable, then, fine, let us >>>> affect 2 bits in HC3 to indicate whether the addresses are compressed. >>>> What do the others think? >>>> >>>> Pascal >>>>> -----Original Message----- >>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>> Sent: mardi 4 mars 2008 18:05 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>> >>>>> >>>>> Hi Pascal, >>>>> >>>>> Thanks for sharing your thoughts. >>>>> >>>>> By assuming the first 5 bits in HC1 are '1', you're staking a claim >>>> that >>>>> mesh-under link-local communication within a PAN is going to be most >>>>> common case and the one we've "shot for". If link-local is all we >>>>> focus >>>>> on, then we are missing the point of IP. Frankly, I don't see much >>>>> benefit of IP if communication is limited to the PAN. >>>>> >>>>> W.r.t mesh-under, there are efforts within the IETF that assume >>>>> 6LoWPAN >>>>> nodes will communicate via route-over using routable addresses (e.g. >>>>> ROLL). This brings us back to a broader topic of route-under vs. >>>>> mesh-under. While both will probably exist for some time, it raises >>>>> the >>>>> question of whether 6LoWPAN implementations can support one or do they >>>>> have to support both. >>>>> >>>>> W.r.t compressing Hop Limit, I don't quite understand why you're using >>>> a >>>>> bit in HC3 to indicate where the message originated. If you're >>>>> assuming >>>>> link-local communication, then messages shouldn't be forwarded across >>>>> links anyway. >>>>> >>>>> I do agree that there is work to do on compression and agree that >>>>> there >>>>> are cases where HC1 and HC2 are not sufficient. This is why I've been >>>>> working, albeit slowly, on HC1g. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> Pascal Thubert (pthubert) wrote: >>>>>> Dear 6LoWPANers, >>>>>> >>>>>> Though HC1 and HC2 provide us with the capability to express any >>>>>> combination of compression, the most expected (or at least shot for) >>>>>> case does not lead to a better compression of the HC headers >>>> themselves. >>>>>> Seems that we could define an HC3 that would compress the pair of HC1 >>>>>> and HC2 for that best case. My proposal for doing this would be to: >>>>>> >>>>>> - define a new dispatch >>>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>>>>> transport >>>>>> >>>>>> - define HC3 itself to: >>>>>> >>>>>> - implicitly say that the first 5 bits of HC1 are all ones >>>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>>> - replace HC2 so bit 7 of HC1 is useless >>>>>> - provide transport specific bits such as those defined for >>>>>> HC-UDP, >>>>>> then again assuming a predefined best case if room is missing >>>>>> >>>>>> An example of what the HC3 octet could be: >>>>>> >>>>>> bits 0 1 2-3 >>>>>> 4-7 >>>>>> >>>>>> >>>> +------------------+-------------+-----------------+-------------------- >>>> >>>>>> ---------------------+ >>>>>> | reserved | reserved | Next Header | >>>> transport >>>>>> specific control bits | >>>>>> >>>>>> >>>> +------------------+-------------+-----------------+-------------------- >>>> >>>>>> ---------------------+ >>>>>> >>>>>> Next header: as defined in HC1, bits 5 and 6 >>>>>> >>>>>> transport specific control bits for UDP: >>>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>>> bit 7 is reserved >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Pascal >>>>>> _______________________________________________ >>>>>> 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 Mar 5 11:29:51 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D94E28C5D1; Wed, 5 Mar 2008 11:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 pzHTVNb6CoGC; Wed, 5 Mar 2008 11:29:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B53B3A6D2D; Wed, 5 Mar 2008 11:29:49 -0800 (PST) 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 7D8953A6ADF for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 11:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 XZHk1m0Z2FrL for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 11:29:43 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0B5C83A6D1B for <6lowpan@ietf.org>; Wed, 5 Mar 2008 11:29:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,451,1199660400"; d="scan'208";a="2635110" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2008 20:29:22 +0100 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 m25JTMel012572; Wed, 5 Mar 2008 20:29:22 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m25JTAHM006752; Wed, 5 Mar 2008 19:29:22 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); Wed, 5 Mar 2008 20:29:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 20:28:44 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC054836B4@xmb-ams-337.emea.cisco.com> In-Reply-To: <47CED8F4.5080802@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Compressing HC1 and HC2 into HC3 thread-index: Ach+5wrLlnYgLUejQ/S724kn6tV8RwABBGpg From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 05 Mar 2008 19:29:16.0640 (UTC) FILETIME=[33847600:01C87EF7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12571; t=1204745362; x=1205609362; 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]=20Compressing=20HC1=20and=20H C2=20into=20HC3 |Sender:=20; bh=URefHmWE18l5yD6v9bFsPn6vwMxhsw3CUP+su8X5vSs=; b=U7jCOOUmPX8rOjJ5XleIYAxmphAVZ92Osmgpq/K7leKqQ1VEKDKb3L+Byt zFuHKjMKATpS9b0HVC9DiudFPu9bOhTf7sYuUKYbC6+o57b0dFtrtPEyc9FF KbIY7ZXB1K; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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'm not sure ROLL precludes the idea of prefix and aggregation, so I'm not sure every node operates as a router, not even than every node can operate as a router. In fact I'm not even sure that every forwarding node performs routing computations either. I think that ROLL is what we have not made it yet. We are in sync on what HC1g does and why; that makes all the sense in the world to me and you've got my support and help if needed. My question was really what is the HG1g pattern that you expect most times? I mean, if you propose a compression mechanism you intend to use it. And I'd say heavily. If I follow you well: - It seems obvious that the local address suffix can be compressed if it is based on EUI-64 or is unambiguously associated to a 16 bits address using states somewhere (nd, reverse-ND, ...). The prefix can be compressed if it is the only one on-link, or then again unambiguously associated to a 16-bits address. I'd assume that for both, considering the value of compressing, people will make sure that the conditions are met for the compression to happen. - It seems pretty obvious too that the remote address will not be compressed: if it was on-link the nodes could and should use link local addresses; So it is arbitrary. So the answer I expect for my question above is that you expect that most times we will fully compress the local address and not at all the remote address. Would that be your guess too? Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mercredi 5 mars 2008 18:32 >To: Pascal Thubert (pthubert) >Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 > > >Hi Pascal, see below: > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >> I'm certainly not willing to specialize HC3 to mesh-under whatever your >> definition of the term. I'm willing to specialize HC3 to elide a number >> off "always on" bits so that when these bits are on, HC3 is used instead >> of HC1 and HC2. I hope this much is clear by now. > >Yes, this is clear now. > >> Consider this: even HC1g is specialized; it is specilized to the case >> when only the terminating networks are LoWPANs. For instance, how do you >> compress a packet in a LoWPAN that would sit between the source LoWPAN >> and the destination LoWPAN - that's ROLL for you? > >I never said that HC1g wasn't specialized. Any compression scheme must >make assumptions about the underlying pattern, otherwise there is no >compression to be had. > >ROLL for me is where every node operates as an IP router. HC1g is trying >to address a PAN where each L2 hop is an IP hop. However, it is not >trying to address cases where the PAN is a transit network for external >networks that can have arbitrary prefixes. In other words, any messages >going into the PAN will be destined for those nodes in the PAN, and >similarly any messages leaving the PAN will be sourced by a node in the >PAN. But in both cases, the addresses used are routable addresses. This >is the case I'm shooting for. Is this scenario realistic to you? > >-- >Jonathan Hui > >> Like I said in another mail, this is a pretty difficult issue, maybe >> more complex than laying labels. My point is we do not know what ROLL >> will be made of; it will certainly be very interesting but it would be >> hazardous at this point to reserve bits for assumptions we could make on >> it. >> >> Let's look at what we have, which are the most important toggles and fit >> those in HC3. I'll be glad to define that the address that designs a >> node on this LoWPAN (the local address) is elided but is not a >> link-local-address and that the remote address is not elided. Or >> something else that makes sense like the local address is elided and is >> the one that unabiguously matches the scope of the remote address. >> >> So what's the case you're shooting for? >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: mercredi 5 mars 2008 17:31 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>> >>> >>> I think it's fair to say that we should continue working on IP header >>> compression. However, I also think we must evaluate whether we are >>> willing to specialize such compression schemes for route-over vs. >>> mesh-under networks. I don't have a problem with such specialization, >>> but I would have a problem if we required any 6LoWPAN implementation to >>> support specialized schemes for both mesh-under and route-over >>> simultaneously. >>> >>> -- >>> Jonathan Hui >>> >>> >>> Pascal Thubert (pthubert) wrote: >>>> Hi Jonathan >>>> >>>> I agree it's great we are having this discussion :) >>>> >>>> Multiple thread could spawn from it because there are multiple topic. >>>> And some of this might belong to ROLL as you pointed out earlier. >>>> >>>> I'd wish to keep this thread for its original question on whether it >> is >>>> desirable, in the context of what we already have, to further >> compress >>>> HC1 and HC2 into a single HC3. For that specific thread, I retain >> that >>>> you do not oppose but that you vote for retaining some information on >>>> whether the addresses are elided or not. >>>> >>>> Is that fair? >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>> Sent: mercredi 5 mars 2008 09:28 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>> >>>>> >>>>> Regarding the GW assumption on the link, I think we need to take a >> step >>>>> back for a second. While it is true that most architectures up until >>>>> this point follow this assumption, most architectures that I know of >>>>> haven't been built using IP. ZigBee nodes, for example, only >>>> communicate >>>>> with ZigBee nodes at every hop and there isn't any effort to do >>>>> internetworking. >>>>> >>>>> But now that we actually have IP, we are no longer constrained to a >>>>> single link technology. Rather, nodes can communicate with each >> other, >>>>> directly using 802.15.4, or over other technologies such as WiFi, >>>>> Ethernet, GPRS, etc. This really opens up the network architecture >>>>> possibilities, and there are many cases where adding these >> additional >>>>> links are desirable. I know that ISA's proposed backbone routers >>>> provide >>>>> this functionality, but I'd rather support such networks at the IP >>>>> layer, rather than abstracting a combination of link technologies as >>>>> single IP link and defining any new machinery to do so. >>>>> >>>>> BTW it's great that we're having this discussion. It is long >> overdue. >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> Pascal Thubert (pthubert) wrote: >>>>>> Hi Jonathan: >>>>>> >>>>>> You are assuming explicitly that I am assuming implicitly... mesh >>>>>> under... Hum. >>>>>> >>>>>> Please have a look at >>>>>> >> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>>>>> -00.txt and it should be apparent that I'm not. In particular the >>>>>> backbone router is the device that will set and use the hop limit >>>> bit. >>>>>> So will all those interconnecting devices used in pseudowire, split >>>>>> bridges, IP Mobility, etc... if they are deployed in this space. >>>>>> >>>>>> What I'm really assuming is a gateway or an edge server on the >> link. >>>>>> It's there in most architectures that I know of at this point >> that's >>>> why >>>>>> I included it in the case we shoot for and saved 2 bits. Note that >>>> when >>>>>> the ULA and global addresses are used on top of link local, it >> makes >>>>>> sense that we define a mechanism to compress them as well. But this >>>> is >>>>>> not what HC3 is about. >>>>>> >>>>>> The goal of my initial proposal is illustrative, to foster this >> very >>>>>> discussion around the idea that we can shoot for a favorite case >> and >>>>>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >>>>>> think that the GW assumption is not reasonable, then, fine, let us >>>>>> affect 2 bits in HC3 to indicate whether the addresses are >>>> compressed. >>>>>> What do the others think? >>>>>> >>>>>> Pascal >>>>>>> -----Original Message----- >>>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>>> Sent: mardi 4 mars 2008 18:05 >>>>>>> To: Pascal Thubert (pthubert) >>>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>>> >>>>>>> >>>>>>> Hi Pascal, >>>>>>> >>>>>>> Thanks for sharing your thoughts. >>>>>>> >>>>>>> By assuming the first 5 bits in HC1 are '1', you're staking a >> claim >>>>>> that >>>>>>> mesh-under link-local communication within a PAN is going to be >> most >>>>>>> common case and the one we've "shot for". If link-local is all we >>>> focus >>>>>>> on, then we are missing the point of IP. Frankly, I don't see much >>>>>>> benefit of IP if communication is limited to the PAN. >>>>>>> >>>>>>> W.r.t mesh-under, there are efforts within the IETF that assume >>>> 6LoWPAN >>>>>>> nodes will communicate via route-over using routable addresses >> (e.g. >>>>>>> ROLL). This brings us back to a broader topic of route-under vs. >>>>>>> mesh-under. While both will probably exist for some time, it >> raises >>>> the >>>>>>> question of whether 6LoWPAN implementations can support one or do >>>> they >>>>>>> have to support both. >>>>>>> >>>>>>> W.r.t compressing Hop Limit, I don't quite understand why you're >>>> using >>>>>> a >>>>>>> bit in HC3 to indicate where the message originated. If you're >>>> assuming >>>>>>> link-local communication, then messages shouldn't be forwarded >>>> across >>>>>>> links anyway. >>>>>>> >>>>>>> I do agree that there is work to do on compression and agree that >>>> there >>>>>>> are cases where HC1 and HC2 are not sufficient. This is why I've >>>> been >>>>>>> working, albeit slowly, on HC1g. >>>>>>> >>>>>>> -- >>>>>>> Jonathan Hui >>>>>>> >>>>>>> >>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>> Dear 6LoWPANers, >>>>>>>> >>>>>>>> Though HC1 and HC2 provide us with the capability to express any >>>>>>>> combination of compression, the most expected (or at least shot >>>> for) >>>>>>>> case does not lead to a better compression of the HC headers >>>>>> themselves. >>>>>>>> Seems that we could define an HC3 that would compress the pair of >>>> HC1 >>>>>>>> and HC2 for that best case. My proposal for doing this would be >> to: >>>>>>>> - define a new dispatch >>>>>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 >> and >>>>>>>> transport >>>>>>>> >>>>>>>> - define HC3 itself to: >>>>>>>> >>>>>>>> - implicitly say that the first 5 bits of HC1 are all ones >>>>>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>>>>> - replace HC2 so bit 7 of HC1 is useless >>>>>>>> - provide transport specific bits such as those defined for >>>>>>>> HC-UDP, >>>>>>>> then again assuming a predefined best case if room is >>>> missing >>>>>>>> An example of what the HC3 octet could be: >>>>>>>> >>>>>>>> bits 0 1 2-3 >>>>>>>> 4-7 >>>>>>>> >>>>>>>> >> +------------------+-------------+-----------------+-------------------- >>>>>>>> ---------------------+ >>>>>>>> | reserved | reserved | Next Header | >>>>>> transport >>>>>>>> specific control bits | >>>>>>>> >>>>>>>> >> +------------------+-------------+-----------------+-------------------- >>>>>>>> ---------------------+ >>>>>>>> >>>>>>>> Next header: as defined in HC1, bits 5 and 6 >>>>>>>> >>>>>>>> transport specific control bits for UDP: >>>>>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>>>>> bit 7 is reserved >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> Pascal >>>>>>>> _______________________________________________ >>>>>>>> 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 Mar 5 12:14:55 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7001E28C657; Wed, 5 Mar 2008 12:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.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 VJdZIN5qBu0l; Wed, 5 Mar 2008 12:14:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADF5128C802; Wed, 5 Mar 2008 12:14:48 -0800 (PST) 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 8B7EF28C6B7 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 12:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 aGM2u010mutj for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 12:14:46 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 4A97828C58F for <6lowpan@ietf.org>; Wed, 5 Mar 2008 12:14:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 8B57AA9301; Wed, 5 Mar 2008 12:14:22 -0800 (PST) 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 xpjOqyW8mINZ; Wed, 5 Mar 2008 12:14:15 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 4866EA92FC; Wed, 5 Mar 2008 12:14:13 -0800 (PST) Message-ID: <47CEFF0C.1020705@archrock.com> Date: Wed, 05 Mar 2008 12:14:04 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC054836B4@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC054836B4@xmb-ams-337.emea.cisco.com> Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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 Thubert (pthubert) wrote: > We are in sync on what HC1g does and why; that makes all the sense in > the world to me and you've got my support and help if needed. My > question was really what is the HG1g pattern that you expect most times? > I mean, if you propose a compression mechanism you intend to use it. And > I'd say heavily. If I follow you well: HC1g assumes the following: - IID is either derived directly from EUI-64 or short address. - All nodes within a PAN are assigned a single common routable prefix. For demonstration purposes, let's first assume that every node acts as an L3 forwarder. In this case, no Mesh Addressing header is used and compressed addresses are carried in the compressed L3 header. - For communication that stays within the PAN, there is between 4 and 16 bytes for L3 compressed addresses depending on whether the IID is derived from the short or extended address. The resulting compressed L3 header is as small as 6 bytes (HC1, hlim, src, dst). - For communication that crosses the PAN boundary, one of the IP addresses is always compressed and the other is not compressed. Although, I am planning to put in provisions to allow stateful compression by using a reserved short address range as defined in RFC4944 similar to how I've proposed to compress well-known multicast addresses. The resulting compressed L3 header is 20 bytes, but only 6 bytes if stateful compression is used. - When the communication occurs over a single IP hop, then the IIDs can be completely compressed and the resulting compressed IP header does not contain any addressing information. This also works when L2 forwarding occurs and the Mesh Addressing header is used. The resulting compressed L3 header is only 2 bytes (HC1, hlim). - To support both link-local and the common routable prefix, two different dispatch values are used. I was originally thinking that the same compression format could be used in both cases. But, as you point out, we might have greater optimizations here. The nice thing with the same compression format is that the same parsing code path can be used for both link-local and routable cases, but comes at the cost of one additional byte per datagram. So there is a tradeoff between code-size and compression efficiency, as discussed early in this thread. Do you think this is a reasonable approach? -- Jonathan Hui > > - It seems obvious that the local address suffix can be compressed if it > is based on EUI-64 or is unambiguously associated to a 16 bits address > using states somewhere (nd, reverse-ND, ...). The prefix can be > compressed if it is the only one on-link, or then again unambiguously > associated to a 16-bits address. I'd assume that for both, considering > the value of compressing, people will make sure that the conditions are > met for the compression to happen. > > - It seems pretty obvious too that the remote address will not be > compressed: if it was on-link the nodes could and should use link local > addresses; So it is arbitrary. So the answer I expect for my question > above is that you expect that most times we will fully compress the > local address and not at all the remote address. > > Would that be your guess too? > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: mercredi 5 mars 2008 18:32 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >> >> >> Hi Pascal, see below: >> >> Pascal Thubert (pthubert) wrote: >>> Hi Jonathan: >>> >>> I'm certainly not willing to specialize HC3 to mesh-under whatever > your >>> definition of the term. I'm willing to specialize HC3 to elide a > number >>> off "always on" bits so that when these bits are on, HC3 is used > instead >>> of HC1 and HC2. I hope this much is clear by now. >> Yes, this is clear now. >> >>> Consider this: even HC1g is specialized; it is specilized to the case >>> when only the terminating networks are LoWPANs. For instance, how do > you >>> compress a packet in a LoWPAN that would sit between the source > LoWPAN >>> and the destination LoWPAN - that's ROLL for you? >> I never said that HC1g wasn't specialized. Any compression scheme must >> make assumptions about the underlying pattern, otherwise there is no >> compression to be had. >> >> ROLL for me is where every node operates as an IP router. HC1g is > trying >> to address a PAN where each L2 hop is an IP hop. However, it is not >> trying to address cases where the PAN is a transit network for external >> networks that can have arbitrary prefixes. In other words, any messages >> going into the PAN will be destined for those nodes in the PAN, and >> similarly any messages leaving the PAN will be sourced by a node in the >> PAN. But in both cases, the addresses used are routable addresses. This >> is the case I'm shooting for. Is this scenario realistic to you? >> >> -- >> Jonathan Hui >> >>> Like I said in another mail, this is a pretty difficult issue, maybe >>> more complex than laying labels. My point is we do not know what ROLL >>> will be made of; it will certainly be very interesting but it would > be >>> hazardous at this point to reserve bits for assumptions we could make > on >>> it. >>> >>> Let's look at what we have, which are the most important toggles and > fit >>> those in HC3. I'll be glad to define that the address that designs a >>> node on this LoWPAN (the local address) is elided but is not a >>> link-local-address and that the remote address is not elided. Or >>> something else that makes sense like the local address is elided and > is >>> the one that unabiguously matches the scope of the remote address. >>> >>> So what's the case you're shooting for? >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: mercredi 5 mars 2008 17:31 >>>> To: Pascal Thubert (pthubert) >>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>> >>>> >>>> I think it's fair to say that we should continue working on IP > header >>>> compression. However, I also think we must evaluate whether we are >>>> willing to specialize such compression schemes for route-over vs. >>>> mesh-under networks. I don't have a problem with such > specialization, >>>> but I would have a problem if we required any 6LoWPAN implementation > to >>>> support specialized schemes for both mesh-under and route-over >>>> simultaneously. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> Pascal Thubert (pthubert) wrote: >>>>> Hi Jonathan >>>>> >>>>> I agree it's great we are having this discussion :) >>>>> >>>>> Multiple thread could spawn from it because there are multiple > topic. >>>>> And some of this might belong to ROLL as you pointed out earlier. >>>>> >>>>> I'd wish to keep this thread for its original question on whether > it >>> is >>>>> desirable, in the context of what we already have, to further >>> compress >>>>> HC1 and HC2 into a single HC3. For that specific thread, I retain >>> that >>>>> you do not oppose but that you vote for retaining some information > on >>>>> whether the addresses are elided or not. >>>>> >>>>> Is that fair? >>>>> >>>>> Pascal >>>>> >>>>>> -----Original Message----- >>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>> Sent: mercredi 5 mars 2008 09:28 >>>>>> To: Pascal Thubert (pthubert) >>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>> >>>>>> >>>>>> Regarding the GW assumption on the link, I think we need to take a >>> step >>>>>> back for a second. While it is true that most architectures up > until >>>>>> this point follow this assumption, most architectures that I know > of >>>>>> haven't been built using IP. ZigBee nodes, for example, only >>>>> communicate >>>>>> with ZigBee nodes at every hop and there isn't any effort to do >>>>>> internetworking. >>>>>> >>>>>> But now that we actually have IP, we are no longer constrained to > a >>>>>> single link technology. Rather, nodes can communicate with each >>> other, >>>>>> directly using 802.15.4, or over other technologies such as WiFi, >>>>>> Ethernet, GPRS, etc. This really opens up the network architecture >>>>>> possibilities, and there are many cases where adding these >>> additional >>>>>> links are desirable. I know that ISA's proposed backbone routers >>>>> provide >>>>>> this functionality, but I'd rather support such networks at the IP >>>>>> layer, rather than abstracting a combination of link technologies > as >>>>>> single IP link and defining any new machinery to do so. >>>>>> >>>>>> BTW it's great that we're having this discussion. It is long >>> overdue. >>>>>> -- >>>>>> Jonathan Hui >>>>>> >>>>>> >>>>>> Pascal Thubert (pthubert) wrote: >>>>>>> Hi Jonathan: >>>>>>> >>>>>>> You are assuming explicitly that I am assuming implicitly... mesh >>>>>>> under... Hum. >>>>>>> >>>>>>> Please have a look at >>>>>>> > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>>>>>> -00.txt and it should be apparent that I'm not. In particular the >>>>>>> backbone router is the device that will set and use the hop limit >>>>> bit. >>>>>>> So will all those interconnecting devices used in pseudowire, > split >>>>>>> bridges, IP Mobility, etc... if they are deployed in this space. >>>>>>> >>>>>>> What I'm really assuming is a gateway or an edge server on the >>> link. >>>>>>> It's there in most architectures that I know of at this point >>> that's >>>>> why >>>>>>> I included it in the case we shoot for and saved 2 bits. Note > that >>>>> when >>>>>>> the ULA and global addresses are used on top of link local, it >>> makes >>>>>>> sense that we define a mechanism to compress them as well. But > this >>>>> is >>>>>>> not what HC3 is about. >>>>>>> >>>>>>> The goal of my initial proposal is illustrative, to foster this >>> very >>>>>>> discussion around the idea that we can shoot for a favorite case >>> and >>>>>>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a > group >>>>>>> think that the GW assumption is not reasonable, then, fine, let > us >>>>>>> affect 2 bits in HC3 to indicate whether the addresses are >>>>> compressed. >>>>>>> What do the others think? >>>>>>> >>>>>>> Pascal >>>>>>>> -----Original Message----- >>>>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>>>> Sent: mardi 4 mars 2008 18:05 >>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>>>> >>>>>>>> >>>>>>>> Hi Pascal, >>>>>>>> >>>>>>>> Thanks for sharing your thoughts. >>>>>>>> >>>>>>>> By assuming the first 5 bits in HC1 are '1', you're staking a >>> claim >>>>>>> that >>>>>>>> mesh-under link-local communication within a PAN is going to be >>> most >>>>>>>> common case and the one we've "shot for". If link-local is all > we >>>>> focus >>>>>>>> on, then we are missing the point of IP. Frankly, I don't see > much >>>>>>>> benefit of IP if communication is limited to the PAN. >>>>>>>> >>>>>>>> W.r.t mesh-under, there are efforts within the IETF that assume >>>>> 6LoWPAN >>>>>>>> nodes will communicate via route-over using routable addresses >>> (e.g. >>>>>>>> ROLL). This brings us back to a broader topic of route-under vs. >>>>>>>> mesh-under. While both will probably exist for some time, it >>> raises >>>>> the >>>>>>>> question of whether 6LoWPAN implementations can support one or > do >>>>> they >>>>>>>> have to support both. >>>>>>>> >>>>>>>> W.r.t compressing Hop Limit, I don't quite understand why you're >>>>> using >>>>>>> a >>>>>>>> bit in HC3 to indicate where the message originated. If you're >>>>> assuming >>>>>>>> link-local communication, then messages shouldn't be forwarded >>>>> across >>>>>>>> links anyway. >>>>>>>> >>>>>>>> I do agree that there is work to do on compression and agree > that >>>>> there >>>>>>>> are cases where HC1 and HC2 are not sufficient. This is why I've >>>>> been >>>>>>>> working, albeit slowly, on HC1g. >>>>>>>> >>>>>>>> -- >>>>>>>> Jonathan Hui >>>>>>>> >>>>>>>> >>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>> Dear 6LoWPANers, >>>>>>>>> >>>>>>>>> Though HC1 and HC2 provide us with the capability to express > any >>>>>>>>> combination of compression, the most expected (or at least shot >>>>> for) >>>>>>>>> case does not lead to a better compression of the HC headers >>>>>>> themselves. >>>>>>>>> Seems that we could define an HC3 that would compress the pair > of >>>>> HC1 >>>>>>>>> and HC2 for that best case. My proposal for doing this would be >>> to: >>>>>>>>> - define a new dispatch >>>>>>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 >>> and >>>>>>>>> transport >>>>>>>>> >>>>>>>>> - define HC3 itself to: >>>>>>>>> >>>>>>>>> - implicitly say that the first 5 bits of HC1 are all > ones >>>>>>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>>>>>> - replace HC2 so bit 7 of HC1 is useless >>>>>>>>> - provide transport specific bits such as those defined > for >>>>>>>>> HC-UDP, >>>>>>>>> then again assuming a predefined best case if room is >>>>> missing >>>>>>>>> An example of what the HC3 octet could be: >>>>>>>>> >>>>>>>>> bits 0 1 2-3 >>>>>>>>> 4-7 >>>>>>>>> >>>>>>>>> > +------------------+-------------+-----------------+-------------------- >>>>>>>>> ---------------------+ >>>>>>>>> | reserved | reserved | Next Header | >>>>>>> transport >>>>>>>>> specific control bits | >>>>>>>>> >>>>>>>>> > +------------------+-------------+-----------------+-------------------- >>>>>>>>> ---------------------+ >>>>>>>>> >>>>>>>>> Next header: as defined in HC1, bits 5 and 6 >>>>>>>>> >>>>>>>>> transport specific control bits for UDP: >>>>>>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>>>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>>>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>>>>>> bit 7 is reserved >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> Pascal >>>>>>>>> _______________________________________________ >>>>>>>>> 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 Mar 5 13:57:47 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A98B28C808; Wed, 5 Mar 2008 13:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.643 X-Spam-Level: X-Spam-Status: No, score=-100.643 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 wXwaF+gxABYu; Wed, 5 Mar 2008 13:57:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0EDA28C6B7; Wed, 5 Mar 2008 13:57:42 -0800 (PST) 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 ECA0D28C609 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 13:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 uXU04QzjB968 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 13:57:39 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 42EC128C6B3 for <6lowpan@ietf.org>; Wed, 5 Mar 2008 13:57:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,452,1199660400"; d="scan'208";a="2643620" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2008 22:57:25 +0100 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 m25LvPtE016683; Wed, 5 Mar 2008 22:57:25 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m25LvPHC016124; Wed, 5 Mar 2008 21:57:25 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); Wed, 5 Mar 2008 22:57:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 22:53:55 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05483705@xmb-ams-337.emea.cisco.com> In-Reply-To: <47CEFF0C.1020705@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Compressing HC1 and HC2 into HC3 thread-index: Ach+/YMMTQy1qXwfQD6Bjem5iVM5jgAAfffQ From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 05 Mar 2008 21:57:25.0513 (UTC) FILETIME=[E5B2D790:01C87F0B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16015; t=1204754245; x=1205618245; 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]=20Compressing=20HC1=20and=20H C2=20into=20HC3 |Sender:=20; bh=9bAoJJHCAUbzTr8Bez7Vtv+hhG5GTkeMGF9GcvXUfKA=; b=uBtuYDhVqwHoVpJ1ZqctBdE/Cbf1lkFOLHibNGtcZspWRE7w8azxh0Txjk DFmUHjdWR1Cg00QydwFSae6tP1cMydtl0I/fl0m+RJRz8DFbw5V5puE1L84o sIStfPx4+Z; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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: >HC1g assumes the following: >- IID is either derived directly from EUI-64 or short address. >- All nodes within a PAN are assigned a single common routable prefix. [Pascal] yes, perfect. > >For demonstration purposes, let's first assume that every node acts as >an L3 forwarder. In this case, no Mesh Addressing header is used and >compressed addresses are carried in the compressed L3 header. > [Pascal] But if there's no mesh, why can't we pick the addresses from the MAC header? >- For communication that stays within the PAN, there is between 4 and 16 >bytes for L3 compressed addresses depending on whether the IID is >derived from the short or extended address. The resulting compressed L3 >header is as small as 6 bytes (HC1, hlim, src, dst). [Pascal] Why not use HC1 with link local in that case? Seems not a most probable case for HC3. >- For communication that crosses the PAN boundary, one of the IP >addresses is always compressed and the other is not compressed. [Pascal] makes sense. I guess that's the right case for HC3? >Although, I am planning to put in provisions to allow stateful >compression by using a reserved short address range as defined in >RFC4944 similar to how I've proposed to compress well-known multicast >addresses. The resulting compressed L3 header is 20 bytes, but only 6 >bytes if stateful compression is used. [Pascal] great but definitely further work. >- When the communication occurs over a single IP hop, then the IIDs can >be completely compressed and the resulting compressed IP header does not >contain any addressing information. This also works when L2 forwarding >occurs and the Mesh Addressing header is used. The resulting compressed >L3 header is only 2 bytes (HC1, hlim). [Pascal] I miss the rationale for the single IP hop... I must be tired :) > >- To support both link-local and the common routable prefix, two >different dispatch values are used. I was originally thinking that the >same compression format could be used in both cases. But, as you point >out, we might have greater optimizations here. The nice thing with the >same compression format is that the same parsing code path can be used >for both link-local and routable cases, but comes at the cost of one >additional byte per datagram. So there is a tradeoff between code-size >and compression efficiency, as discussed early in this thread. [Pascal] I agree with that too. Still HC1g needs an HC2. The real issue with HC3 seems to be the code-size compression trade off. Maybe writing some pseudo code will help figuring that out. If that's one byte in most packets it might be worth it. Also, it could mean a fast path though the parsing, and thus a better energy-efficiency. >Do you think this is a reasonable approach? [Pascal] It is. Comments: 1) I'm missing the 2 bits to compress the hop limit though considering your assumptions there's a great chance that the PAN is a stub. I'd take the next header 2 bits off to HC2 to make room for this. 2) there's a well identified best case for HC3. I still think we can make room in HC3 to indicate this and have a common HC3 for 1 and 1g. On the side) I fail to see why we can not fully compress a EUI-64 based suffix with HC1G. Pascal > >-- >Jonathan Hui > >> >> - It seems obvious that the local address suffix can be compressed if it >> is based on EUI-64 or is unambiguously associated to a 16 bits address >> using states somewhere (nd, reverse-ND, ...). The prefix can be >> compressed if it is the only one on-link, or then again unambiguously >> associated to a 16-bits address. I'd assume that for both, considering >> the value of compressing, people will make sure that the conditions are >> met for the compression to happen. >> >> - It seems pretty obvious too that the remote address will not be >> compressed: if it was on-link the nodes could and should use link local >> addresses; So it is arbitrary. So the answer I expect for my question >> above is that you expect that most times we will fully compress the >> local address and not at all the remote address. >> >> Would that be your guess too? >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: mercredi 5 mars 2008 18:32 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>> >>> >>> Hi Pascal, see below: >>> >>> Pascal Thubert (pthubert) wrote: >>>> Hi Jonathan: >>>> >>>> I'm certainly not willing to specialize HC3 to mesh-under whatever >> your >>>> definition of the term. I'm willing to specialize HC3 to elide a >> number >>>> off "always on" bits so that when these bits are on, HC3 is used >> instead >>>> of HC1 and HC2. I hope this much is clear by now. >>> Yes, this is clear now. >>> >>>> Consider this: even HC1g is specialized; it is specilized to the case >>>> when only the terminating networks are LoWPANs. For instance, how do >> you >>>> compress a packet in a LoWPAN that would sit between the source >> LoWPAN >>>> and the destination LoWPAN - that's ROLL for you? >>> I never said that HC1g wasn't specialized. Any compression scheme must >>> make assumptions about the underlying pattern, otherwise there is no >>> compression to be had. >>> >>> ROLL for me is where every node operates as an IP router. HC1g is >> trying >>> to address a PAN where each L2 hop is an IP hop. However, it is not >>> trying to address cases where the PAN is a transit network for external >>> networks that can have arbitrary prefixes. In other words, any messages >>> going into the PAN will be destined for those nodes in the PAN, and >>> similarly any messages leaving the PAN will be sourced by a node in the >>> PAN. But in both cases, the addresses used are routable addresses. This >>> is the case I'm shooting for. Is this scenario realistic to you? >>> >>> -- >>> Jonathan Hui >>> >>>> Like I said in another mail, this is a pretty difficult issue, maybe >>>> more complex than laying labels. My point is we do not know what ROLL >>>> will be made of; it will certainly be very interesting but it would >> be >>>> hazardous at this point to reserve bits for assumptions we could make >> on >>>> it. >>>> >>>> Let's look at what we have, which are the most important toggles and >> fit >>>> those in HC3. I'll be glad to define that the address that designs a >>>> node on this LoWPAN (the local address) is elided but is not a >>>> link-local-address and that the remote address is not elided. Or >>>> something else that makes sense like the local address is elided and >> is >>>> the one that unabiguously matches the scope of the remote address. >>>> >>>> So what's the case you're shooting for? >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>> Sent: mercredi 5 mars 2008 17:31 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>> >>>>> >>>>> I think it's fair to say that we should continue working on IP >> header >>>>> compression. However, I also think we must evaluate whether we are >>>>> willing to specialize such compression schemes for route-over vs. >>>>> mesh-under networks. I don't have a problem with such >> specialization, >>>>> but I would have a problem if we required any 6LoWPAN implementation >> to >>>>> support specialized schemes for both mesh-under and route-over >>>>> simultaneously. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> Pascal Thubert (pthubert) wrote: >>>>>> Hi Jonathan >>>>>> >>>>>> I agree it's great we are having this discussion :) >>>>>> >>>>>> Multiple thread could spawn from it because there are multiple >> topic. >>>>>> And some of this might belong to ROLL as you pointed out earlier. >>>>>> >>>>>> I'd wish to keep this thread for its original question on whether >> it >>>> is >>>>>> desirable, in the context of what we already have, to further >>>> compress >>>>>> HC1 and HC2 into a single HC3. For that specific thread, I retain >>>> that >>>>>> you do not oppose but that you vote for retaining some information >> on >>>>>> whether the addresses are elided or not. >>>>>> >>>>>> Is that fair? >>>>>> >>>>>> Pascal >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>>> Sent: mercredi 5 mars 2008 09:28 >>>>>>> To: Pascal Thubert (pthubert) >>>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>>> >>>>>>> >>>>>>> Regarding the GW assumption on the link, I think we need to take a >>>> step >>>>>>> back for a second. While it is true that most architectures up >> until >>>>>>> this point follow this assumption, most architectures that I know >> of >>>>>>> haven't been built using IP. ZigBee nodes, for example, only >>>>>> communicate >>>>>>> with ZigBee nodes at every hop and there isn't any effort to do >>>>>>> internetworking. >>>>>>> >>>>>>> But now that we actually have IP, we are no longer constrained to >> a >>>>>>> single link technology. Rather, nodes can communicate with each >>>> other, >>>>>>> directly using 802.15.4, or over other technologies such as WiFi, >>>>>>> Ethernet, GPRS, etc. This really opens up the network architecture >>>>>>> possibilities, and there are many cases where adding these >>>> additional >>>>>>> links are desirable. I know that ISA's proposed backbone routers >>>>>> provide >>>>>>> this functionality, but I'd rather support such networks at the IP >>>>>>> layer, rather than abstracting a combination of link technologies >> as >>>>>>> single IP link and defining any new machinery to do so. >>>>>>> >>>>>>> BTW it's great that we're having this discussion. It is long >>>> overdue. >>>>>>> -- >>>>>>> Jonathan Hui >>>>>>> >>>>>>> >>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>> Hi Jonathan: >>>>>>>> >>>>>>>> You are assuming explicitly that I am assuming implicitly... mesh >>>>>>>> under... Hum. >>>>>>>> >>>>>>>> Please have a look at >>>>>>>> >> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>>>>>>> -00.txt and it should be apparent that I'm not. In particular the >>>>>>>> backbone router is the device that will set and use the hop limit >>>>>> bit. >>>>>>>> So will all those interconnecting devices used in pseudowire, >> split >>>>>>>> bridges, IP Mobility, etc... if they are deployed in this space. >>>>>>>> >>>>>>>> What I'm really assuming is a gateway or an edge server on the >>>> link. >>>>>>>> It's there in most architectures that I know of at this point >>>> that's >>>>>> why >>>>>>>> I included it in the case we shoot for and saved 2 bits. Note >> that >>>>>> when >>>>>>>> the ULA and global addresses are used on top of link local, it >>>> makes >>>>>>>> sense that we define a mechanism to compress them as well. But >> this >>>>>> is >>>>>>>> not what HC3 is about. >>>>>>>> >>>>>>>> The goal of my initial proposal is illustrative, to foster this >>>> very >>>>>>>> discussion around the idea that we can shoot for a favorite case >>>> and >>>>>>>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a >> group >>>>>>>> think that the GW assumption is not reasonable, then, fine, let >> us >>>>>>>> affect 2 bits in HC3 to indicate whether the addresses are >>>>>> compressed. >>>>>>>> What do the others think? >>>>>>>> >>>>>>>> Pascal >>>>>>>>> -----Original Message----- >>>>>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>>>>> Sent: mardi 4 mars 2008 18:05 >>>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Pascal, >>>>>>>>> >>>>>>>>> Thanks for sharing your thoughts. >>>>>>>>> >>>>>>>>> By assuming the first 5 bits in HC1 are '1', you're staking a >>>> claim >>>>>>>> that >>>>>>>>> mesh-under link-local communication within a PAN is going to be >>>> most >>>>>>>>> common case and the one we've "shot for". If link-local is all >> we >>>>>> focus >>>>>>>>> on, then we are missing the point of IP. Frankly, I don't see >> much >>>>>>>>> benefit of IP if communication is limited to the PAN. >>>>>>>>> >>>>>>>>> W.r.t mesh-under, there are efforts within the IETF that assume >>>>>> 6LoWPAN >>>>>>>>> nodes will communicate via route-over using routable addresses >>>> (e.g. >>>>>>>>> ROLL). This brings us back to a broader topic of route-under vs. >>>>>>>>> mesh-under. While both will probably exist for some time, it >>>> raises >>>>>> the >>>>>>>>> question of whether 6LoWPAN implementations can support one or >> do >>>>>> they >>>>>>>>> have to support both. >>>>>>>>> >>>>>>>>> W.r.t compressing Hop Limit, I don't quite understand why you're >>>>>> using >>>>>>>> a >>>>>>>>> bit in HC3 to indicate where the message originated. If you're >>>>>> assuming >>>>>>>>> link-local communication, then messages shouldn't be forwarded >>>>>> across >>>>>>>>> links anyway. >>>>>>>>> >>>>>>>>> I do agree that there is work to do on compression and agree >> that >>>>>> there >>>>>>>>> are cases where HC1 and HC2 are not sufficient. This is why I've >>>>>> been >>>>>>>>> working, albeit slowly, on HC1g. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jonathan Hui >>>>>>>>> >>>>>>>>> >>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>>> Dear 6LoWPANers, >>>>>>>>>> >>>>>>>>>> Though HC1 and HC2 provide us with the capability to express >> any >>>>>>>>>> combination of compression, the most expected (or at least shot >>>>>> for) >>>>>>>>>> case does not lead to a better compression of the HC headers >>>>>>>> themselves. >>>>>>>>>> Seems that we could define an HC3 that would compress the pair >> of >>>>>> HC1 >>>>>>>>>> and HC2 for that best case. My proposal for doing this would be >>>> to: >>>>>>>>>> - define a new dispatch >>>>>>>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 >>>> and >>>>>>>>>> transport >>>>>>>>>> >>>>>>>>>> - define HC3 itself to: >>>>>>>>>> >>>>>>>>>> - implicitly say that the first 5 bits of HC1 are all >> ones >>>>>>>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>>>>>>> - replace HC2 so bit 7 of HC1 is useless >>>>>>>>>> - provide transport specific bits such as those defined >> for >>>>>>>>>> HC-UDP, >>>>>>>>>> then again assuming a predefined best case if room is >>>>>> missing >>>>>>>>>> An example of what the HC3 octet could be: >>>>>>>>>> >>>>>>>>>> bits 0 1 2-3 >>>>>>>>>> 4-7 >>>>>>>>>> >>>>>>>>>> >> +------------------+-------------+-----------------+-------------------- >>>>>>>>>> ---------------------+ >>>>>>>>>> | reserved | reserved | Next Header | >>>>>>>> transport >>>>>>>>>> specific control bits | >>>>>>>>>> >>>>>>>>>> >> +------------------+-------------+-----------------+-------------------- >>>>>>>>>> ---------------------+ >>>>>>>>>> >>>>>>>>>> Next header: as defined in HC1, bits 5 and 6 >>>>>>>>>> >>>>>>>>>> transport specific control bits for UDP: >>>>>>>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>>>>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>>>>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>>>>>>> bit 7 is reserved >>>>>>>>>> >>>>>>>>>> What do you think? >>>>>>>>>> >>>>>>>>>> Pascal >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 Mar 5 14:15:34 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7495128C418; Wed, 5 Mar 2008 14:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 WiB0ECuasu5l; Wed, 5 Mar 2008 14:15:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FEBC28C124; Wed, 5 Mar 2008 14:15:32 -0800 (PST) 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 DD87728C20C for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 14:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 JLnvre4saMJc for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 14:15:27 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 28A1B28C1DD for <6lowpan@ietf.org>; Wed, 5 Mar 2008 14:15:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 618EDA920E; Wed, 5 Mar 2008 14:15:17 -0800 (PST) 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 efK2KH13wRUl; Wed, 5 Mar 2008 14:15:10 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 4DE14A920B; Wed, 5 Mar 2008 14:15:10 -0800 (PST) Message-ID: <47CF1B69.2000501@archrock.com> Date: Wed, 05 Mar 2008 14:15:05 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC05483705@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05483705@xmb-ams-337.emea.cisco.com> Cc: enns@stanfordalumni.org, 6lowpan <6lowpan@ietf.org>, Jay Werb Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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 Thubert (pthubert) wrote: >> For demonstration purposes, let's first assume that every node acts as >> an L3 forwarder. In this case, no Mesh Addressing header is used and >> compressed addresses are carried in the compressed L3 header. >> > [Pascal] But if there's no mesh, why can't we pick the addresses from > the MAC header? I think our ideas of the network are still not matching up. In one case, I'm assuming that every node is doing L3 forwarding, meaning that each 15.4 hop is an IP hop. Every 15.4 hop decrements the IPv6 Hop Limit by one. In this case, you can deliver messages over multiple hops without a Mesh Addressing header. But you still need source and destination addresses distinct from the MAC header. If you are delivering a message over a single L2 hop, then the IP addresses can be completely elided and derived from the 15.4 header. In the case where nodes are doing L2 forwarding, then a Mesh Addressing header is required to define the end-points of an IP hop and we can completely elide the addresses in the IP header. The format defined by HC1g supports both cases. I've said this in an earlier email, but I believe the difference between L2 and L3 forwarding is smaller than we think. In both cases, nodes are essentially naming each other using MAC addresses. If this is the case, I would prefer to have the forwarding occur at L3. Doing so allows us to utilize functionality provided by IP, rather than re-defining functionality below IP to make L2 hops look like a single IP hop. -- Jonathan Hui >> - For communication that stays within the PAN, there is between 4 and > 16 >> bytes for L3 compressed addresses depending on whether the IID is >> derived from the short or extended address. The resulting compressed L3 >> header is as small as 6 bytes (HC1, hlim, src, dst). > [Pascal] Why not use HC1 with link local in that case? Seems not a most > probable case for HC3. > >> - For communication that crosses the PAN boundary, one of the IP >> addresses is always compressed and the other is not compressed. > [Pascal] makes sense. I guess that's the right case for HC3? > >> Although, I am planning to put in provisions to allow stateful >> compression by using a reserved short address range as defined in >> RFC4944 similar to how I've proposed to compress well-known multicast >> addresses. The resulting compressed L3 header is 20 bytes, but only 6 >> bytes if stateful compression is used. > [Pascal] great but definitely further work. > >> - When the communication occurs over a single IP hop, then the IIDs can >> be completely compressed and the resulting compressed IP header does > not >> contain any addressing information. This also works when L2 forwarding >> occurs and the Mesh Addressing header is used. The resulting compressed >> L3 header is only 2 bytes (HC1, hlim). > [Pascal] I miss the rationale for the single IP hop... I must be tired > :) > >> - To support both link-local and the common routable prefix, two >> different dispatch values are used. I was originally thinking that the >> same compression format could be used in both cases. But, as you point >> out, we might have greater optimizations here. The nice thing with the >> same compression format is that the same parsing code path can be used >> for both link-local and routable cases, but comes at the cost of one >> additional byte per datagram. So there is a tradeoff between code-size >> and compression efficiency, as discussed early in this thread. > [Pascal] I agree with that too. Still HC1g needs an HC2. The real issue > with HC3 seems to be the code-size compression trade off. Maybe writing > some pseudo code will help figuring that out. If that's one byte in most > packets it might be worth it. Also, it could mean a fast path though the > parsing, and thus a better energy-efficiency. > >> Do you think this is a reasonable approach? > [Pascal] It is. Comments: > > 1) I'm missing the 2 bits to compress the hop limit though considering > your assumptions there's a great chance that the PAN is a stub. I'd take > the next header 2 bits off to HC2 to make room for this. > > 2) there's a well identified best case for HC3. I still think we can > make room in HC3 to indicate this and have a common HC3 for 1 and 1g. > > On the side) I fail to see why we can not fully compress a EUI-64 based > suffix with HC1G. > > Pascal >> -- >> Jonathan Hui >> >>> - It seems obvious that the local address suffix can be compressed if > it >>> is based on EUI-64 or is unambiguously associated to a 16 bits > address >>> using states somewhere (nd, reverse-ND, ...). The prefix can be >>> compressed if it is the only one on-link, or then again unambiguously >>> associated to a 16-bits address. I'd assume that for both, > considering >>> the value of compressing, people will make sure that the conditions > are >>> met for the compression to happen. >>> >>> - It seems pretty obvious too that the remote address will not be >>> compressed: if it was on-link the nodes could and should use link > local >>> addresses; So it is arbitrary. So the answer I expect for my question >>> above is that you expect that most times we will fully compress the >>> local address and not at all the remote address. >>> >>> Would that be your guess too? >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: mercredi 5 mars 2008 18:32 >>>> To: Pascal Thubert (pthubert) >>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>> >>>> >>>> Hi Pascal, see below: >>>> >>>> Pascal Thubert (pthubert) wrote: >>>>> Hi Jonathan: >>>>> >>>>> I'm certainly not willing to specialize HC3 to mesh-under whatever >>> your >>>>> definition of the term. I'm willing to specialize HC3 to elide a >>> number >>>>> off "always on" bits so that when these bits are on, HC3 is used >>> instead >>>>> of HC1 and HC2. I hope this much is clear by now. >>>> Yes, this is clear now. >>>> >>>>> Consider this: even HC1g is specialized; it is specilized to the > case >>>>> when only the terminating networks are LoWPANs. For instance, how > do >>> you >>>>> compress a packet in a LoWPAN that would sit between the source >>> LoWPAN >>>>> and the destination LoWPAN - that's ROLL for you? >>>> I never said that HC1g wasn't specialized. Any compression scheme > must >>>> make assumptions about the underlying pattern, otherwise there is no >>>> compression to be had. >>>> >>>> ROLL for me is where every node operates as an IP router. HC1g is >>> trying >>>> to address a PAN where each L2 hop is an IP hop. However, it is not >>>> trying to address cases where the PAN is a transit network for > external >>>> networks that can have arbitrary prefixes. In other words, any > messages >>>> going into the PAN will be destined for those nodes in the PAN, and >>>> similarly any messages leaving the PAN will be sourced by a node in > the >>>> PAN. But in both cases, the addresses used are routable addresses. > This >>>> is the case I'm shooting for. Is this scenario realistic to you? >>>> >>>> -- >>>> Jonathan Hui >>>> >>>>> Like I said in another mail, this is a pretty difficult issue, > maybe >>>>> more complex than laying labels. My point is we do not know what > ROLL >>>>> will be made of; it will certainly be very interesting but it would >>> be >>>>> hazardous at this point to reserve bits for assumptions we could > make >>> on >>>>> it. >>>>> >>>>> Let's look at what we have, which are the most important toggles > and >>> fit >>>>> those in HC3. I'll be glad to define that the address that designs > a >>>>> node on this LoWPAN (the local address) is elided but is not a >>>>> link-local-address and that the remote address is not elided. Or >>>>> something else that makes sense like the local address is elided > and >>> is >>>>> the one that unabiguously matches the scope of the remote address. >>>>> >>>>> So what's the case you're shooting for? >>>>> >>>>> Pascal >>>>> >>>>>> -----Original Message----- >>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>> Sent: mercredi 5 mars 2008 17:31 >>>>>> To: Pascal Thubert (pthubert) >>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>> >>>>>> >>>>>> I think it's fair to say that we should continue working on IP >>> header >>>>>> compression. However, I also think we must evaluate whether we are >>>>>> willing to specialize such compression schemes for route-over vs. >>>>>> mesh-under networks. I don't have a problem with such >>> specialization, >>>>>> but I would have a problem if we required any 6LoWPAN > implementation >>> to >>>>>> support specialized schemes for both mesh-under and route-over >>>>>> simultaneously. >>>>>> >>>>>> -- >>>>>> Jonathan Hui >>>>>> >>>>>> >>>>>> Pascal Thubert (pthubert) wrote: >>>>>>> Hi Jonathan >>>>>>> >>>>>>> I agree it's great we are having this discussion :) >>>>>>> >>>>>>> Multiple thread could spawn from it because there are multiple >>> topic. >>>>>>> And some of this might belong to ROLL as you pointed out earlier. >>>>>>> >>>>>>> I'd wish to keep this thread for its original question on whether >>> it >>>>> is >>>>>>> desirable, in the context of what we already have, to further >>>>> compress >>>>>>> HC1 and HC2 into a single HC3. For that specific thread, I retain >>>>> that >>>>>>> you do not oppose but that you vote for retaining some > information >>> on >>>>>>> whether the addresses are elided or not. >>>>>>> >>>>>>> Is that fair? >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>>>> Sent: mercredi 5 mars 2008 09:28 >>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>>>> >>>>>>>> >>>>>>>> Regarding the GW assumption on the link, I think we need to take > a >>>>> step >>>>>>>> back for a second. While it is true that most architectures up >>> until >>>>>>>> this point follow this assumption, most architectures that I > know >>> of >>>>>>>> haven't been built using IP. ZigBee nodes, for example, only >>>>>>> communicate >>>>>>>> with ZigBee nodes at every hop and there isn't any effort to do >>>>>>>> internetworking. >>>>>>>> >>>>>>>> But now that we actually have IP, we are no longer constrained > to >>> a >>>>>>>> single link technology. Rather, nodes can communicate with each >>>>> other, >>>>>>>> directly using 802.15.4, or over other technologies such as > WiFi, >>>>>>>> Ethernet, GPRS, etc. This really opens up the network > architecture >>>>>>>> possibilities, and there are many cases where adding these >>>>> additional >>>>>>>> links are desirable. I know that ISA's proposed backbone routers >>>>>>> provide >>>>>>>> this functionality, but I'd rather support such networks at the > IP >>>>>>>> layer, rather than abstracting a combination of link > technologies >>> as >>>>>>>> single IP link and defining any new machinery to do so. >>>>>>>> >>>>>>>> BTW it's great that we're having this discussion. It is long >>>>> overdue. >>>>>>>> -- >>>>>>>> Jonathan Hui >>>>>>>> >>>>>>>> >>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>> Hi Jonathan: >>>>>>>>> >>>>>>>>> You are assuming explicitly that I am assuming implicitly... > mesh >>>>>>>>> under... Hum. >>>>>>>>> >>>>>>>>> Please have a look at >>>>>>>>> > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>>>>>>>> -00.txt and it should be apparent that I'm not. In particular > the >>>>>>>>> backbone router is the device that will set and use the hop > limit >>>>>>> bit. >>>>>>>>> So will all those interconnecting devices used in pseudowire, >>> split >>>>>>>>> bridges, IP Mobility, etc... if they are deployed in this > space. >>>>>>>>> What I'm really assuming is a gateway or an edge server on the >>>>> link. >>>>>>>>> It's there in most architectures that I know of at this point >>>>> that's >>>>>>> why >>>>>>>>> I included it in the case we shoot for and saved 2 bits. Note >>> that >>>>>>> when >>>>>>>>> the ULA and global addresses are used on top of link local, it >>>>> makes >>>>>>>>> sense that we define a mechanism to compress them as well. But >>> this >>>>>>> is >>>>>>>>> not what HC3 is about. >>>>>>>>> >>>>>>>>> The goal of my initial proposal is illustrative, to foster this >>>>> very >>>>>>>>> discussion around the idea that we can shoot for a favorite > case >>>>> and >>>>>>>>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a >>> group >>>>>>>>> think that the GW assumption is not reasonable, then, fine, let >>> us >>>>>>>>> affect 2 bits in HC3 to indicate whether the addresses are >>>>>>> compressed. >>>>>>>>> What do the others think? >>>>>>>>> >>>>>>>>> Pascal >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>>>>>> Sent: mardi 4 mars 2008 18:05 >>>>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Pascal, >>>>>>>>>> >>>>>>>>>> Thanks for sharing your thoughts. >>>>>>>>>> >>>>>>>>>> By assuming the first 5 bits in HC1 are '1', you're staking a >>>>> claim >>>>>>>>> that >>>>>>>>>> mesh-under link-local communication within a PAN is going to > be >>>>> most >>>>>>>>>> common case and the one we've "shot for". If link-local is all >>> we >>>>>>> focus >>>>>>>>>> on, then we are missing the point of IP. Frankly, I don't see >>> much >>>>>>>>>> benefit of IP if communication is limited to the PAN. >>>>>>>>>> >>>>>>>>>> W.r.t mesh-under, there are efforts within the IETF that > assume >>>>>>> 6LoWPAN >>>>>>>>>> nodes will communicate via route-over using routable addresses >>>>> (e.g. >>>>>>>>>> ROLL). This brings us back to a broader topic of route-under > vs. >>>>>>>>>> mesh-under. While both will probably exist for some time, it >>>>> raises >>>>>>> the >>>>>>>>>> question of whether 6LoWPAN implementations can support one or >>> do >>>>>>> they >>>>>>>>>> have to support both. >>>>>>>>>> >>>>>>>>>> W.r.t compressing Hop Limit, I don't quite understand why > you're >>>>>>> using >>>>>>>>> a >>>>>>>>>> bit in HC3 to indicate where the message originated. If you're >>>>>>> assuming >>>>>>>>>> link-local communication, then messages shouldn't be forwarded >>>>>>> across >>>>>>>>>> links anyway. >>>>>>>>>> >>>>>>>>>> I do agree that there is work to do on compression and agree >>> that >>>>>>> there >>>>>>>>>> are cases where HC1 and HC2 are not sufficient. This is why > I've >>>>>>> been >>>>>>>>>> working, albeit slowly, on HC1g. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Jonathan Hui >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>>>> Dear 6LoWPANers, >>>>>>>>>>> >>>>>>>>>>> Though HC1 and HC2 provide us with the capability to express >>> any >>>>>>>>>>> combination of compression, the most expected (or at least > shot >>>>>>> for) >>>>>>>>>>> case does not lead to a better compression of the HC headers >>>>>>>>> themselves. >>>>>>>>>>> Seems that we could define an HC3 that would compress the > pair >>> of >>>>>>> HC1 >>>>>>>>>>> and HC2 for that best case. My proposal for doing this would > be >>>>> to: >>>>>>>>>>> - define a new dispatch >>>>>>>>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed > IPv6 >>>>> and >>>>>>>>>>> transport >>>>>>>>>>> >>>>>>>>>>> - define HC3 itself to: >>>>>>>>>>> >>>>>>>>>>> - implicitly say that the first 5 bits of HC1 are all >>> ones >>>>>>>>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>>>>>>>> - replace HC2 so bit 7 of HC1 is useless >>>>>>>>>>> - provide transport specific bits such as those defined >>> for >>>>>>>>>>> HC-UDP, >>>>>>>>>>> then again assuming a predefined best case if room is >>>>>>> missing >>>>>>>>>>> An example of what the HC3 octet could be: >>>>>>>>>>> >>>>>>>>>>> bits 0 1 2-3 >>>>>>>>>>> 4-7 >>>>>>>>>>> >>>>>>>>>>> > +------------------+-------------+-----------------+-------------------- >>>>>>>>>>> ---------------------+ >>>>>>>>>>> | reserved | reserved | Next Header | >>>>>>>>> transport >>>>>>>>>>> specific control bits | >>>>>>>>>>> >>>>>>>>>>> > +------------------+-------------+-----------------+-------------------- >>>>>>>>>>> ---------------------+ >>>>>>>>>>> >>>>>>>>>>> Next header: as defined in HC1, bits 5 and 6 >>>>>>>>>>> >>>>>>>>>>> transport specific control bits for UDP: >>>>>>>>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>>>>>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>>>>>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>>>>>>>> bit 7 is reserved >>>>>>>>>>> >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>> Pascal >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 Mar 5 14:44:36 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592FD28C683; Wed, 5 Mar 2008 14:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.647 X-Spam-Level: X-Spam-Status: No, score=-100.647 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 oRJqoVUPr3wC; Wed, 5 Mar 2008 14:44:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F8DE28C7C6; Wed, 5 Mar 2008 14:44:34 -0800 (PST) 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 E6CA628C6EB for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 14:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 IZyJSlgjpkgz for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 14:44:32 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 26C7928C47F for <6lowpan@ietf.org>; Wed, 5 Mar 2008 14:44:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,452,1199660400"; d="scan'208";a="2645536" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2008 23:44:20 +0100 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 m25MiKtv016254; Wed, 5 Mar 2008 23:44:20 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m25MiIHC026665; Wed, 5 Mar 2008 22:44:18 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); Wed, 5 Mar 2008 23:44:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 23:43:48 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05483733@xmb-ams-337.emea.cisco.com> In-Reply-To: <47CF1B69.2000501@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Compressing HC1 and HC2 into HC3 thread-index: Ach/DnCqblp6daw8RhWDOTtQz1isUAAAR2hA From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 05 Mar 2008 22:44:18.0605 (UTC) FILETIME=[726E9DD0:01C87F12] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18064; t=1204757060; x=1205621060; 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]=20Compressing=20HC1=20and=20H C2=20into=20HC3 |Sender:=20; bh=VH2hLl4E6XN1v7ovgSh0Qes0EyYw9tO1p6loonqvCXc=; b=dneFVAkgu9qlNG0gZsD2aLNDNiUNjaqrDK7/W3jB7HuVTl78NFE56upSmV 2gUJ7gMHlPVZP3ATIZhzalhDdZOuXj32SnlMbOFtkU7adOw1QSiHD1j3XqF2 7aazHa1CkN; 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] Compressing HC1 and HC2 into HC3 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 Thubert (pthubert) wrote: >>> For demonstration purposes, let's first assume that every node acts as >>> an L3 forwarder. In this case, no Mesh Addressing header is used and >>> compressed addresses are carried in the compressed L3 header. >>> >> [Pascal] But if there's no mesh, why can't we pick the addresses from >> the MAC header? > >I think our ideas of the network are still not matching up. In one case, >I'm assuming that every node is doing L3 forwarding, meaning that each >15.4 hop is an IP hop. Every 15.4 hop decrements the IPv6 Hop Limit by >one. In this case, you can deliver messages over multiple hops without a >Mesh Addressing header. But you still need source and destination >addresses distinct from the MAC header. If you are delivering a message >over a single L2 hop, then the IP addresses can be completely elided and >derived from the 15.4 header. [Pascal] Now I think I'm with you. I was confused by what you design as a PAN that I associated with a link. So you have a single 802.15.4 short address domain but still multiple IP hops. I guess you're doing host routes in the original MANET fashion within the PAN and then aggregate outside the PAN. [Pascal] I a formal world, you should undo/redo 6lowpan at each hop and present the encompressed packet to routing. Obviously you do not want to do that so you accept a routing plane at L3 and a forwarding at 6LoWPAN shim. If that's so, why not keep the mesh header format when you stay in the same PAN? Talk to you soon, Pascal >-- >Jonathan Hui > > >>> - For communication that stays within the PAN, there is between 4 and >> 16 >>> bytes for L3 compressed addresses depending on whether the IID is >>> derived from the short or extended address. The resulting compressed L3 >>> header is as small as 6 bytes (HC1, hlim, src, dst). >> [Pascal] Why not use HC1 with link local in that case? Seems not a most >> probable case for HC3. >> >>> - For communication that crosses the PAN boundary, one of the IP >>> addresses is always compressed and the other is not compressed. >> [Pascal] makes sense. I guess that's the right case for HC3? >> >>> Although, I am planning to put in provisions to allow stateful >>> compression by using a reserved short address range as defined in >>> RFC4944 similar to how I've proposed to compress well-known multicast >>> addresses. The resulting compressed L3 header is 20 bytes, but only 6 >>> bytes if stateful compression is used. >> [Pascal] great but definitely further work. >> >>> - When the communication occurs over a single IP hop, then the IIDs can >>> be completely compressed and the resulting compressed IP header does >> not >>> contain any addressing information. This also works when L2 forwarding >>> occurs and the Mesh Addressing header is used. The resulting compressed >>> L3 header is only 2 bytes (HC1, hlim). >> [Pascal] I miss the rationale for the single IP hop... I must be tired >> :) >> >>> - To support both link-local and the common routable prefix, two >>> different dispatch values are used. I was originally thinking that the >>> same compression format could be used in both cases. But, as you point >>> out, we might have greater optimizations here. The nice thing with the >>> same compression format is that the same parsing code path can be used >>> for both link-local and routable cases, but comes at the cost of one >>> additional byte per datagram. So there is a tradeoff between code-size >>> and compression efficiency, as discussed early in this thread. >> [Pascal] I agree with that too. Still HC1g needs an HC2. The real issue >> with HC3 seems to be the code-size compression trade off. Maybe writing >> some pseudo code will help figuring that out. If that's one byte in most >> packets it might be worth it. Also, it could mean a fast path though the >> parsing, and thus a better energy-efficiency. >> >>> Do you think this is a reasonable approach? >> [Pascal] It is. Comments: >> >> 1) I'm missing the 2 bits to compress the hop limit though considering >> your assumptions there's a great chance that the PAN is a stub. I'd take >> the next header 2 bits off to HC2 to make room for this. >> >> 2) there's a well identified best case for HC3. I still think we can >> make room in HC3 to indicate this and have a common HC3 for 1 and 1g. >> >> On the side) I fail to see why we can not fully compress a EUI-64 based >> suffix with HC1G. >> >> Pascal >>> -- >>> Jonathan Hui >>> >>>> - It seems obvious that the local address suffix can be compressed if >> it >>>> is based on EUI-64 or is unambiguously associated to a 16 bits >> address >>>> using states somewhere (nd, reverse-ND, ...). The prefix can be >>>> compressed if it is the only one on-link, or then again unambiguously >>>> associated to a 16-bits address. I'd assume that for both, >> considering >>>> the value of compressing, people will make sure that the conditions >> are >>>> met for the compression to happen. >>>> >>>> - It seems pretty obvious too that the remote address will not be >>>> compressed: if it was on-link the nodes could and should use link >> local >>>> addresses; So it is arbitrary. So the answer I expect for my question >>>> above is that you expect that most times we will fully compress the >>>> local address and not at all the remote address. >>>> >>>> Would that be your guess too? >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>> Sent: mercredi 5 mars 2008 18:32 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>> >>>>> >>>>> Hi Pascal, see below: >>>>> >>>>> Pascal Thubert (pthubert) wrote: >>>>>> Hi Jonathan: >>>>>> >>>>>> I'm certainly not willing to specialize HC3 to mesh-under whatever >>>> your >>>>>> definition of the term. I'm willing to specialize HC3 to elide a >>>> number >>>>>> off "always on" bits so that when these bits are on, HC3 is used >>>> instead >>>>>> of HC1 and HC2. I hope this much is clear by now. >>>>> Yes, this is clear now. >>>>> >>>>>> Consider this: even HC1g is specialized; it is specilized to the >> case >>>>>> when only the terminating networks are LoWPANs. For instance, how >> do >>>> you >>>>>> compress a packet in a LoWPAN that would sit between the source >>>> LoWPAN >>>>>> and the destination LoWPAN - that's ROLL for you? >>>>> I never said that HC1g wasn't specialized. Any compression scheme >> must >>>>> make assumptions about the underlying pattern, otherwise there is no >>>>> compression to be had. >>>>> >>>>> ROLL for me is where every node operates as an IP router. HC1g is >>>> trying >>>>> to address a PAN where each L2 hop is an IP hop. However, it is not >>>>> trying to address cases where the PAN is a transit network for >> external >>>>> networks that can have arbitrary prefixes. In other words, any >> messages >>>>> going into the PAN will be destined for those nodes in the PAN, and >>>>> similarly any messages leaving the PAN will be sourced by a node in >> the >>>>> PAN. But in both cases, the addresses used are routable addresses. >> This >>>>> is the case I'm shooting for. Is this scenario realistic to you? >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>>> Like I said in another mail, this is a pretty difficult issue, >> maybe >>>>>> more complex than laying labels. My point is we do not know what >> ROLL >>>>>> will be made of; it will certainly be very interesting but it would >>>> be >>>>>> hazardous at this point to reserve bits for assumptions we could >> make >>>> on >>>>>> it. >>>>>> >>>>>> Let's look at what we have, which are the most important toggles >> and >>>> fit >>>>>> those in HC3. I'll be glad to define that the address that designs >> a >>>>>> node on this LoWPAN (the local address) is elided but is not a >>>>>> link-local-address and that the remote address is not elided. Or >>>>>> something else that makes sense like the local address is elided >> and >>>> is >>>>>> the one that unabiguously matches the scope of the remote address. >>>>>> >>>>>> So what's the case you're shooting for? >>>>>> >>>>>> Pascal >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>>> Sent: mercredi 5 mars 2008 17:31 >>>>>>> To: Pascal Thubert (pthubert) >>>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>>> >>>>>>> >>>>>>> I think it's fair to say that we should continue working on IP >>>> header >>>>>>> compression. However, I also think we must evaluate whether we are >>>>>>> willing to specialize such compression schemes for route-over vs. >>>>>>> mesh-under networks. I don't have a problem with such >>>> specialization, >>>>>>> but I would have a problem if we required any 6LoWPAN >> implementation >>>> to >>>>>>> support specialized schemes for both mesh-under and route-over >>>>>>> simultaneously. >>>>>>> >>>>>>> -- >>>>>>> Jonathan Hui >>>>>>> >>>>>>> >>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>> Hi Jonathan >>>>>>>> >>>>>>>> I agree it's great we are having this discussion :) >>>>>>>> >>>>>>>> Multiple thread could spawn from it because there are multiple >>>> topic. >>>>>>>> And some of this might belong to ROLL as you pointed out earlier. >>>>>>>> >>>>>>>> I'd wish to keep this thread for its original question on whether >>>> it >>>>>> is >>>>>>>> desirable, in the context of what we already have, to further >>>>>> compress >>>>>>>> HC1 and HC2 into a single HC3. For that specific thread, I retain >>>>>> that >>>>>>>> you do not oppose but that you vote for retaining some >> information >>>> on >>>>>>>> whether the addresses are elided or not. >>>>>>>> >>>>>>>> Is that fair? >>>>>>>> >>>>>>>> Pascal >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>>>>> Sent: mercredi 5 mars 2008 09:28 >>>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>>>>> >>>>>>>>> >>>>>>>>> Regarding the GW assumption on the link, I think we need to take >> a >>>>>> step >>>>>>>>> back for a second. While it is true that most architectures up >>>> until >>>>>>>>> this point follow this assumption, most architectures that I >> know >>>> of >>>>>>>>> haven't been built using IP. ZigBee nodes, for example, only >>>>>>>> communicate >>>>>>>>> with ZigBee nodes at every hop and there isn't any effort to do >>>>>>>>> internetworking. >>>>>>>>> >>>>>>>>> But now that we actually have IP, we are no longer constrained >> to >>>> a >>>>>>>>> single link technology. Rather, nodes can communicate with each >>>>>> other, >>>>>>>>> directly using 802.15.4, or over other technologies such as >> WiFi, >>>>>>>>> Ethernet, GPRS, etc. This really opens up the network >> architecture >>>>>>>>> possibilities, and there are many cases where adding these >>>>>> additional >>>>>>>>> links are desirable. I know that ISA's proposed backbone routers >>>>>>>> provide >>>>>>>>> this functionality, but I'd rather support such networks at the >> IP >>>>>>>>> layer, rather than abstracting a combination of link >> technologies >>>> as >>>>>>>>> single IP link and defining any new machinery to do so. >>>>>>>>> >>>>>>>>> BTW it's great that we're having this discussion. It is long >>>>>> overdue. >>>>>>>>> -- >>>>>>>>> Jonathan Hui >>>>>>>>> >>>>>>>>> >>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>>> Hi Jonathan: >>>>>>>>>> >>>>>>>>>> You are assuming explicitly that I am assuming implicitly... >> mesh >>>>>>>>>> under... Hum. >>>>>>>>>> >>>>>>>>>> Please have a look at >>>>>>>>>> >> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>>>>>>>>> -00.txt and it should be apparent that I'm not. In particular >> the >>>>>>>>>> backbone router is the device that will set and use the hop >> limit >>>>>>>> bit. >>>>>>>>>> So will all those interconnecting devices used in pseudowire, >>>> split >>>>>>>>>> bridges, IP Mobility, etc... if they are deployed in this >> space. >>>>>>>>>> What I'm really assuming is a gateway or an edge server on the >>>>>> link. >>>>>>>>>> It's there in most architectures that I know of at this point >>>>>> that's >>>>>>>> why >>>>>>>>>> I included it in the case we shoot for and saved 2 bits. Note >>>> that >>>>>>>> when >>>>>>>>>> the ULA and global addresses are used on top of link local, it >>>>>> makes >>>>>>>>>> sense that we define a mechanism to compress them as well. But >>>> this >>>>>>>> is >>>>>>>>>> not what HC3 is about. >>>>>>>>>> >>>>>>>>>> The goal of my initial proposal is illustrative, to foster this >>>>>> very >>>>>>>>>> discussion around the idea that we can shoot for a favorite >> case >>>>>> and >>>>>>>>>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a >>>> group >>>>>>>>>> think that the GW assumption is not reasonable, then, fine, let >>>> us >>>>>>>>>> affect 2 bits in HC3 to indicate whether the addresses are >>>>>>>> compressed. >>>>>>>>>> What do the others think? >>>>>>>>>> >>>>>>>>>> Pascal >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>>>>>>> Sent: mardi 4 mars 2008 18:05 >>>>>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Pascal, >>>>>>>>>>> >>>>>>>>>>> Thanks for sharing your thoughts. >>>>>>>>>>> >>>>>>>>>>> By assuming the first 5 bits in HC1 are '1', you're staking a >>>>>> claim >>>>>>>>>> that >>>>>>>>>>> mesh-under link-local communication within a PAN is going to >> be >>>>>> most >>>>>>>>>>> common case and the one we've "shot for". If link-local is all >>>> we >>>>>>>> focus >>>>>>>>>>> on, then we are missing the point of IP. Frankly, I don't see >>>> much >>>>>>>>>>> benefit of IP if communication is limited to the PAN. >>>>>>>>>>> >>>>>>>>>>> W.r.t mesh-under, there are efforts within the IETF that >> assume >>>>>>>> 6LoWPAN >>>>>>>>>>> nodes will communicate via route-over using routable addresses >>>>>> (e.g. >>>>>>>>>>> ROLL). This brings us back to a broader topic of route-under >> vs. >>>>>>>>>>> mesh-under. While both will probably exist for some time, it >>>>>> raises >>>>>>>> the >>>>>>>>>>> question of whether 6LoWPAN implementations can support one or >>>> do >>>>>>>> they >>>>>>>>>>> have to support both. >>>>>>>>>>> >>>>>>>>>>> W.r.t compressing Hop Limit, I don't quite understand why >> you're >>>>>>>> using >>>>>>>>>> a >>>>>>>>>>> bit in HC3 to indicate where the message originated. If you're >>>>>>>> assuming >>>>>>>>>>> link-local communication, then messages shouldn't be forwarded >>>>>>>> across >>>>>>>>>>> links anyway. >>>>>>>>>>> >>>>>>>>>>> I do agree that there is work to do on compression and agree >>>> that >>>>>>>> there >>>>>>>>>>> are cases where HC1 and HC2 are not sufficient. This is why >> I've >>>>>>>> been >>>>>>>>>>> working, albeit slowly, on HC1g. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Jonathan Hui >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>>>>> Dear 6LoWPANers, >>>>>>>>>>>> >>>>>>>>>>>> Though HC1 and HC2 provide us with the capability to express >>>> any >>>>>>>>>>>> combination of compression, the most expected (or at least >> shot >>>>>>>> for) >>>>>>>>>>>> case does not lead to a better compression of the HC headers >>>>>>>>>> themselves. >>>>>>>>>>>> Seems that we could define an HC3 that would compress the >> pair >>>> of >>>>>>>> HC1 >>>>>>>>>>>> and HC2 for that best case. My proposal for doing this would >> be >>>>>> to: >>>>>>>>>>>> - define a new dispatch >>>>>>>>>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed >> IPv6 >>>>>> and >>>>>>>>>>>> transport >>>>>>>>>>>> >>>>>>>>>>>> - define HC3 itself to: >>>>>>>>>>>> >>>>>>>>>>>> - implicitly say that the first 5 bits of HC1 are all >>>> ones >>>>>>>>>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>>>>>>>>> - replace HC2 so bit 7 of HC1 is useless >>>>>>>>>>>> - provide transport specific bits such as those defined >>>> for >>>>>>>>>>>> HC-UDP, >>>>>>>>>>>> then again assuming a predefined best case if room is >>>>>>>> missing >>>>>>>>>>>> An example of what the HC3 octet could be: >>>>>>>>>>>> >>>>>>>>>>>> bits 0 1 2-3 >>>>>>>>>>>> 4-7 >>>>>>>>>>>> >>>>>>>>>>>> >> +------------------+-------------+-----------------+-------------------- >>>>>>>>>>>> ---------------------+ >>>>>>>>>>>> | reserved | reserved | Next Header | >>>>>>>>>> transport >>>>>>>>>>>> specific control bits | >>>>>>>>>>>> >>>>>>>>>>>> >> +------------------+-------------+-----------------+-------------------- >>>>>>>>>>>> ---------------------+ >>>>>>>>>>>> >>>>>>>>>>>> Next header: as defined in HC1, bits 5 and 6 >>>>>>>>>>>> >>>>>>>>>>>> transport specific control bits for UDP: >>>>>>>>>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>>>>>>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>>>>>>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>>>>>>>>> bit 7 is reserved >>>>>>>>>>>> >>>>>>>>>>>> What do you think? >>>>>>>>>>>> >>>>>>>>>>>> Pascal >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 Mar 5 15:05:37 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5495028C81B; Wed, 5 Mar 2008 15:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.163 X-Spam-Level: X-Spam-Status: No, score=-100.163 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 vffI04VucClz; Wed, 5 Mar 2008 15:05:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CED328C2DF; Wed, 5 Mar 2008 15:05:35 -0800 (PST) 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 D0A7628C2C6 for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 15:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 A3ndRG9AEwEk for <6lowpan@core3.amsl.com>; Wed, 5 Mar 2008 15:05:33 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 1CBBA28C2DF for <6lowpan@ietf.org>; Wed, 5 Mar 2008 15:05:33 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 6AD21A9304; Wed, 5 Mar 2008 15:05:23 -0800 (PST) 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 auSXmY1buo22; Wed, 5 Mar 2008 15:05:16 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 09A61A9301; Wed, 5 Mar 2008 15:05:16 -0800 (PST) Message-ID: <47CF2727.3030202@archrock.com> Date: Wed, 05 Mar 2008 15:05:11 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC05483733@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05483733@xmb-ams-337.emea.cisco.com> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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 Pascal, Pascal Thubert (pthubert) wrote: > [Pascal] Now I think I'm with you. I was confused by what you design as > a PAN that I associated with a link. So you have a single 802.15.4 short > address domain but still multiple IP hops. I guess you're doing host > routes in the original MANET fashion within the PAN and then aggregate > outside the PAN. Yes, that's right. But, if we step back a bit, it's not much different than routing at L2, nodes are still named by their 15.4 addresses. > [Pascal] I a formal world, you should undo/redo 6lowpan at each hop and > present the encompressed packet to routing. Obviously you do not want to > do that so you accept a routing plane at L3 and a forwarding at 6LoWPAN > shim. If that's so, why not keep the mesh header format when you stay in > the same PAN? I am technically undoing/redoing 6lowpan at each L2 hop. One way to look at my L3 forwarding proposal is that the 6LoWPAN Mesh Addressing header is always compressed out because the Mesh Addressing source and destination addresses are identical to the 15.4 source and destination. Then we are left with a header that includes the 15.4 header and the compressed IP header. - When a node communicates with other nodes within a single radio hop, then both source and destination addresses may be completely elided, deriving them from the lower layers. - When a node communicates over multiple IP hops but stay within the PAN, then compressed source and destination addresses appear in the IP header. - When a node communicates with devices outside the PAN, then one of the addresses are carried uncompressed in the IP header. There's no need to use the Mesh Addressing header in any of these cases. I hope I'm making myself more clear. -- Jonathan Hui > > Talk to you soon, > > Pascal >> -- >> Jonathan Hui >> >> >>>> - For communication that stays within the PAN, there is between 4 > and >>> 16 >>>> bytes for L3 compressed addresses depending on whether the IID is >>>> derived from the short or extended address. The resulting compressed > L3 >>>> header is as small as 6 bytes (HC1, hlim, src, dst). >>> [Pascal] Why not use HC1 with link local in that case? Seems not a > most >>> probable case for HC3. >>> >>>> - For communication that crosses the PAN boundary, one of the IP >>>> addresses is always compressed and the other is not compressed. >>> [Pascal] makes sense. I guess that's the right case for HC3? >>> >>>> Although, I am planning to put in provisions to allow stateful >>>> compression by using a reserved short address range as defined in >>>> RFC4944 similar to how I've proposed to compress well-known > multicast >>>> addresses. The resulting compressed L3 header is 20 bytes, but only > 6 >>>> bytes if stateful compression is used. >>> [Pascal] great but definitely further work. >>> >>>> - When the communication occurs over a single IP hop, then the IIDs > can >>>> be completely compressed and the resulting compressed IP header does >>> not >>>> contain any addressing information. This also works when L2 > forwarding >>>> occurs and the Mesh Addressing header is used. The resulting > compressed >>>> L3 header is only 2 bytes (HC1, hlim). >>> [Pascal] I miss the rationale for the single IP hop... I must be > tired >>> :) >>> >>>> - To support both link-local and the common routable prefix, two >>>> different dispatch values are used. I was originally thinking that > the >>>> same compression format could be used in both cases. But, as you > point >>>> out, we might have greater optimizations here. The nice thing with > the >>>> same compression format is that the same parsing code path can be > used >>>> for both link-local and routable cases, but comes at the cost of one >>>> additional byte per datagram. So there is a tradeoff between > code-size >>>> and compression efficiency, as discussed early in this thread. >>> [Pascal] I agree with that too. Still HC1g needs an HC2. The real > issue >>> with HC3 seems to be the code-size compression trade off. Maybe > writing >>> some pseudo code will help figuring that out. If that's one byte in > most >>> packets it might be worth it. Also, it could mean a fast path though > the >>> parsing, and thus a better energy-efficiency. >>> >>>> Do you think this is a reasonable approach? >>> [Pascal] It is. Comments: >>> >>> 1) I'm missing the 2 bits to compress the hop limit though > considering >>> your assumptions there's a great chance that the PAN is a stub. I'd > take >>> the next header 2 bits off to HC2 to make room for this. >>> >>> 2) there's a well identified best case for HC3. I still think we can >>> make room in HC3 to indicate this and have a common HC3 for 1 and 1g. >>> >>> On the side) I fail to see why we can not fully compress a EUI-64 > based >>> suffix with HC1G. >>> >>> Pascal >>>> -- >>>> Jonathan Hui >>>> >>>>> - It seems obvious that the local address suffix can be compressed > if >>> it >>>>> is based on EUI-64 or is unambiguously associated to a 16 bits >>> address >>>>> using states somewhere (nd, reverse-ND, ...). The prefix can be >>>>> compressed if it is the only one on-link, or then again > unambiguously >>>>> associated to a 16-bits address. I'd assume that for both, >>> considering >>>>> the value of compressing, people will make sure that the conditions >>> are >>>>> met for the compression to happen. >>>>> >>>>> - It seems pretty obvious too that the remote address will not be >>>>> compressed: if it was on-link the nodes could and should use link >>> local >>>>> addresses; So it is arbitrary. So the answer I expect for my > question >>>>> above is that you expect that most times we will fully compress the >>>>> local address and not at all the remote address. >>>>> >>>>> Would that be your guess too? >>>>> >>>>> Pascal >>>>> >>>>>> -----Original Message----- >>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>> Sent: mercredi 5 mars 2008 18:32 >>>>>> To: Pascal Thubert (pthubert) >>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>> >>>>>> >>>>>> Hi Pascal, see below: >>>>>> >>>>>> Pascal Thubert (pthubert) wrote: >>>>>>> Hi Jonathan: >>>>>>> >>>>>>> I'm certainly not willing to specialize HC3 to mesh-under > whatever >>>>> your >>>>>>> definition of the term. I'm willing to specialize HC3 to elide a >>>>> number >>>>>>> off "always on" bits so that when these bits are on, HC3 is used >>>>> instead >>>>>>> of HC1 and HC2. I hope this much is clear by now. >>>>>> Yes, this is clear now. >>>>>> >>>>>>> Consider this: even HC1g is specialized; it is specilized to the >>> case >>>>>>> when only the terminating networks are LoWPANs. For instance, how >>> do >>>>> you >>>>>>> compress a packet in a LoWPAN that would sit between the source >>>>> LoWPAN >>>>>>> and the destination LoWPAN - that's ROLL for you? >>>>>> I never said that HC1g wasn't specialized. Any compression scheme >>> must >>>>>> make assumptions about the underlying pattern, otherwise there is > no >>>>>> compression to be had. >>>>>> >>>>>> ROLL for me is where every node operates as an IP router. HC1g is >>>>> trying >>>>>> to address a PAN where each L2 hop is an IP hop. However, it is > not >>>>>> trying to address cases where the PAN is a transit network for >>> external >>>>>> networks that can have arbitrary prefixes. In other words, any >>> messages >>>>>> going into the PAN will be destined for those nodes in the PAN, > and >>>>>> similarly any messages leaving the PAN will be sourced by a node > in >>> the >>>>>> PAN. But in both cases, the addresses used are routable addresses. >>> This >>>>>> is the case I'm shooting for. Is this scenario realistic to you? >>>>>> >>>>>> -- >>>>>> Jonathan Hui >>>>>> >>>>>>> Like I said in another mail, this is a pretty difficult issue, >>> maybe >>>>>>> more complex than laying labels. My point is we do not know what >>> ROLL >>>>>>> will be made of; it will certainly be very interesting but it > would >>>>> be >>>>>>> hazardous at this point to reserve bits for assumptions we could >>> make >>>>> on >>>>>>> it. >>>>>>> >>>>>>> Let's look at what we have, which are the most important toggles >>> and >>>>> fit >>>>>>> those in HC3. I'll be glad to define that the address that > designs >>> a >>>>>>> node on this LoWPAN (the local address) is elided but is not a >>>>>>> link-local-address and that the remote address is not elided. Or >>>>>>> something else that makes sense like the local address is elided >>> and >>>>> is >>>>>>> the one that unabiguously matches the scope of the remote > address. >>>>>>> So what's the case you're shooting for? >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>>>> Sent: mercredi 5 mars 2008 17:31 >>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>>>> >>>>>>>> >>>>>>>> I think it's fair to say that we should continue working on IP >>>>> header >>>>>>>> compression. However, I also think we must evaluate whether we > are >>>>>>>> willing to specialize such compression schemes for route-over > vs. >>>>>>>> mesh-under networks. I don't have a problem with such >>>>> specialization, >>>>>>>> but I would have a problem if we required any 6LoWPAN >>> implementation >>>>> to >>>>>>>> support specialized schemes for both mesh-under and route-over >>>>>>>> simultaneously. >>>>>>>> >>>>>>>> -- >>>>>>>> Jonathan Hui >>>>>>>> >>>>>>>> >>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>> Hi Jonathan >>>>>>>>> >>>>>>>>> I agree it's great we are having this discussion :) >>>>>>>>> >>>>>>>>> Multiple thread could spawn from it because there are multiple >>>>> topic. >>>>>>>>> And some of this might belong to ROLL as you pointed out > earlier. >>>>>>>>> I'd wish to keep this thread for its original question on > whether >>>>> it >>>>>>> is >>>>>>>>> desirable, in the context of what we already have, to further >>>>>>> compress >>>>>>>>> HC1 and HC2 into a single HC3. For that specific thread, I > retain >>>>>>> that >>>>>>>>> you do not oppose but that you vote for retaining some >>> information >>>>> on >>>>>>>>> whether the addresses are elided or not. >>>>>>>>> >>>>>>>>> Is that fair? >>>>>>>>> >>>>>>>>> Pascal >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>>>>>> Sent: mercredi 5 mars 2008 09:28 >>>>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regarding the GW assumption on the link, I think we need to > take >>> a >>>>>>> step >>>>>>>>>> back for a second. While it is true that most architectures up >>>>> until >>>>>>>>>> this point follow this assumption, most architectures that I >>> know >>>>> of >>>>>>>>>> haven't been built using IP. ZigBee nodes, for example, only >>>>>>>>> communicate >>>>>>>>>> with ZigBee nodes at every hop and there isn't any effort to > do >>>>>>>>>> internetworking. >>>>>>>>>> >>>>>>>>>> But now that we actually have IP, we are no longer constrained >>> to >>>>> a >>>>>>>>>> single link technology. Rather, nodes can communicate with > each >>>>>>> other, >>>>>>>>>> directly using 802.15.4, or over other technologies such as >>> WiFi, >>>>>>>>>> Ethernet, GPRS, etc. This really opens up the network >>> architecture >>>>>>>>>> possibilities, and there are many cases where adding these >>>>>>> additional >>>>>>>>>> links are desirable. I know that ISA's proposed backbone > routers >>>>>>>>> provide >>>>>>>>>> this functionality, but I'd rather support such networks at > the >>> IP >>>>>>>>>> layer, rather than abstracting a combination of link >>> technologies >>>>> as >>>>>>>>>> single IP link and defining any new machinery to do so. >>>>>>>>>> >>>>>>>>>> BTW it's great that we're having this discussion. It is long >>>>>>> overdue. >>>>>>>>>> -- >>>>>>>>>> Jonathan Hui >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>>>> Hi Jonathan: >>>>>>>>>>> >>>>>>>>>>> You are assuming explicitly that I am assuming implicitly... >>> mesh >>>>>>>>>>> under... Hum. >>>>>>>>>>> >>>>>>>>>>> Please have a look at >>>>>>>>>>> > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>>>>>>>>>> -00.txt and it should be apparent that I'm not. In particular >>> the >>>>>>>>>>> backbone router is the device that will set and use the hop >>> limit >>>>>>>>> bit. >>>>>>>>>>> So will all those interconnecting devices used in pseudowire, >>>>> split >>>>>>>>>>> bridges, IP Mobility, etc... if they are deployed in this >>> space. >>>>>>>>>>> What I'm really assuming is a gateway or an edge server on > the >>>>>>> link. >>>>>>>>>>> It's there in most architectures that I know of at this point >>>>>>> that's >>>>>>>>> why >>>>>>>>>>> I included it in the case we shoot for and saved 2 bits. Note >>>>> that >>>>>>>>> when >>>>>>>>>>> the ULA and global addresses are used on top of link local, > it >>>>>>> makes >>>>>>>>>>> sense that we define a mechanism to compress them as well. > But >>>>> this >>>>>>>>> is >>>>>>>>>>> not what HC3 is about. >>>>>>>>>>> >>>>>>>>>>> The goal of my initial proposal is illustrative, to foster > this >>>>>>> very >>>>>>>>>>> discussion around the idea that we can shoot for a favorite >>> case >>>>>>> and >>>>>>>>>>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a >>>>> group >>>>>>>>>>> think that the GW assumption is not reasonable, then, fine, > let >>>>> us >>>>>>>>>>> affect 2 bits in HC3 to indicate whether the addresses are >>>>>>>>> compressed. >>>>>>>>>>> What do the others think? >>>>>>>>>>> >>>>>>>>>>> Pascal >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>>>>>>>> Sent: mardi 4 mars 2008 18:05 >>>>>>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>>>>>> Cc: 6lowpan; enns@stanfordalumni.org; Jay Werb >>>>>>>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Pascal, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for sharing your thoughts. >>>>>>>>>>>> >>>>>>>>>>>> By assuming the first 5 bits in HC1 are '1', you're staking > a >>>>>>> claim >>>>>>>>>>> that >>>>>>>>>>>> mesh-under link-local communication within a PAN is going to >>> be >>>>>>> most >>>>>>>>>>>> common case and the one we've "shot for". If link-local is > all >>>>> we >>>>>>>>> focus >>>>>>>>>>>> on, then we are missing the point of IP. Frankly, I don't > see >>>>> much >>>>>>>>>>>> benefit of IP if communication is limited to the PAN. >>>>>>>>>>>> >>>>>>>>>>>> W.r.t mesh-under, there are efforts within the IETF that >>> assume >>>>>>>>> 6LoWPAN >>>>>>>>>>>> nodes will communicate via route-over using routable > addresses >>>>>>> (e.g. >>>>>>>>>>>> ROLL). This brings us back to a broader topic of route-under >>> vs. >>>>>>>>>>>> mesh-under. While both will probably exist for some time, it >>>>>>> raises >>>>>>>>> the >>>>>>>>>>>> question of whether 6LoWPAN implementations can support one > or >>>>> do >>>>>>>>> they >>>>>>>>>>>> have to support both. >>>>>>>>>>>> >>>>>>>>>>>> W.r.t compressing Hop Limit, I don't quite understand why >>> you're >>>>>>>>> using >>>>>>>>>>> a >>>>>>>>>>>> bit in HC3 to indicate where the message originated. If > you're >>>>>>>>> assuming >>>>>>>>>>>> link-local communication, then messages shouldn't be > forwarded >>>>>>>>> across >>>>>>>>>>>> links anyway. >>>>>>>>>>>> >>>>>>>>>>>> I do agree that there is work to do on compression and agree >>>>> that >>>>>>>>> there >>>>>>>>>>>> are cases where HC1 and HC2 are not sufficient. This is why >>> I've >>>>>>>>> been >>>>>>>>>>>> working, albeit slowly, on HC1g. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Jonathan Hui >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>>>>>> Dear 6LoWPANers, >>>>>>>>>>>>> >>>>>>>>>>>>> Though HC1 and HC2 provide us with the capability to > express >>>>> any >>>>>>>>>>>>> combination of compression, the most expected (or at least >>> shot >>>>>>>>> for) >>>>>>>>>>>>> case does not lead to a better compression of the HC > headers >>>>>>>>>>> themselves. >>>>>>>>>>>>> Seems that we could define an HC3 that would compress the >>> pair >>>>> of >>>>>>>>> HC1 >>>>>>>>>>>>> and HC2 for that best case. My proposal for doing this > would >>> be >>>>>>> to: >>>>>>>>>>>>> - define a new dispatch >>>>>>>>>>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed >>> IPv6 >>>>>>> and >>>>>>>>>>>>> transport >>>>>>>>>>>>> >>>>>>>>>>>>> - define HC3 itself to: >>>>>>>>>>>>> >>>>>>>>>>>>> - implicitly say that the first 5 bits of HC1 are all >>>>> ones >>>>>>>>>>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>>>>>>>>>> - replace HC2 so bit 7 of HC1 is useless >>>>>>>>>>>>> - provide transport specific bits such as those > defined >>>>> for >>>>>>>>>>>>> HC-UDP, >>>>>>>>>>>>> then again assuming a predefined best case if room > is >>>>>>>>> missing >>>>>>>>>>>>> An example of what the HC3 octet could be: >>>>>>>>>>>>> >>>>>>>>>>>>> bits 0 1 2-3 >>>>>>>>>>>>> 4-7 >>>>>>>>>>>>> >>>>>>>>>>>>> > +------------------+-------------+-----------------+-------------------- >>>>>>>>>>>>> ---------------------+ >>>>>>>>>>>>> | reserved | reserved | Next Header | >>>>>>>>>>> transport >>>>>>>>>>>>> specific control bits | >>>>>>>>>>>>> >>>>>>>>>>>>> > +------------------+-------------+-----------------+-------------------- >>>>>>>>>>>>> ---------------------+ >>>>>>>>>>>>> >>>>>>>>>>>>> Next header: as defined in HC1, bits 5 and 6 >>>>>>>>>>>>> >>>>>>>>>>>>> transport specific control bits for UDP: >>>>>>>>>>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>>>>>>>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>>>>>>>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>>>>>>>>>> bit 7 is reserved >>>>>>>>>>>>> >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> Pascal >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 Mar 6 05:12:04 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B28728C500; Thu, 6 Mar 2008 05:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.924 X-Spam-Level: X-Spam-Status: No, score=-100.924 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Y78VgFZUMF7y; Thu, 6 Mar 2008 05:11:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB5A3A68EA; Thu, 6 Mar 2008 05:11:58 -0800 (PST) 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 A60AE3A6B09 for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 05:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 fiH8RG560+oH for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 05:11:53 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9079228C3A5 for <6lowpan@ietf.org>; Thu, 6 Mar 2008 05:11:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,455,1199660400"; d="scan'208";a="2709998" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Mar 2008 14:11:42 +0100 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 m26DBgHl023009; Thu, 6 Mar 2008 14:11:42 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m26DBSHE029924; Thu, 6 Mar 2008 13:11:37 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, 6 Mar 2008 14:11:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 14:10:57 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC054D7CDE@xmb-ams-337.emea.cisco.com> In-Reply-To: <47CF2727.3030202@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Compressing HC1 and HC2 into HC3 thread-index: Ach/FXO8bo8cnIpWQqW2lgQYEZYAUAAdNq1A From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 06 Mar 2008 13:11:28.0988 (UTC) FILETIME=[96F501C0:01C87F8B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=613; t=1204809103; x=1205673103; 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]=20Compressing=20HC1=20and=20H C2=20into=20HC3 |Sender:=20; bh=GUfgY7825pt/EqlrqDFVim6IRDrwXV8VJv84wuYuHhE=; b=gIRAMXZWbJRM/7bvRyDXlGyGLh3tODSNiG/12L3TRxTIP647yrLv8LfAms OOoBHl49V1n3Lu6HWXLww/dfXmwBS7xw2ma9WhuGHYc29gz7zxM0nS0+mMGN t3Por1IC22; 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] Compressing HC1 and HC2 into HC3 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 and all: I'd wish to move forward on the original subject for this thread. Basically the question is whether it is worth consuming a dispatch for an HC3 that would represent the best case of what HC1 and HC2 can compress. Pros: saves one byte in the headers and a fast path in the code Cons: Additional encoding complexity and one dispatch. On the side, there's a compression mechanism coming up for ULA/GLO (HC1g). Can we make HC3 ready for that upcoming mechanism? Should we wait? I'll ask Geoff if some discussion can happen in Philly to conclude on the topic. Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 05:42:05 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2AB28C5DB; Thu, 6 Mar 2008 05:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.605 X-Spam-Level: X-Spam-Status: No, score=-100.605 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 kfmMMzD3LKXo; Thu, 6 Mar 2008 05:42:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD4128C500; Thu, 6 Mar 2008 05:42:04 -0800 (PST) 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 93B7D28C1EC for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 05:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 AEWuLUXedPhw for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 05:42:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1A58028C47A for <6lowpan@ietf.org>; Thu, 6 Mar 2008 05:42:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,456,1199660400"; d="scan'208";a="2714512" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Mar 2008 14:41:50 +0100 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 m26DfoZQ026343; Thu, 6 Mar 2008 14:41:50 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m26DflHO013857; Thu, 6 Mar 2008 13:41:48 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, 6 Mar 2008 14:41:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 14:41:06 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC054D7D0B@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HC1g and HC2g thread-index: Ach/j7qVkhSpyCcBSwaQX/536jx62g== From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 06 Mar 2008 13:41:39.0084 (UTC) FILETIME=[CDDBBCC0:01C87F8F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2061; t=1204810910; x=1205674910; 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:=20HC1g=20and=20HC2g |Sender:=20; bh=fjcqQ2xAPKnp7ibWFDWDjZ7rDB6mZxwYyJmmpnB6nDc=; b=tPTWi2LFE1x/FH0yREGeKZ+621PpnJ2rsVY8MXkUP3PdOiPjv561+aUEiE BHI1x4jllutlkpkWXPc+XR5kOCHJoXsc+bcMwHwOJul+3wOC4Lc6BsflfW2I SYZ22yEio5; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] HC1g and HC2g 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: We've been discussing HC1g quite extensively. I'd wish to discuss variations on your initial proposal: ------------------------------------------------------ The LOWPAN_HC1g encoding as currently in the draft 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | SC | DC |VTF| NH |L4C| +---+---+---+---+---+---+---+---+ HC2g for UDP 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | S | D | L | reserved | +---+---+---+---+---+---+---+---+ ------------------------------------------------------ What seeems to be missing: - Hop limit compression (takes 2 bits) - UDP checksum compression My proposal includes to keep using the mesh header format for route over to carry the short addresses and hop limit. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | SC | DC |VTF| Hlim |L4C| +---+---+---+---+---+---+---+---+ HLIM: 00 not compressed 01 placed in the mesh header to count PAN hops 10 fully elided, packet generated inside the PAN 11 fully elided, packet came in a stub HC2g for UDP 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NH | S | D | L | C | rsvrd | +---+---+---+---+---+---+---+---+ C: checksum is compressed. Note1: with that new format you need an HC2g to be able to compress NH. I do not mind. Note2: if NH is 0 then the NH is placed after the HC2G as it is taken as an L4 parm not between HC1G and HC2G. The parsing of bits 2..7 depends on that NH. What do you think? Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 08:29:49 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7B128C1A5; Thu, 6 Mar 2008 08:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.154 X-Spam-Level: X-Spam-Status: No, score=-100.154 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 dm7vGyqZvlS0; Thu, 6 Mar 2008 08:29:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3363428C7F0; Thu, 6 Mar 2008 08:29:44 -0800 (PST) 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 CE71C3A6A4B for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 08:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 kX4VZc5yfFf7 for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 08:29:42 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 033F828C7F0 for <6lowpan@ietf.org>; Thu, 6 Mar 2008 08:28:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id DA16DA92E4; Thu, 6 Mar 2008 08:28:45 -0800 (PST) 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 Rty54y4QM3V0; Thu, 6 Mar 2008 08:28:39 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 16255A92E3; Thu, 6 Mar 2008 08:28:39 -0800 (PST) Message-ID: <47D01BB3.6060906@archrock.com> Date: Thu, 06 Mar 2008 08:28:35 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC054D7CDE@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC054D7CDE@xmb-ams-337.emea.cisco.com> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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 Pascal, Given that it looks like we can include two of your three proposals into HC1g, I'm not so sure whether defining a new format adds that much benefit. Adding the ability to elide the UDP checksum and the hop limit into HC1g already provides 3 bytes of savings. Compared to your proposed modifications to HC1g, HC3 only saves one byte (which you've observed). I'll put this idea out now, but I believe HC1g has the potential to supersede HC1+HC2. Really, we should rename HC1g to be something like HCx since it's not really specific to routable addresses. My alternative proposal is as follows: - Use the HCx format for both link-local and non-link-local communication. - Define a dispatch HCl when communicating with link-local addresses. - Define a dispatch HCr when communicating with routable addresses. The reason why I'm pushing for a single format is that I believe the most optimized code will work with the format directly to save RAM and code. That means that 6LoWPAN nodes generally do not expand compressed datagrams into uncompressed datagrams and the other way around. Thus, it involves more than just the encoder/decoder functions and could involve the entire stack (including the application). What do you/others think? -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi Jonathan and all: > > I'd wish to move forward on the original subject for this thread. > > Basically the question is whether it is worth consuming a dispatch for > an HC3 that would represent the best case of what HC1 and HC2 can > compress. > > Pros: saves one byte in the headers and a fast path in the code > Cons: Additional encoding complexity and one dispatch. > > On the side, there's a compression mechanism coming up for ULA/GLO > (HC1g). > Can we make HC3 ready for that upcoming mechanism? Should we wait? > > I'll ask Geoff if some discussion can happen in Philly to conclude on > the topic. > > Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 08:57:43 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269E93A6895; Thu, 6 Mar 2008 08:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.116 X-Spam-Level: X-Spam-Status: No, score=-100.116 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Y7FZGt24JyUj; Thu, 6 Mar 2008 08:57:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D04E28C514; Thu, 6 Mar 2008 08:57:39 -0800 (PST) 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 AD63828C514 for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 08:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 5t-+Uhj9fxYk for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 08:57:36 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id DC1A83A6975 for <6lowpan@ietf.org>; Thu, 6 Mar 2008 08:57:36 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id BA9E4A920B; Thu, 6 Mar 2008 08:57:26 -0800 (PST) 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 eVC4GqfFmNM2; Thu, 6 Mar 2008 08:57:19 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 9C9D9A9165; Thu, 6 Mar 2008 08:57:19 -0800 (PST) Message-ID: <47D0226B.4000003@archrock.com> Date: Thu, 06 Mar 2008 08:57:15 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC054D7D0B@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC054D7D0B@xmb-ams-337.emea.cisco.com> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] HC1g and HC2g 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 Pascal, I think it's reasonable to incorporate some of your ideas into HC1g. UDP checksums make sense. I also understand the motivation for eliding the Hop Limit field. But I'd like to find a way to make it only a single bit. The motivation for this is in the following paragraph. To me, eliding the Hop Limit field only makes sense when communicating over a single IP hop. How about a single bit states if the HLIM is elided or not, and can only be elided when one of the L3 addresses are completely elided. The latter restriction ensures that Hop Limit is only elided on the 6LoWPAN side for a single IP hop. Am I missing a case here? If we can remove one bit from HLIM, then I think we can move the NH field back into HC1. I would remove the L4C bit and say that if NH is non-zero, then HC2 must be included. I believe NH is still part of the L3 header, so it should remain in HC1. The S, D, L, and C fields in HC2 should remain there because they are UDP specific. Also, I was proposing to move HC2 to the start of the L4 header and putting the NH field there seems strange to me. What do you think? -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi Jonathan: > > We've been discussing HC1g quite extensively. I'd wish to discuss > variations on your initial proposal: > > ------------------------------------------------------ > The LOWPAN_HC1g encoding as currently in the draft > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | SC | DC |VTF| NH |L4C| > +---+---+---+---+---+---+---+---+ > > HC2g for UDP > > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | S | D | L | reserved | > +---+---+---+---+---+---+---+---+ > > > ------------------------------------------------------ > > What seeems to be missing: > > - Hop limit compression (takes 2 bits) > - UDP checksum compression > > > My proposal includes to keep using the mesh header format for route over > to carry the short addresses and hop limit. > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | SC | DC |VTF| Hlim |L4C| > +---+---+---+---+---+---+---+---+ > > HLIM: > 00 not compressed > 01 placed in the mesh header to count PAN hops > 10 fully elided, packet generated inside the PAN > 11 fully elided, packet came in a stub > > > > HC2g for UDP > > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | NH | S | D | L | C | rsvrd | > +---+---+---+---+---+---+---+---+ > > C: checksum is compressed. > > Note1: with that new format you need an HC2g to be able to compress NH. > I do not mind. > Note2: if NH is 0 then the NH is placed after the HC2G as it is taken as > an L4 parm not between HC1G and HC2G. The parsing of bits 2..7 depends > on that NH. > > What do you think? > > Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 12:17:16 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE6828C901; Thu, 6 Mar 2008 12:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.601 X-Spam-Level: X-Spam-Status: No, score=-100.601 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 i51AulrVDiOF; Thu, 6 Mar 2008 12:17:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593D128C943; Thu, 6 Mar 2008 12:17:15 -0800 (PST) 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 B99703A6828 for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 12:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 XKmclpwyhoBE for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 12:17:08 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B3CFD28C36F for <6lowpan@ietf.org>; Thu, 6 Mar 2008 12:17:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,457,1199660400"; d="scan'208";a="2757524" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Mar 2008 21:16:56 +0100 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 m26KGu3O011441; Thu, 6 Mar 2008 21:16:56 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m26KGmHC005552; Thu, 6 Mar 2008 20:16:48 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, 6 Mar 2008 21:16:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 21:16:17 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC054D7EA0@xmb-ams-337.emea.cisco.com> In-Reply-To: <47D0226B.4000003@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HC1g and HC2g thread-index: Ach/qy+QGjGmT3btQIyzBXCoPPGS5wAFoM4Q From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 06 Mar 2008 20:16:47.0999 (UTC) FILETIME=[017910F0:01C87FC7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4580; t=1204834616; x=1205698616; 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=20HC1g=20and=20HC2g |Sender:=20; bh=0aHJ0uf2hMKcrYItfZXzwrbTQysBZrTBcUZBpz0XlvU=; b=GhHuX7VJN4692cjcJGn24FR9nHLqW7hk+nuXad2LYx/elQGcwoKDyFQk3y bXjdye7EaFzgPrc5RFXCooqp0ROcB+WcHi6cnP/8SykgOQ5QHuHHn+TNYJYP tQOrlxash0; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Jay Werb , 6lowpan <6lowpan@ietf.org>, enns@stanfordalumni.org Subject: Re: [6lowpan] HC1g and HC2g 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: In a more general fashion, the hop limit can be elided over the first and the last L2 hops. On the first hop, either the packet reaches onlink destination, or the router that terminates the 6LoWPAN compression can use a default Hop limit to forward to the world. On the last hop, whatever is is above 1 is as good as 1 since you're done with L3. So the rules can turn out to be: - LoWPAN node that originates the packet can elide the Hop limit. - router performing local delivery over the LoWPAN can elide the Hop Limit ; else the Hop limit MUST NOT be compressed With that set of rules in place I think we're fine with one bit. There are a number of assumptions behind about proxy and stubs, but I think we're OK. I still like the idea to move the NH to HC2. Even if it is an IP header field, it really talks about the HC2 content, and that balances the preserved bits leaving flexibility in HC1G. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: jeudi 6 mars 2008 17:57 >To: Pascal Thubert (pthubert) >Cc: 6lowpan >Subject: Re: HC1g and HC2g > > >Hi Pascal, > >I think it's reasonable to incorporate some of your ideas into HC1g. UDP >checksums make sense. > >I also understand the motivation for eliding the Hop Limit field. But >I'd like to find a way to make it only a single bit. The motivation for >this is in the following paragraph. To me, eliding the Hop Limit field >only makes sense when communicating over a single IP hop. How about a >single bit states if the HLIM is elided or not, and can only be elided >when one of the L3 addresses are completely elided. The latter >restriction ensures that Hop Limit is only elided on the 6LoWPAN side >for a single IP hop. Am I missing a case here? > >If we can remove one bit from HLIM, then I think we can move the NH >field back into HC1. I would remove the L4C bit and say that if NH is >non-zero, then HC2 must be included. I believe NH is still part of the >L3 header, so it should remain in HC1. The S, D, L, and C fields in HC2 >should remain there because they are UDP specific. Also, I was proposing >to move HC2 to the start of the L4 header and putting the NH field there >seems strange to me. > >What do you think? > >-- >Jonathan Hui > > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >> We've been discussing HC1g quite extensively. I'd wish to discuss >> variations on your initial proposal: >> >> ------------------------------------------------------ >> The LOWPAN_HC1g encoding as currently in the draft >> >> 0 1 2 3 4 5 6 7 >> +---+---+---+---+---+---+---+---+ >> | SC | DC |VTF| NH |L4C| >> +---+---+---+---+---+---+---+---+ >> >> HC2g for UDP >> >> >> 0 1 2 3 4 5 6 7 >> +---+---+---+---+---+---+---+---+ >> | S | D | L | reserved | >> +---+---+---+---+---+---+---+---+ >> >> >> ------------------------------------------------------ >> >> What seeems to be missing: >> >> - Hop limit compression (takes 2 bits) >> - UDP checksum compression >> >> >> My proposal includes to keep using the mesh header format for route over >> to carry the short addresses and hop limit. >> >> 0 1 2 3 4 5 6 7 >> +---+---+---+---+---+---+---+---+ >> | SC | DC |VTF| Hlim |L4C| >> +---+---+---+---+---+---+---+---+ >> >> HLIM: >> 00 not compressed >> 01 placed in the mesh header to count PAN hops >> 10 fully elided, packet generated inside the PAN >> 11 fully elided, packet came in a stub >> >> >> >> HC2g for UDP >> >> >> 0 1 2 3 4 5 6 7 >> +---+---+---+---+---+---+---+---+ >> | NH | S | D | L | C | rsvrd | >> +---+---+---+---+---+---+---+---+ >> >> C: checksum is compressed. >> >> Note1: with that new format you need an HC2g to be able to compress NH. >> I do not mind. >> Note2: if NH is 0 then the NH is placed after the HC2G as it is taken as >> an L4 parm not between HC1G and HC2G. The parsing of bits 2..7 depends >> on that NH. >> >> What do you think? >> >> Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 13:01:59 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5689A28C5FE; Thu, 6 Mar 2008 13:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.116 X-Spam-Level: X-Spam-Status: No, score=-100.116 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 R6eE5Hhz9Eqf; Thu, 6 Mar 2008 13:01:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2FE28C2F4; Thu, 6 Mar 2008 13:01:52 -0800 (PST) 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 BE42728C2F4 for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 13:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 h79YZqqaXUlv for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 13:01:50 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 22C843A6E05 for <6lowpan@ietf.org>; Thu, 6 Mar 2008 13:01:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id DA089A92EC; Thu, 6 Mar 2008 13:01:37 -0800 (PST) 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 QvYGSu4EgHn6; Thu, 6 Mar 2008 13:01:31 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id B5AA0A92BA; Thu, 6 Mar 2008 13:01:30 -0800 (PST) Message-ID: <47D05BA6.6050609@archrock.com> Date: Thu, 06 Mar 2008 13:01:26 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC054D7EA0@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC054D7EA0@xmb-ams-337.emea.cisco.com> Cc: Jay Werb , 6lowpan <6lowpan@ietf.org>, enns@stanfordalumni.org Subject: Re: [6lowpan] HC1g and HC2g 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 Pascal, -- Jonathan Hui Pascal Thubert (pthubert) wrote: > On the first hop, either the packet reaches onlink destination, or the > router that terminates the 6LoWPAN compression can use a default Hop > limit to forward to the world. On the last hop, whatever is is above 1 > is as good as 1 since you're done with L3. > > So the rules can turn out to be: > > - LoWPAN node that originates the packet can elide the Hop limit. > - router performing local delivery over the LoWPAN can elide the Hop > Limit > ; else the Hop limit MUST NOT be compressed > > With that set of rules in place I think we're fine with one bit. There > are a number of assumptions behind about proxy and stubs, but I think > we're OK. Yup. The reason why I tied it to the eliding of L3 addresses is in the case where each 15.4 node is doing L3 forwarding and modifying the Hop Limit. I don't want a 15.4 node having to do a memmove() simply to insert a Hop Limit when forwarding it to the next hop. But I am fine with having a router that's forwarding to the outside world to eat this cost. Maybe the rule should state if more than one IP hop is taken in the PAN, then the Hop Limit must not be compressed. For the assumptions, yes, I'm continuing to assume that 15.4 nodes will operate in stub networks. > I still like the idea to move the NH to HC2. Even if it is an IP header > field, it really talks about the HC2 content, and that balances the > preserved bits leaving flexibility in HC1G. I had originally proposed with HC1g to move HC2 after the compressed L3 header. In this scenario, putting NH into HC2 doesn't work because the position of HC2 depends on whether the Next Hop field appears in the compressed L3 header or not. If you look at the IPv6 header architecture, the Next Header field always describes what header is coming next. So it's a pretty well understood concept. In the 6LoWPAN adaptation layer, however, we did design it in the way you suggest. If we want flexibility in the HC1 header, I'd argue replacing VTF with a bit that expands the HC1 header by another byte and put the VTF bit there. I like reserving extra room in the HC2 header because I'd also like to make provisions for using stateful compression of the UDP ports. -- Jonathan Hui > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: jeudi 6 mars 2008 17:57 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan >> Subject: Re: HC1g and HC2g >> >> >> Hi Pascal, >> >> I think it's reasonable to incorporate some of your ideas into HC1g. > UDP >> checksums make sense. >> >> I also understand the motivation for eliding the Hop Limit field. But >> I'd like to find a way to make it only a single bit. The motivation for >> this is in the following paragraph. To me, eliding the Hop Limit field >> only makes sense when communicating over a single IP hop. How about a >> single bit states if the HLIM is elided or not, and can only be elided >> when one of the L3 addresses are completely elided. The latter >> restriction ensures that Hop Limit is only elided on the 6LoWPAN side >> for a single IP hop. Am I missing a case here? >> >> If we can remove one bit from HLIM, then I think we can move the NH >> field back into HC1. I would remove the L4C bit and say that if NH is >> non-zero, then HC2 must be included. I believe NH is still part of the >> L3 header, so it should remain in HC1. The S, D, L, and C fields in HC2 >> should remain there because they are UDP specific. Also, I was > proposing >> to move HC2 to the start of the L4 header and putting the NH field > there >> seems strange to me. >> >> What do you think? >> >> -- >> Jonathan Hui >> >> >> Pascal Thubert (pthubert) wrote: >>> Hi Jonathan: >>> >>> We've been discussing HC1g quite extensively. I'd wish to discuss >>> variations on your initial proposal: >>> >>> ------------------------------------------------------ >>> The LOWPAN_HC1g encoding as currently in the draft >>> >>> 0 1 2 3 4 5 6 7 >>> +---+---+---+---+---+---+---+---+ >>> | SC | DC |VTF| NH |L4C| >>> +---+---+---+---+---+---+---+---+ >>> >>> HC2g for UDP >>> >>> >>> 0 1 2 3 4 5 6 7 >>> +---+---+---+---+---+---+---+---+ >>> | S | D | L | reserved | >>> +---+---+---+---+---+---+---+---+ >>> >>> >>> ------------------------------------------------------ >>> >>> What seeems to be missing: >>> >>> - Hop limit compression (takes 2 bits) >>> - UDP checksum compression >>> >>> >>> My proposal includes to keep using the mesh header format for route > over >>> to carry the short addresses and hop limit. >>> >>> 0 1 2 3 4 5 6 7 >>> +---+---+---+---+---+---+---+---+ >>> | SC | DC |VTF| Hlim |L4C| >>> +---+---+---+---+---+---+---+---+ >>> >>> HLIM: >>> 00 not compressed >>> 01 placed in the mesh header to count PAN hops >>> 10 fully elided, packet generated inside the PAN >>> 11 fully elided, packet came in a stub >>> >>> >>> >>> HC2g for UDP >>> >>> >>> 0 1 2 3 4 5 6 7 >>> +---+---+---+---+---+---+---+---+ >>> | NH | S | D | L | C | rsvrd | >>> +---+---+---+---+---+---+---+---+ >>> >>> C: checksum is compressed. >>> >>> Note1: with that new format you need an HC2g to be able to compress > NH. >>> I do not mind. >>> Note2: if NH is 0 then the NH is placed after the HC2G as it is taken > as >>> an L4 parm not between HC1G and HC2G. The parsing of bits 2..7 > depends >>> on that NH. >>> >>> What do you think? >>> >>> Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 13:17:24 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE70928C9AB; Thu, 6 Mar 2008 13:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.383 X-Spam-Level: X-Spam-Status: No, score=-100.383 tagged_above=-999 required=5 tests=[AWL=-1.341, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 wH006rk95E7l; Thu, 6 Mar 2008 13:17:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0C728C927; Thu, 6 Mar 2008 13:17:23 -0800 (PST) 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 37EF628C914 for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 13:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 yDfgyJRLVA-p for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 13:17:20 -0800 (PST) Received: from mail.nivis.com (mail.nivis.com [65.205.163.229]) by core3.amsl.com (Postfix) with SMTP id BFE5728C913 for <6lowpan@ietf.org>; Thu, 6 Mar 2008 13:17:19 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 16:17:00 -0500 Message-ID: In-Reply-To: <200803021021.10955.coflynn@newae.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Syncronized Wake thread-index: Ach8cddTZgHiUWeZQJelMzA7syWPowDXH63g References: <200803021021.10955.coflynn@newae.com> From: "Robert Assimiti" To: "Colin O'Flynn" , <6lowpan@ietf.org> Subject: Re: [6lowpan] Syncronized Wake 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-8859-1" Content-Transfer-Encoding: quoted-printable Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hello Colin, The currently undergoing ISA100.11a standardization effort would be the per= fect paradigm for what you are trying to accomplish. It is a standard geare= d towards industrial process and automation, but it definitely has applicab= ility in commercial applications as well. Currently employing the 802.15.4 PHY/MAC (although alternate PHY/MACs are b= eing considered), the Field Devices (FFD/RFDs in 802.15.4 semantics) commun= icate during strictly enforced "time slots" without using beacons. This all= ows for prolonged battery life although frequent time synchronization messa= ges must be exchanged. Let me know if you are interested in more details. "The nice thing about standards is that there are so many to choose from." = - Andrew S. Tanenbaum = Robert Assimiti Executive Staff=A0Engineer Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Colin O'Flynn Sent: Sunday, March 02, 2008 9:21 AM To: 6lowpan@ietf.org Subject: [6lowpan] Syncronized Wake Hello All, First a quick question - I found this list on the IETF site. I assume it's = a = public list, you don't have to be a member of the working group to submit? Anyway, a few of us are working on doing a 6lowpan implementation. I was = looking at doing a 'syncronized wake' to help save power yet get reasonable = response times. By my calculations you could wake every few seconds and sti= ll = have an exceptional battery life (year+). = Since some nodes might need to wake up more often than others they might ha= ve = different schedules, and obviously you'd need some sort of beacon to = syncronize. The idea is each node has a "wake schedule" that nearby nodes = know, and will be listening at that time. But any node can TX at almost any = time. I don't want to do GTS though, as nodes can talk at any time. But I need a = way = to (a) sync nodes and (b) transmit wake schedule. So the question: would their be a standards-compliant way to do this? Or is= it = worth it trying to be standards compliant at this stage? It would be easy = enough to make some simple protocol up to do this for testing. Warm Regards, -Colin O'Flynn PS: If you are interested: hardware is 8-bit AVR devices, using uIP for IPv= 6 = implementation. The gateway router is AVR32 device, which can route over = ethernet. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan This e-mail (including any attachments to it) is confidential, proprietary,= legally privileged, subject to copyright and is sent for the personal atte= ntion of the intended recipient only. If you have received this e-mail in e= rror, please reply to advise us immediately, delete it and destroy any prin= ted copies of it. You are notified that reading, disclosing, copying, distr= ibuting or taking any action in reliance on the contents of this informatio= n is strictly prohibited. No employee is authorized to conclude any binding= agreement on behalf of NIVIS LLC with another party by e-mail without expr= ess written confirmation by an officer of the company. Although we have tak= en reasonable precautions to ensure no viruses are present in this e-mail, = we cannot accept responsibility for any loss or damage arising from the vir= uses in this e-mail or attachments. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 13:40:06 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 209E328C9C5; Thu, 6 Mar 2008 13:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.577 X-Spam-Level: X-Spam-Status: No, score=-100.577 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 4VpPBxRroZD1; Thu, 6 Mar 2008 13:40:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAEAA28C260; Thu, 6 Mar 2008 13:40:04 -0800 (PST) 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 1C7E928C986 for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 13:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 0nAJ2+plwEsL for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 13:40:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E62D028C9EA for <6lowpan@ietf.org>; Thu, 6 Mar 2008 13:39:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,458,1199660400"; d="scan'208";a="2761687" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Mar 2008 22:35:29 +0100 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 m26LZTr8025978; Thu, 6 Mar 2008 22:35:29 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m26LZPHC025876; Thu, 6 Mar 2008 21:35:25 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, 6 Mar 2008 22:35:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 22:34:52 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC054D7ECA@xmb-ams-337.emea.cisco.com> In-Reply-To: <47D05BA6.6050609@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HC1g and HC2g thread-index: Ach/zUu/HceKy11VTzafooGhR8Xl+AAAg8wg From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 06 Mar 2008 21:35:25.0238 (UTC) FILETIME=[FD2A9D60:01C87FD1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6554; t=1204839329; x=1205703329; 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=20HC1g=20and=20HC2g |Sender:=20; bh=0zBPJsgVhbBAYjXfxewQFrHujy8nUbWhfsBpAI7h8ug=; b=qP77kLDnKTTAR/e+lrOZqEuee51TXLg06NC8CdutRXdWI0LkdmHADWHNvZ om+Nt/Cp15yqn7vK36dtkW0+O1JrQKUgsazWza39g02SP7TLSa5kvDqPv0XF vx+lHg3SAb; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Jay Werb , 6lowpan <6lowpan@ietf.org>, enns@stanfordalumni.org Subject: Re: [6lowpan] HC1g and HC2g 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 > >Yup. The reason why I tied it to the eliding of L3 addresses is in the >case where each 15.4 node is doing L3 forwarding and modifying the Hop >Limit. I don't want a 15.4 node having to do a memmove() simply to >insert a Hop Limit when forwarding it to the next hop. But I am fine >with having a router that's forwarding to the outside world to eat this >cost. Maybe the rule should state if more than one IP hop is taken in >the PAN, then the Hop Limit must not be compressed. [Pascal] I would not use must :) but I see what you're saying. If you have RFD types of devices they wouldn't know what to expect. They can be configured to do one way or the other for a given deployment. Note that with the single bit, we can not detect the case where a packet bounces from one router to another due to improper L2 operation but stays within the PAN. > >For the assumptions, yes, I'm continuing to assume that 15.4 nodes will >operate in stub networks. > >> I still like the idea to move the NH to HC2. Even if it is an IP header >> field, it really talks about the HC2 content, and that balances the >> preserved bits leaving flexibility in HC1G. > >I had originally proposed with HC1g to move HC2 after the compressed L3 >header. In this scenario, putting NH into HC2 doesn't work because the >position of HC2 depends on whether the Next Hop field appears in the >compressed L3 header or not. If you look at the IPv6 header >architecture, the Next Header field always describes what header is >coming next. So it's a pretty well understood concept. In the 6LoWPAN >adaptation layer, however, we did design it in the way you suggest. > [Pascal] Remember I took great care to place the expanded NH after HC2. So that it works (see the note at the very bottom of this mail). Just that when you read HC2, if the HC bits are 0 you need to read the full HC after HC2 to parse the bits in HC2. I do think it's still cleanly putting L4 things together - and TLV is also a well understood concept ;) >If we want flexibility in the HC1 header, I'd argue replacing VTF with a >bit that expands the HC1 header by another byte and put the VTF bit >there. I like reserving extra room in the HC2 header because I'd also >like to make provisions for using stateful compression of the UDP ports. [Pascal] But will that be enough anyway? Hard to know what to reserve for this so I'd do whatever seems right with what I have. I'd rather expand HC2 later with whatever room you need when you know more precisely what it is you need and leave VTF in place right now... Pascal > >-- >Jonathan Hui > > >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: jeudi 6 mars 2008 17:57 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan >>> Subject: Re: HC1g and HC2g >>> >>> >>> Hi Pascal, >>> >>> I think it's reasonable to incorporate some of your ideas into HC1g. >> UDP >>> checksums make sense. >>> >>> I also understand the motivation for eliding the Hop Limit field. But >>> I'd like to find a way to make it only a single bit. The motivation for >>> this is in the following paragraph. To me, eliding the Hop Limit field >>> only makes sense when communicating over a single IP hop. How about a >>> single bit states if the HLIM is elided or not, and can only be elided >>> when one of the L3 addresses are completely elided. The latter >>> restriction ensures that Hop Limit is only elided on the 6LoWPAN side >>> for a single IP hop. Am I missing a case here? >>> >>> If we can remove one bit from HLIM, then I think we can move the NH >>> field back into HC1. I would remove the L4C bit and say that if NH is >>> non-zero, then HC2 must be included. I believe NH is still part of the >>> L3 header, so it should remain in HC1. The S, D, L, and C fields in HC2 >>> should remain there because they are UDP specific. Also, I was >> proposing >>> to move HC2 to the start of the L4 header and putting the NH field >> there >>> seems strange to me. >>> >>> What do you think? >>> >>> -- >>> Jonathan Hui >>> >>> >>> Pascal Thubert (pthubert) wrote: >>>> Hi Jonathan: >>>> >>>> We've been discussing HC1g quite extensively. I'd wish to discuss >>>> variations on your initial proposal: >>>> >>>> ------------------------------------------------------ >>>> The LOWPAN_HC1g encoding as currently in the draft >>>> >>>> 0 1 2 3 4 5 6 7 >>>> +---+---+---+---+---+---+---+---+ >>>> | SC | DC |VTF| NH |L4C| >>>> +---+---+---+---+---+---+---+---+ >>>> >>>> HC2g for UDP >>>> >>>> >>>> 0 1 2 3 4 5 6 7 >>>> +---+---+---+---+---+---+---+---+ >>>> | S | D | L | reserved | >>>> +---+---+---+---+---+---+---+---+ >>>> >>>> >>>> ------------------------------------------------------ >>>> >>>> What seeems to be missing: >>>> >>>> - Hop limit compression (takes 2 bits) >>>> - UDP checksum compression >>>> >>>> >>>> My proposal includes to keep using the mesh header format for route >> over >>>> to carry the short addresses and hop limit. >>>> >>>> 0 1 2 3 4 5 6 7 >>>> +---+---+---+---+---+---+---+---+ >>>> | SC | DC |VTF| Hlim |L4C| >>>> +---+---+---+---+---+---+---+---+ >>>> >>>> HLIM: >>>> 00 not compressed >>>> 01 placed in the mesh header to count PAN hops >>>> 10 fully elided, packet generated inside the PAN >>>> 11 fully elided, packet came in a stub >>>> >>>> >>>> >>>> HC2g for UDP >>>> >>>> >>>> 0 1 2 3 4 5 6 7 >>>> +---+---+---+---+---+---+---+---+ >>>> | NH | S | D | L | C | rsvrd | >>>> +---+---+---+---+---+---+---+---+ >>>> >>>> C: checksum is compressed. >>>> >>>> Note1: with that new format you need an HC2g to be able to compress >> NH. >>>> I do not mind. >>>> Note2: if NH is 0 then the NH is placed after the HC2G as it is taken >> as >>>> an L4 parm not between HC1G and HC2G. The parsing of bits 2..7 >> depends >>>> on that NH. >>>> >>>> What do you think? >>>> >>>> Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 13:53:25 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCB728C99D; Thu, 6 Mar 2008 13:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.663 X-Spam-Level: X-Spam-Status: No, score=-100.663 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 x4-fmqO7SHvj; Thu, 6 Mar 2008 13:53:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF7C28C152; Thu, 6 Mar 2008 13:53:21 -0800 (PST) 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 E112B3A6DD5 for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 13:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 6Pd4H9bNHatF for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 13:53:15 -0800 (PST) Received: from monty.telenet-ops.be (monty.telenet-ops.be [195.130.132.56]) by core3.amsl.com (Postfix) with ESMTP id 2B6F428C818 for <6lowpan@ietf.org>; Thu, 6 Mar 2008 13:53:15 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by monty.telenet-ops.be (Postfix) with SMTP id F1F4C54012; Thu, 6 Mar 2008 22:53:03 +0100 (CET) Received: from priveiqvfluhp9 (78-23-203-202.access.telenet.be [78.23.203.202]) by monty.telenet-ops.be (Postfix) with SMTP id C26E554050; Thu, 6 Mar 2008 22:53:03 +0100 (CET) Message-ID: <001e01c87fd4$7264c4a0$8300a8c0@priveiqvfluhp9> From: "Pieter De Mil" To: "Robert Assimiti" , "Colin O'Flynn" , <6lowpan@ietf.org> References: <200803021021.10955.coflynn@newae.com> Date: Thu, 6 Mar 2008 22:53:00 +0100 Organization: UGent 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 Subject: Re: [6lowpan] Syncronized Wake 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 Robert, I don't know if Colin is interested in more details, but I certainly am. How frequently do you have to exchange sync. messages? Every 10/60/.. seconds? How are your sync. messages scheduled? Via a distributed assignment? Do you use CSMA/CA in a time slot? Pieter ----- Original Message ----- From: "Robert Assimiti" To: "Colin O'Flynn" ; <6lowpan@ietf.org> Sent: Thursday, March 06, 2008 10:17 PM Subject: Re: [6lowpan] Syncronized Wake Hello Colin, The currently undergoing ISA100.11a standardization effort would be the perfect paradigm for what you are trying to accomplish. It is a standard geared towards industrial process and automation, but it definitely has applicability in commercial applications as well. Currently employing the 802.15.4 PHY/MAC (although alternate PHY/MACs are being considered), the Field Devices (FFD/RFDs in 802.15.4 semantics) communicate during strictly enforced "time slots" without using beacons. This allows for prolonged battery life although frequent time synchronization messages must be exchanged. Let me know if you are interested in more details. "The nice thing about standards is that there are so many to choose from." - Andrew S. Tanenbaum Robert Assimiti Executive Staff Engineer Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Colin O'Flynn Sent: Sunday, March 02, 2008 9:21 AM To: 6lowpan@ietf.org Subject: [6lowpan] Syncronized Wake Hello All, First a quick question - I found this list on the IETF site. I assume it's a public list, you don't have to be a member of the working group to submit? Anyway, a few of us are working on doing a 6lowpan implementation. I was looking at doing a 'syncronized wake' to help save power yet get reasonable response times. By my calculations you could wake every few seconds and still have an exceptional battery life (year+). Since some nodes might need to wake up more often than others they might have different schedules, and obviously you'd need some sort of beacon to syncronize. The idea is each node has a "wake schedule" that nearby nodes know, and will be listening at that time. But any node can TX at almost any time. I don't want to do GTS though, as nodes can talk at any time. But I need a way to (a) sync nodes and (b) transmit wake schedule. So the question: would their be a standards-compliant way to do this? Or is it worth it trying to be standards compliant at this stage? It would be easy enough to make some simple protocol up to do this for testing. Warm Regards, -Colin O'Flynn PS: If you are interested: hardware is 8-bit AVR devices, using uIP for IPv6 implementation. The gateway router is AVR32 device, which can route over ethernet. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments. _______________________________________________ 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 Mar 6 14:57:21 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539FD3A6C50; Thu, 6 Mar 2008 14:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.634 X-Spam-Level: X-Spam-Status: No, score=-100.634 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 2GVEBE3hR4ca; Thu, 6 Mar 2008 14:57:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918EB3A6AFE; Thu, 6 Mar 2008 14:57:20 -0800 (PST) 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 F1EC33A6A72 for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 14:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 Tvp8fgAiXPup for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 14:57:18 -0800 (PST) Received: from smtpout.eastlink.ca (smtpout.eastlink.ca [24.222.0.30]) by core3.amsl.com (Postfix) with ESMTP id 4DFEE3A691C for <6lowpan@ietf.org>; Thu, 6 Mar 2008 14:57:18 -0800 (PST) Received: from ip05.eastlink.ca ([24.222.39.68]) by mta02.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JXB00LD6ZR50AM1@mta02.eastlink.ca> for 6lowpan@ietf.org; Thu, 06 Mar 2008 18:57:05 -0400 (AST) Received: from blk-89-207-57.eastlink.ca (HELO [192.168.0.112]) ([24.89.207.57]) by ip05.eastlink.ca with ESMTP; Thu, 06 Mar 2008 18:46:47 -0400 Date: Thu, 06 Mar 2008 18:56:44 -0400 From: Colin O'Flynn In-reply-to: To: Robert Assimiti Message-id: <200803061856.45174.coflynn@newae.com> Organization: NewAE MIME-version: 1.0 Content-disposition: inline X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0BAAMG0EcYWc85/2dsb2JhbAAIrH4 X-IronPort-AV: E=Sophos;i="4.25,458,1199678400"; d="scan'208";a="144680383" References: <200803021021.10955.coflynn@newae.com> User-Agent: KMail/1.9.6 (enterprise 0.20071204.744707) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Syncronized Wake 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 Hello, > Let me know if you are interested in more details. Definitely! Let me know more details... Thanks, -Colin _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 15:00:04 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199C728C985; Thu, 6 Mar 2008 15:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.12 X-Spam-Level: X-Spam-Status: No, score=-100.12 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 yWRZAxXPfOVV; Thu, 6 Mar 2008 15:00:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7793A6A1E; Thu, 6 Mar 2008 15:00:02 -0800 (PST) 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 BF6253A691C for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 15:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 3Lpg8gk8mCAR for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 15:00:00 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 271A63A6B50 for <6lowpan@ietf.org>; Thu, 6 Mar 2008 15:00:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id E8E74A921E; Thu, 6 Mar 2008 14:59:49 -0800 (PST) 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 hBsPHSVr3K8X; Thu, 6 Mar 2008 14:59:43 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id D9C20A920A; Thu, 6 Mar 2008 14:59:42 -0800 (PST) Message-ID: <47D0775B.9070302@archrock.com> Date: Thu, 06 Mar 2008 14:59:39 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC054D7ECA@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC054D7ECA@xmb-ams-337.emea.cisco.com> Cc: Jay Werb , 6lowpan <6lowpan@ietf.org>, enns@stanfordalumni.org Subject: Re: [6lowpan] HC1g and HC2g 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 Pascal, Pascal Thubert (pthubert) wrote: >> Yup. The reason why I tied it to the eliding of L3 addresses is in the >> case where each 15.4 node is doing L3 forwarding and modifying the Hop >> Limit. I don't want a 15.4 node having to do a memmove() simply to >> insert a Hop Limit when forwarding it to the next hop. But I am fine >> with having a router that's forwarding to the outside world to eat this >> cost. Maybe the rule should state if more than one IP hop is taken in >> the PAN, then the Hop Limit must not be compressed. > > [Pascal] I would not use must :) but I see what you're saying. If you > have RFD types of devices they wouldn't know what to expect. They can be > configured to do one way or the other for a given deployment. I'm not strongly opposed to a memmove() because of the differences in computation vs. communication energy. However, I am opposed to doing memmove() repeatedly just to forward a message. To save memory, I'm guessing such insertions will occur in-place. That's why I was fishing for ideas to see if there's ways to avoid it. I didn't want to start going down a slippery slope. > Note that with the single bit, we can not detect the case where a packet > bounces from one router to another due to improper L2 operation but > stays within the PAN. If it's due to improper L2 operation, does having the Hop Limit field in the L3 header help us? >> I had originally proposed with HC1g to move HC2 after the compressed L3 >> header. In this scenario, putting NH into HC2 doesn't work because the >> position of HC2 depends on whether the Next Hop field appears in the >> compressed L3 header or not. If you look at the IPv6 header >> architecture, the Next Header field always describes what header is >> coming next. So it's a pretty well understood concept. In the 6LoWPAN >> adaptation layer, however, we did design it in the way you suggest. >> > [Pascal] Remember I took great care to place the expanded NH after HC2. > So that it works (see the note at the very bottom of this mail). Just > that when you read HC2, if the HC bits are 0 you need to read the full > HC after HC2 to parse the bits in HC2. I do think it's still cleanly > putting L4 things together - and TLV is also a well understood concept > ;) Ah, I didn't see your note at the bottom. Rather than having the Next Hop field be in potentially three different places, how about this idea: Leave the L4C bit in HC1 as before, but rename it to NHC for next-header compression (if NHC is 0, then the Next Header field is carried inline and no HC2 header appears; if NHC is 1, then an HC2 header follows). Then we define a HC2_UDP as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0|S|P|C| rsv | +-+-+-+-+-+-+-+-+ The difference here is that we fix the first bit as '0' for UDP and leave compression mechanisms for other Next Header values undefined for now. As we define new NHC compression mechanisms, they can be added by setting the first bit to '1' and some other bit-pattern following. It's a huffman-style encoding, but we're just assuming that UDP is going to be the most common case, so we give it the best case. I've also taken out the 'L' option, opting to say that UDP length should always be elided and derived from lower layers, just as we've done with the IP header. >> If we want flexibility in the HC1 header, I'd argue replacing VTF with > a >> bit that expands the HC1 header by another byte and put the VTF bit >> there. I like reserving extra room in the HC2 header because I'd also >> like to make provisions for using stateful compression of the UDP > ports. > > [Pascal] But will that be enough anyway? Hard to know what to reserve > for this so I'd do whatever seems right with what I have. I'd rather > expand HC2 later with whatever room you need when you know more > precisely what it is you need and leave VTF in place right now... Agreed. I was just trying to see if there are other ways to leave flexibility in the HC1 header. -- Jonathan Hui > > Pascal > >> -- >> Jonathan Hui >> >> >>> Pascal >>> >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: jeudi 6 mars 2008 17:57 >>>> To: Pascal Thubert (pthubert) >>>> Cc: 6lowpan >>>> Subject: Re: HC1g and HC2g >>>> >>>> >>>> Hi Pascal, >>>> >>>> I think it's reasonable to incorporate some of your ideas into HC1g. >>> UDP >>>> checksums make sense. >>>> >>>> I also understand the motivation for eliding the Hop Limit field. > But >>>> I'd like to find a way to make it only a single bit. The motivation > for >>>> this is in the following paragraph. To me, eliding the Hop Limit > field >>>> only makes sense when communicating over a single IP hop. How about > a >>>> single bit states if the HLIM is elided or not, and can only be > elided >>>> when one of the L3 addresses are completely elided. The latter >>>> restriction ensures that Hop Limit is only elided on the 6LoWPAN > side >>>> for a single IP hop. Am I missing a case here? >>>> >>>> If we can remove one bit from HLIM, then I think we can move the NH >>>> field back into HC1. I would remove the L4C bit and say that if NH > is >>>> non-zero, then HC2 must be included. I believe NH is still part of > the >>>> L3 header, so it should remain in HC1. The S, D, L, and C fields in > HC2 >>>> should remain there because they are UDP specific. Also, I was >>> proposing >>>> to move HC2 to the start of the L4 header and putting the NH field >>> there >>>> seems strange to me. >>>> >>>> What do you think? >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> Pascal Thubert (pthubert) wrote: >>>>> Hi Jonathan: >>>>> >>>>> We've been discussing HC1g quite extensively. I'd wish to discuss >>>>> variations on your initial proposal: >>>>> >>>>> ------------------------------------------------------ >>>>> The LOWPAN_HC1g encoding as currently in the draft >>>>> >>>>> 0 1 2 3 4 5 6 7 >>>>> +---+---+---+---+---+---+---+---+ >>>>> | SC | DC |VTF| NH |L4C| >>>>> +---+---+---+---+---+---+---+---+ >>>>> >>>>> HC2g for UDP >>>>> >>>>> >>>>> 0 1 2 3 4 5 6 7 >>>>> +---+---+---+---+---+---+---+---+ >>>>> | S | D | L | reserved | >>>>> +---+---+---+---+---+---+---+---+ >>>>> >>>>> >>>>> ------------------------------------------------------ >>>>> >>>>> What seeems to be missing: >>>>> >>>>> - Hop limit compression (takes 2 bits) >>>>> - UDP checksum compression >>>>> >>>>> >>>>> My proposal includes to keep using the mesh header format for route >>> over >>>>> to carry the short addresses and hop limit. >>>>> >>>>> 0 1 2 3 4 5 6 7 >>>>> +---+---+---+---+---+---+---+---+ >>>>> | SC | DC |VTF| Hlim |L4C| >>>>> +---+---+---+---+---+---+---+---+ >>>>> >>>>> HLIM: >>>>> 00 not compressed >>>>> 01 placed in the mesh header to count PAN hops >>>>> 10 fully elided, packet generated inside the PAN >>>>> 11 fully elided, packet came in a stub >>>>> >>>>> >>>>> >>>>> HC2g for UDP >>>>> >>>>> >>>>> 0 1 2 3 4 5 6 7 >>>>> +---+---+---+---+---+---+---+---+ >>>>> | NH | S | D | L | C | rsvrd | >>>>> +---+---+---+---+---+---+---+---+ >>>>> >>>>> C: checksum is compressed. >>>>> >>>>> Note1: with that new format you need an HC2g to be able to compress >>> NH. >>>>> I do not mind. >>>>> Note2: if NH is 0 then the NH is placed after the HC2G as it is > taken >>> as >>>>> an L4 parm not between HC1G and HC2G. The parsing of bits 2..7 >>> depends >>>>> on that NH. >>>>> >>>>> What do you think? >>>>> >>>>> Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 15:30:51 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C240E28C9C8; Thu, 6 Mar 2008 15:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.555 X-Spam-Level: X-Spam-Status: No, score=-100.555 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 cKEZDQ8evK4U; Thu, 6 Mar 2008 15:30:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0C353A6A1D; Thu, 6 Mar 2008 15:30:50 -0800 (PST) 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 C517F3A6A1D for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 15:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 2TgQekCCjw4l for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 15:30:48 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 491A43A6937 for <6lowpan@ietf.org>; Thu, 6 Mar 2008 15:30:48 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Mar 2008 00:30:36 +0100 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 m26NUakR013114; Fri, 7 Mar 2008 00:30:36 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m26NUQHI023729; Thu, 6 Mar 2008 23:30:36 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, 7 Mar 2008 00:30:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Mar 2008 00:29:57 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC054D7EF2@xmb-ams-337.emea.cisco.com> In-Reply-To: <47D01BB3.6060906@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Compressing HC1 and HC2 into HC3 thread-index: Ach/pzAH0CWsb15pR7qI1+rtXUj8vwAANaHg From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 06 Mar 2008 23:30:30.0874 (UTC) FILETIME=[113F0BA0:01C87FE2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2989; t=1204846236; x=1205710236; 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]=20Compressing=20HC1=20and=20H C2=20into=20HC3 |Sender:=20; bh=FB7c6HCHQlruHX+Zfmzcw6GWBf+04LyswSSRMOlS/Qw=; b=qtKaJPihrf3eDVZXf6EHejx3vTsJplgYGc6BBV4LpxFVjTtlOR8lkF5fsz YXkwfe/ve9Xt02A9Z6ziMp9ac9ud6P2Qf0ypiIV82i869I6vRyRac3XNlU9i QYikVtYbba; 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] Compressing HC1 and HC2 into HC3 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'm can't wait to see the proposal that saves the 3 additional bytes as we discussed turn into a WG doc, and that would be the priority. I'm also concerned that the 3 bytes be elided when the addresses are link local because that's the current use in ISA100, though I'm pretty sure we could use HC1G there. I think that the work on compressing the HCs themselves is also important because each byte in the headers is a percentage of battery-life (or something). And that's mostly orthogonal work. They intersect if: - we need to delay HC3 till HC1's are well defined - We're missing dispatch bits. So I still wish to have the question discussed in Philly if that's possible within constraints... Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: jeudi 6 mars 2008 17:29 >To: Pascal Thubert (pthubert) >Cc: 6lowpan >Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 > > >Hi Pascal, > >Given that it looks like we can include two of your three proposals into >HC1g, I'm not so sure whether defining a new format adds that much >benefit. Adding the ability to elide the UDP checksum and the hop limit >into HC1g already provides 3 bytes of savings. Compared to your proposed >modifications to HC1g, HC3 only saves one byte (which you've observed). >I'll put this idea out now, but I believe HC1g has the potential to >supersede HC1+HC2. Really, we should rename HC1g to be something like >HCx since it's not really specific to routable addresses. > >My alternative proposal is as follows: >- Use the HCx format for both link-local and non-link-local communication. >- Define a dispatch HCl when communicating with link-local addresses. >- Define a dispatch HCr when communicating with routable addresses. > >The reason why I'm pushing for a single format is that I believe the >most optimized code will work with the format directly to save RAM and >code. That means that 6LoWPAN nodes generally do not expand compressed >datagrams into uncompressed datagrams and the other way around. Thus, it >involves more than just the encoder/decoder functions and could involve >the entire stack (including the application). > >What do you/others think? > >-- >Jonathan Hui > > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan and all: >> >> I'd wish to move forward on the original subject for this thread. >> >> Basically the question is whether it is worth consuming a dispatch for >> an HC3 that would represent the best case of what HC1 and HC2 can >> compress. >> >> Pros: saves one byte in the headers and a fast path in the code >> Cons: Additional encoding complexity and one dispatch. >> >> On the side, there's a compression mechanism coming up for ULA/GLO >> (HC1g). >> Can we make HC3 ready for that upcoming mechanism? Should we wait? >> >> I'll ask Geoff if some discussion can happen in Philly to conclude on >> the topic. >> >> Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 15:41:18 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0D228CA02; Thu, 6 Mar 2008 15:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.539 X-Spam-Level: X-Spam-Status: No, score=-100.539 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 hklOdrby4BKz; Thu, 6 Mar 2008 15:41:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537FB3A6937; Thu, 6 Mar 2008 15:41:17 -0800 (PST) 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 4E6A43A69FA for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 15:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 Jlzultel6wf8 for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 15:41:14 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 24AED28C9DD for <6lowpan@ietf.org>; Thu, 6 Mar 2008 15:41:10 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Mar 2008 00:40:59 +0100 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 m26NexeL020799; Fri, 7 Mar 2008 00:40:59 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m26NexHC025515; Thu, 6 Mar 2008 23:40:59 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, 7 Mar 2008 00:40:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Mar 2008 00:40:29 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC054D7EF7@xmb-ams-337.emea.cisco.com> In-Reply-To: <47D0775B.9070302@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HC1g and HC2g thread-index: Ach/3eb4Ql3PhscQR9S6iLQU0gXoegABM5Jg From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 06 Mar 2008 23:40:59.0116 (UTC) FILETIME=[87B52AC0:01C87FE3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1330; t=1204846859; x=1205710859; 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=20HC1g=20and=20HC2g |Sender:=20; bh=KMs4BM8iatT9jH4VkQaGoy9LF29R42JaYCkdjHOJsts=; b=tBJXA4RTWPCUviaC4U+AjaiZ7BtuFEeE4vNup9fChVvDKYNcR9KDicC+1B LSHkxpx4SuzE5MvpEz+kv9iFgzyJGLL3gpEawcPLopM28aafot+jTJ94nVBu kDMZI7QYgt; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Jay Werb , 6lowpan <6lowpan@ietf.org>, enns@stanfordalumni.org Subject: Re: [6lowpan] HC1g and HC2g 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 > Rather than having the Next >Hop field be in potentially three different places, how about this idea: >Leave the L4C bit in HC1 as before, but rename it to NHC for next-header >compression (if NHC is 0, then the Next Header field is carried inline >and no HC2 header appears; if NHC is 1, then an HC2 header follows). >Then we define a HC2_UDP as follows: > > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |0|S|P|C| rsv | > +-+-+-+-+-+-+-+-+ > >The difference here is that we fix the first bit as '0' for UDP and >leave compression mechanisms for other Next Header values undefined for >now. As we define new NHC compression mechanisms, they can be added by >setting the first bit to '1' and some other bit-pattern following. It's >a huffman-style encoding, but we're just assuming that UDP is going to >be the most common case, so we give it the best case. > >I've also taken out the 'L' option, opting to say that UDP length should >always be elided and derived from lower layers, just as we've done with >the IP header. [Pascal] I love it. Note that it's too bad that UDP comes first in this encoding though it needs few bits... So the hop limit compression now resides in one of the 2 freed NH bits and the other one is reserved, right? Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 15:49:10 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C888928C9CB; Thu, 6 Mar 2008 15:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.113 X-Spam-Level: X-Spam-Status: No, score=-100.113 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 YdWT9TpNzTC0; Thu, 6 Mar 2008 15:49:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C217228C811; Thu, 6 Mar 2008 15:49:08 -0800 (PST) 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 3BD9A28C1DA for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 15:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 RO9P5eYy6dBQ for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 15:49:07 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id AFD7228C31F for <6lowpan@ietf.org>; Thu, 6 Mar 2008 15:49:03 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 741E7A92F1; Thu, 6 Mar 2008 15:48:53 -0800 (PST) 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 7IpOSqZ7FC5s; Thu, 6 Mar 2008 15:48:46 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 9F876A92F2; Thu, 6 Mar 2008 15:48:46 -0800 (PST) Message-ID: <47D082D8.9030307@archrock.com> Date: Thu, 06 Mar 2008 15:48:40 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC054D7EF2@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC054D7EF2@xmb-ams-337.emea.cisco.com> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 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 Pascal, I've asked for a time slot to talk about HCx and will incorporate stuff we've been discussing so far. We can bring up the discussion of further compressing the HC's there as well. -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi Jonathan: > > I'm can't wait to see the proposal that saves the 3 additional bytes as > we discussed turn into a WG doc, and that would be the priority. I'm > also concerned that the 3 bytes be elided when the addresses are link > local because that's the current use in ISA100, though I'm pretty sure > we could use HC1G there. > > I think that the work on compressing the HCs themselves is also > important because each byte in the headers is a percentage of > battery-life (or something). And that's mostly orthogonal work. They > intersect if: > > - we need to delay HC3 till HC1's are well defined > - We're missing dispatch bits. > > So I still wish to have the question discussed in Philly if that's > possible within constraints... > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: jeudi 6 mars 2008 17:29 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan >> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >> >> >> Hi Pascal, >> >> Given that it looks like we can include two of your three proposals > into >> HC1g, I'm not so sure whether defining a new format adds that much >> benefit. Adding the ability to elide the UDP checksum and the hop limit >> into HC1g already provides 3 bytes of savings. Compared to your > proposed >> modifications to HC1g, HC3 only saves one byte (which you've observed). >> I'll put this idea out now, but I believe HC1g has the potential to >> supersede HC1+HC2. Really, we should rename HC1g to be something like >> HCx since it's not really specific to routable addresses. >> >> My alternative proposal is as follows: >> - Use the HCx format for both link-local and non-link-local > communication. >> - Define a dispatch HCl when communicating with link-local addresses. >> - Define a dispatch HCr when communicating with routable addresses. >> >> The reason why I'm pushing for a single format is that I believe the >> most optimized code will work with the format directly to save RAM and >> code. That means that 6LoWPAN nodes generally do not expand compressed >> datagrams into uncompressed datagrams and the other way around. Thus, > it >> involves more than just the encoder/decoder functions and could involve >> the entire stack (including the application). >> >> What do you/others think? >> >> -- >> Jonathan Hui >> >> >> Pascal Thubert (pthubert) wrote: >>> Hi Jonathan and all: >>> >>> I'd wish to move forward on the original subject for this thread. >>> >>> Basically the question is whether it is worth consuming a dispatch > for >>> an HC3 that would represent the best case of what HC1 and HC2 can >>> compress. >>> >>> Pros: saves one byte in the headers and a fast path in the code >>> Cons: Additional encoding complexity and one dispatch. >>> >>> On the side, there's a compression mechanism coming up for ULA/GLO >>> (HC1g). >>> Can we make HC3 ready for that upcoming mechanism? Should we wait? >>> >>> I'll ask Geoff if some discussion can happen in Philly to conclude on >>> the topic. >>> >>> Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 15:52:23 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037053A6B3C; Thu, 6 Mar 2008 15:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.115 X-Spam-Level: X-Spam-Status: No, score=-100.115 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Aj3JrwSuWaLz; Thu, 6 Mar 2008 15:52:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309D93A6A58; Thu, 6 Mar 2008 15:52:22 -0800 (PST) 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 E52933A6A0B for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 15:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 UuMLpNR8Cg04 for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 15:52:20 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 4405E3A69A8 for <6lowpan@ietf.org>; Thu, 6 Mar 2008 15:52:20 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 00DABA92FB; Thu, 6 Mar 2008 15:52:10 -0800 (PST) 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 x6+AJv6zUtRX; Thu, 6 Mar 2008 15:52:03 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 40100A92FA; Thu, 6 Mar 2008 15:52:03 -0800 (PST) Message-ID: <47D0839F.8000609@archrock.com> Date: Thu, 06 Mar 2008 15:51:59 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC054D7EF7@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC054D7EF7@xmb-ams-337.emea.cisco.com> Cc: Jay Werb , 6lowpan <6lowpan@ietf.org>, enns@stanfordalumni.org Subject: Re: [6lowpan] HC1g and HC2g 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 Pascal, Pascal Thubert (pthubert) wrote: >> Rather than having the Next >> Hop field be in potentially three different places, how about this > idea: >> Leave the L4C bit in HC1 as before, but rename it to NHC for > next-header >> compression (if NHC is 0, then the Next Header field is carried inline >> and no HC2 header appears; if NHC is 1, then an HC2 header follows). >> Then we define a HC2_UDP as follows: >> >> 0 1 2 3 4 5 6 7 >> +-+-+-+-+-+-+-+-+ >> |0|S|P|C| rsv | >> +-+-+-+-+-+-+-+-+ >> >> The difference here is that we fix the first bit as '0' for UDP and >> leave compression mechanisms for other Next Header values undefined for >> now. As we define new NHC compression mechanisms, they can be added by >> setting the first bit to '1' and some other bit-pattern following. It's >> a huffman-style encoding, but we're just assuming that UDP is going to >> be the most common case, so we give it the best case. >> >> I've also taken out the 'L' option, opting to say that UDP length > should >> always be elided and derived from lower layers, just as we've done with >> the IP header. > > [Pascal] I love it. Note that it's too bad that UDP comes first in this > encoding though it needs few bits... So the hop limit compression now > resides in one of the 2 freed NH bits and the other one is reserved, > right? It is too bad that UDP needs only a few bits. But there are ways to utilize those extra bits :-). If you mean the hop limit compression resides in one of the freed HLIM bits, then that's correct. -- Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 6 21:52:58 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648BB3A6C4A; Thu, 6 Mar 2008 21:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.596 X-Spam-Level: X-Spam-Status: No, score=-100.596 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 mwkySd7i9s85; Thu, 6 Mar 2008 21:52:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7203A69A1; Thu, 6 Mar 2008 21:52:57 -0800 (PST) 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 F215F3A69A1 for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 21:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 ec9zmwH1Vof8 for <6lowpan@core3.amsl.com>; Thu, 6 Mar 2008 21:52:56 -0800 (PST) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 251143A67A2 for <6lowpan@ietf.org>; Thu, 6 Mar 2008 21:52:56 -0800 (PST) Received: from [199.233.92.21] (dev21.coslabs.com [199.233.92.21]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id m275qiSY017847 for <6lowpan@lists.ietf.org>; Thu, 6 Mar 2008 22:52:44 -0700 (MST) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Date: Thu, 06 Mar 2008 22:52:42 -0700 Message-Id: <1204869162.24625.17.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Subject: [6lowpan] agenda 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 The agenda for the 6lowpan wg meeting has been posted to ietf.org. Sorry for it being late. I actually posted earlier, but forgot to send out this message. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Mar 8 12:10:37 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D153A6BCB; Sat, 8 Mar 2008 12:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.758 X-Spam-Level: X-Spam-Status: No, score=-100.758 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 sOkU1bWLaqRj; Sat, 8 Mar 2008 12:10:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39F53A6B96; Sat, 8 Mar 2008 12:10:35 -0800 (PST) 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 95EFD3A6AEE; Sat, 8 Mar 2008 12:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 8BI+JmlkoV38; Sat, 8 Mar 2008 12:10:31 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 5EE993A6BF0; Sat, 8 Mar 2008 12:10:25 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m28K80f7026690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 8 Mar 2008 12:08:01 -0800 (PST) Message-ID: <47D2F21A.7080309@eecs.berkeley.edu> Date: Sat, 08 Mar 2008 12:07:54 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: 6lowpan@ietf.org, roll@ietf.org References: <200803021021.10955.coflynn@newae.com> <001e01c87fd4$7264c4a0$8300a8c0@priveiqvfluhp9> In-Reply-To: <001e01c87fd4$7264c4a0$8300a8c0@priveiqvfluhp9> Subject: Re: [6lowpan] Syncronized Wake 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 Pieter, Collin: the ISA100.11a MAC is based on TSMP (http://en.wikipedia.org/wiki/TSMP), although it's been made very general because of political requirements in getting the .11 group off the ground. So it's actually possible to configure it to be pure scheduled unicast channel-hopping TDMA, pure single-channel CSMA, or anything in between. One likely operating mode would look something like this (this is basically what Wireless HART does): * 10ms slot length. Single packet sent and acknowledged in a single slot. Most scheduled slots would be unicast for "upstream" data collection. Some scheduled slots would be broadcast for downstream communication. Some might be shared bandwidth (slotted aloha). Scheduled slots repeat in one or more superframes, similar to but far more flexible than the 15.4 GTS mechanism. * +/- 1ms guard time at the beginning of the slot to allow for synchronization errors. Depending on the temperature range and the quality of the time-keeping at each mote, this leads to a synchronization requirement of between 10 seconds and a minute. Motes keep track of their last synchronization (optionally on a path-by-path basis) and send a keepalive packet if their synch timer expires. Every acknowledged packet carries time information in both directions, so they reset the synchronization timer. For many/most motes in many/all networks there is no need for additional synchronization traffic above and beyond normal data traffic. For low traffic networks, beaconing may be used if it makes more sense energetically than keepalives. For 802.15.4 radios, the overhead for maintaining +/-1ms synchronization across the entire network is less than 0.01% radio duty cycle. Since all motes share a common sense of time, they can pseudo-randomly channel hop, dramatically reducing the chance of a link between two motes "going down" due to external or multi-path interference. * Communication cells (={slot, channel_offset} pair) may be assigned by some central manager, or via purely distributed algorithms, or some combination of both. Enforcing unicast with no collisions, 1,600 cells per second are available (100 slots/second * 16 channels). Cells are collected into graphs. Graphs provide QoS to applications, and can be turned on and off to dynamically vary power and performance over many orders of magnitude in response to application requests. This is where things get interesting with 6LoWPAN and RoLL. TSMP provides the mechanisms to bind layer 4 quality of service to layer 3 routes and layer 2 performance/power provisioning. This is critical in industrial automation, and seems likely to be very useful in other applications as well. I don't think that it violates anything that the IETF holds dear, but I've been wrong about that before :) ksjp Pieter De Mil wrote: > Hi Robert, > > I don't know if Colin is interested in more details, but I certainly am. > > How frequently do you have to exchange sync. messages? Every 10/60/.. > seconds? > How are your sync. messages scheduled? Via a distributed assignment? > > Do you use CSMA/CA in a time slot? > > Pieter > > ----- Original Message ----- > From: "Robert Assimiti" > To: "Colin O'Flynn" ; <6lowpan@ietf.org> > Sent: Thursday, March 06, 2008 10:17 PM > Subject: Re: [6lowpan] Syncronized Wake > > > Hello Colin, > > The currently undergoing ISA100.11a standardization effort would be the > perfect paradigm for what you are trying to accomplish. It is a standard > geared towards industrial process and automation, but it definitely has > applicability in commercial applications as well. > > Currently employing the 802.15.4 PHY/MAC (although alternate PHY/MACs are > being considered), the Field Devices (FFD/RFDs in 802.15.4 semantics) > communicate during strictly enforced "time slots" without using beacons. > This allows for prolonged battery life although frequent time > synchronization messages must be exchanged. > > Let me know if you are interested in more details. > > > > > > "The nice thing about standards is that there are so many to choose from." - > Andrew S. Tanenbaum > Robert Assimiti > Executive Staff Engineer > Office: [678]-202-6859 > Mobile: [404]-578-0205 > robert.assimiti@nivis.com > > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Colin O'Flynn > Sent: Sunday, March 02, 2008 9:21 AM > To: 6lowpan@ietf.org > Subject: [6lowpan] Syncronized Wake > > Hello All, > > First a quick question - I found this list on the IETF site. I assume it's a > public list, you don't have to be a member of the working group to submit? > > Anyway, a few of us are working on doing a 6lowpan implementation. I was > looking at doing a 'syncronized wake' to help save power yet get reasonable > response times. By my calculations you could wake every few seconds and > still > have an exceptional battery life (year+). > > Since some nodes might need to wake up more often than others they might > have > different schedules, and obviously you'd need some sort of beacon to > syncronize. The idea is each node has a "wake schedule" that nearby nodes > know, and will be listening at that time. But any node can TX at almost any > time. > > I don't want to do GTS though, as nodes can talk at any time. But I need a > way > to (a) sync nodes and (b) transmit wake schedule. > > So the question: would their be a standards-compliant way to do this? Or is > it > worth it trying to be standards compliant at this stage? It would be easy > enough to make some simple protocol up to do this for testing. > > Warm Regards, > > -Colin O'Flynn > > PS: If you are interested: hardware is 8-bit AVR devices, using uIP for IPv6 > implementation. The gateway router is AVR32 device, which can route over > ethernet. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > This e-mail (including any attachments to it) is confidential, proprietary, > legally privileged, subject to copyright and is sent for the personal > attention of the intended recipient only. If you have received this e-mail > in error, please reply to advise us immediately, delete it and destroy any > printed copies of it. You are notified that reading, disclosing, copying, > distributing or taking any action in reliance on the contents of this > information is strictly prohibited. No employee is authorized to conclude > any binding agreement on behalf of NIVIS LLC with another party by e-mail > without express written confirmation by an officer of the company. Although > we have taken reasonable precautions to ensure no viruses are present in > this e-mail, we cannot accept responsibility for any loss or damage arising > from the viruses in this e-mail or attachments. > _______________________________________________ > 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 Sun Mar 9 17:27:20 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263013A6D1C; Sun, 9 Mar 2008 17:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.253 X-Spam-Level: X-Spam-Status: No, score=-101.253 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 8560Zwp9PwCk; Sun, 9 Mar 2008 17:27:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB533A6CB0; Sun, 9 Mar 2008 17:27: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 6083D3A68CB for <6lowpan@core3.amsl.com>; Sun, 9 Mar 2008 17:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 LNDCTJAEDcJN for <6lowpan@core3.amsl.com>; Sun, 9 Mar 2008 17:27:15 -0700 (PDT) Received: from cedar.ugent.be (cedar.ugent.be [157.193.49.14]) by core3.amsl.com (Postfix) with ESMTP id 616063A6850 for <6lowpan@ietf.org>; Sun, 9 Mar 2008 17:27:13 -0700 (PDT) Received: from bonobo.ugent.be (HELO localhost) ([157.193.71.53]) by cedar.ugent.be with ESMTP; 10 Mar 2008 01:24:52 +0100 Received: from cedar.ugent.be ([157.193.49.14]) by localhost (bonobo.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 26685-05; Mon, 10 Mar 2008 01:24:52 +0100 (CET) Received: from mail4.intec.ugent.be ([157.193.214.4]) by cedar.ugent.be with ESMTP; 10 Mar 2008 01:24:52 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHwc1EedwdYE/2dsb2JhbACoTw Received: from localhost (localhost [127.0.0.1]) by mail4.intec.ugent.be (Postfix) with ESMTP id 09C7B40B2BB; Mon, 10 Mar 2008 01:24:43 +0100 (CET) Received: from mail4.intec.ugent.be ([127.0.0.1]) by localhost (mail4.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WyL52KHgTR1; Mon, 10 Mar 2008 01:24:42 +0100 (CET) Received: from webserver6.intec.ugent.be (webserver6.intec.ugent.be [157.193.214.11]) by mail4.intec.ugent.be (Postfix) with ESMTP id AAD3540B2BA; Mon, 10 Mar 2008 01:24:42 +0100 (CET) Received: from 76.160.222.32 (SquirrelMail authenticated user pdemil) by webserver6.intec.ugent.be with HTTP; Mon, 10 Mar 2008 01:24:51 +0100 (CET) Message-ID: <31227.76.160.222.32.1205108691.squirrel@webserver6.intec.ugent.be> Date: Mon, 10 Mar 2008 01:24:51 +0100 (CET) From: "Pieter De Mil" To: "Kris Pister" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal References: <200803021021.10955.coflynn@newae.com> <001e01c87fd4$7264c4a0$8300a8c0@priveiqvfluhp9> <47D2F21A.7080309@eecs.berkeley.edu> In-Reply-To: <47D2F21A.7080309@eecs.berkeley.edu> X-Virus-Scanned: by UGent DICT Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Syncronized Wake 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 Kris, All; Thanks for the info, the ISA100.11a MAC seems to be a very flexible MAC layer. Some questions inline. > Pieter, Collin: > the ISA100.11a MAC is based on TSMP (http://en.wikipedia.org/wiki/TSMP), although it's been made very general because of political requirements in getting the .11 group off the ground. So it's actually possible to configure it to be pure scheduled unicast channel-hopping TDMA, pure single-channel CSMA, or anything in between. > One likely operating mode would look something like this (this is basically what Wireless HART does): > * 10ms slot length. Single packet sent and acknowledged in a single slot. Most scheduled slots would be unicast for "upstream" data collection. Some scheduled slots would be broadcast for downstream communication. Some might be shared bandwidth (slotted aloha). > Scheduled slots repeat in one or more superframes, similar to but far more flexible than the 15.4 GTS mechanism. Do you mean that the same scheduled slot "No 1" (assuming 1000 slots in 1 superframe) can be configured as "upstream" at time0 and as "broasdcast for downstream" at time0+10s? > * +/- 1ms guard time at the beginning of the slot to allow for > synchronization errors. Depending on the temperature range and the quality of the time-keeping at each mote, this leads to a > synchronization requirement of between 10 seconds and a minute. Motes keep track of their last synchronization (optionally on a path-by-path basis) and send a keepalive packet if their synch timer expires. Every acknowledged packet carries time information in both directions, so they reset the synchronization timer. Can you disable this extra time information for some ack packets? > For many/most motes in many/all > networks there is no need for additional synchronization traffic above and beyond normal data traffic. For low traffic networks, beaconing may be used if it makes more sense energetically than keepalives. Can you have a beacon-enabled ISA100.11a MAC? I've read you can assign the communication cells centrally/distributed/hybrid. Is this scheduling algorithm defined for beacons in low traffic networks? Or is this out of scope of the standard spec? > For > 802.15.4 radios, the overhead for maintaining +/-1ms synchronization across the entire network is less than 0.01% radio duty cycle. > Since all motes share a common sense of time, they can pseudo-randomly channel hop, dramatically reducing the chance of a link between two motes "going down" due to external or multi-path interference. Great! > * Communication cells (={slot, channel_offset} pair) may be assigned by some central manager, or via purely distributed algorithms, or some combination of both. Enforcing unicast with no collisions, 1,600 cells per second are available (100 slots/second * 16 channels). > > Cells are collected into graphs. Graphs provide QoS to applications, and can be turned on and off to dynamically vary power and performance over many orders of magnitude in response to application requests. This is where things get interesting with 6LoWPAN and RoLL. TSMP provides the mechanisms to bind layer 4 quality of service to layer 3 routes and layer 2 performance/power provisioning. This is critical in industrial automation, and seems likely to be very useful in other applications as well. I don't think that it violates anything that the IETF holds dear, but I've been wrong about that before :) :-) The need for an abstraction layer is clear, because some MAC layers do not offer slots or synchronization. The routing layer has to know this. One option is defining a profile or information base that every MAC layer (implementer) has to fill in. This profile must describe the MAC capabilities (available channels, transmit power, synchronized, slotted, slotlength,...). Someone has already started? Pieter > > ksjp > > Pieter De Mil wrote: >> Hi Robert, >> I don't know if Colin is interested in more details, but I certainly am. >> How frequently do you have to exchange sync. messages? Every 10/60/.. seconds? >> How are your sync. messages scheduled? Via a distributed assignment? Do you use CSMA/CA in a time slot? >> Pieter >> ----- Original Message ----- >> From: "Robert Assimiti" >> To: "Colin O'Flynn" ; <6lowpan@ietf.org> >> Sent: Thursday, March 06, 2008 10:17 PM >> Subject: Re: [6lowpan] Syncronized Wake >> Hello Colin, >> The currently undergoing ISA100.11a standardization effort would be the perfect paradigm for what you are trying to accomplish. It is a standard >> geared towards industrial process and automation, but it definitely has applicability in commercial applications as well. >> Currently employing the 802.15.4 PHY/MAC (although alternate PHY/MACs are >> being considered), the Field Devices (FFD/RFDs in 802.15.4 semantics) communicate during strictly enforced "time slots" without using beacons. >> This allows for prolonged battery life although frequent time >> synchronization messages must be exchanged. >> Let me know if you are interested in more details. >> "The nice thing about standards is that there are so many to choose from." - >> Andrew S. Tanenbaum >> Robert Assimiti >> Executive Staff Engineer >> Office: [678]-202-6859 >> Mobile: [404]-578-0205 >> robert.assimiti@nivis.com >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf >> Of Colin O'Flynn >> Sent: Sunday, March 02, 2008 9:21 AM >> To: 6lowpan@ietf.org >> Subject: [6lowpan] Syncronized Wake >> Hello All, >> First a quick question - I found this list on the IETF site. I assume it's a >> public list, you don't have to be a member of the working group to submit? >> Anyway, a few of us are working on doing a 6lowpan implementation. I was >> looking at doing a 'syncronized wake' to help save power yet get reasonable >> response times. By my calculations you could wake every few seconds and still >> have an exceptional battery life (year+). >> Since some nodes might need to wake up more often than others they might >> have >> different schedules, and obviously you'd need some sort of beacon to syncronize. The idea is each node has a "wake schedule" that nearby nodes >> know, and will be listening at that time. But any node can TX at almost any >> time. >> I don't want to do GTS though, as nodes can talk at any time. But I need >> a >> way >> to (a) sync nodes and (b) transmit wake schedule. >> So the question: would their be a standards-compliant way to do this? Or >> is >> it >> worth it trying to be standards compliant at this stage? It would be easy >> enough to make some simple protocol up to do this for testing. >> Warm Regards, >> -Colin O'Flynn >> PS: If you are interested: hardware is 8-bit AVR devices, using uIP for IPv6 >> implementation. The gateway router is AVR32 device, which can route over >> ethernet. >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> This e-mail (including any attachments to it) is confidential, >> proprietary, >> legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail >> in error, please reply to advise us immediately, delete it and destroy any >> printed copies of it. You are notified that reading, disclosing, copying, >> distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude >> any binding agreement on behalf of NIVIS LLC with another party by e-mail >> without express written confirmation by an officer of the company. Although >> we have taken reasonable precautions to ensure no viruses are present in >> this e-mail, we cannot accept responsibility for any loss or damage arising >> from the viruses in this e-mail or attachments. >> _______________________________________________ >> 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 Mar 10 08:01:53 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BDBE3A6E9C; Mon, 10 Mar 2008 08:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.615 X-Spam-Level: X-Spam-Status: No, score=-98.615 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 R39sdfAATVyu; Mon, 10 Mar 2008 08:01:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF4128D5A2; Mon, 10 Mar 2008 07:30: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 0C4B928C4EF for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 07:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 dCIpAN4cYf-u for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 07:30:50 -0700 (PDT) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by core3.amsl.com (Postfix) with ESMTP id 333CD3A6CC0 for <6lowpan@ietf.org>; Sun, 9 Mar 2008 21:31:07 -0700 (PDT) Received: by rv-out-0910.google.com with SMTP id l15so915352rvb.49 for <6lowpan@ietf.org>; Sun, 09 Mar 2008 21:28:47 -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:in-reply-to:mime-version:content-type:references; bh=qnhtTOn1H/cEjT0A9e2nowWvqXyEgq2eEfkPUZzbmmQ=; b=gczYV41wmilxdEjzhhhw05uvUF5Wn9kQiKvkLf/d7uDaivT+rMjx+LewsxUFgm/+LSqUSxKGbWh2v4MC51NgEQi7rwqe5tGaP1uKVj9j6kfS8VVsZmGk/Bky9cvC153YSCLcOudQQ1I0Qf6Yj8ZVlKCG4w7HdEgCSqbn4lmWqHc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=hZ5F5DwOPQjL/qjZmLEDYlZV9hID7ixz06/CThWE1s1PkbAQTAr4sEMu5H3BE9KmD8Qa7i865bnrO9RHzT8ZDeBbMEzFyKPMI9LhZy3jlY9k3yndKZBIeD3+7g1LOsne1uP9RslIW0DXSDQTlogleC+wqcOP4e1OJrazREJLHbo= Received: by 10.141.162.16 with SMTP id p16mr2715370rvo.243.1205123327107; Sun, 09 Mar 2008 21:28:47 -0700 (PDT) Received: by 10.141.40.6 with HTTP; Sun, 9 Mar 2008 21:28:47 -0700 (PDT) Message-ID: <7b2b19400803092128r6d001b91w84cd56621fda2362@mail.gmail.com> Date: Mon, 10 Mar 2008 13:28:47 +0900 From: "Dhananjay Singh" To: 6lowpan@ietf.org In-Reply-To: MIME-Version: 1.0 References: Subject: Re: [6lowpan] 6lowpan Digest, Vol 38, Issue 15 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="===============0747839435==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============0747839435== Content-Type: multipart/alternative; boundary="----=_Part_37699_17707717.1205123327100" ------=_Part_37699_17707717.1205123327100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Friends, I am Dhananjay Singh from I*ndia but now a days* i am doing my research work at in Ubiquitous Sensor Laboratory, Dongseo University Busan Korea Friends, i am working on ip-based Wirelesss Sensor Networks so i have to need 6lowpan stack for telosb mode on tinyos2.02 OS firstly i want to test communication between two teloseb modes.if anybody have stack code on 6lowpan then let me know....... thanks in advance! with best regard's Dan On 3/8/08, 6lowpan-request@ietf.org <6lowpan-request@ietf.org> wrote: > > Send 6lowpan mailing list submissions to > 6lowpan@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/6lowpan > or, via email, send a message with subject or body 'help' to > 6lowpan-request@ietf.org > > You can reach the person managing the list at > 6lowpan-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 6lowpan digest..." > > > Today's Topics: > > 1. Re: Compressing HC1 and HC2 into HC3 (Jonathan Hui) > 2. Re: HC1g and HC2g (Jonathan Hui) > 3. agenda (Geoff Mulligan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 06 Mar 2008 15:48:40 -0800 > From: Jonathan Hui > Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 > To: "Pascal Thubert (pthubert)" > Cc: 6lowpan <6lowpan@ietf.org> > Message-ID: <47D082D8.9030307@archrock.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Hi Pascal, > > I've asked for a time slot to talk about HCx and will incorporate stuff > we've been discussing so far. We can bring up the discussion of further > compressing the HC's there as well. > > -- > Jonathan Hui > > > Pascal Thubert (pthubert) wrote: > > Hi Jonathan: > > > > I'm can't wait to see the proposal that saves the 3 additional bytes as > > we discussed turn into a WG doc, and that would be the priority. I'm > > also concerned that the 3 bytes be elided when the addresses are link > > local because that's the current use in ISA100, though I'm pretty sure > > we could use HC1G there. > > > > I think that the work on compressing the HCs themselves is also > > important because each byte in the headers is a percentage of > > battery-life (or something). And that's mostly orthogonal work. They > > intersect if: > > > > - we need to delay HC3 till HC1's are well defined > > - We're missing dispatch bits. > > > > So I still wish to have the question discussed in Philly if that's > > possible within constraints... > > > > Pascal > > > >> -----Original Message----- > >> From: Jonathan Hui [mailto:jhui@archrock.com] > >> Sent: jeudi 6 mars 2008 17:29 > >> To: Pascal Thubert (pthubert) > >> Cc: 6lowpan > >> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 > >> > >> > >> Hi Pascal, > >> > >> Given that it looks like we can include two of your three proposals > > into > >> HC1g, I'm not so sure whether defining a new format adds that much > >> benefit. Adding the ability to elide the UDP checksum and the hop limit > >> into HC1g already provides 3 bytes of savings. Compared to your > > proposed > >> modifications to HC1g, HC3 only saves one byte (which you've observed). > >> I'll put this idea out now, but I believe HC1g has the potential to > >> supersede HC1+HC2. Really, we should rename HC1g to be something like > >> HCx since it's not really specific to routable addresses. > >> > >> My alternative proposal is as follows: > >> - Use the HCx format for both link-local and non-link-local > > communication. > >> - Define a dispatch HCl when communicating with link-local addresses. > >> - Define a dispatch HCr when communicating with routable addresses. > >> > >> The reason why I'm pushing for a single format is that I believe the > >> most optimized code will work with the format directly to save RAM and > >> code. That means that 6LoWPAN nodes generally do not expand compressed > >> datagrams into uncompressed datagrams and the other way around. Thus, > > it > >> involves more than just the encoder/decoder functions and could involve > >> the entire stack (including the application). > >> > >> What do you/others think? > >> > >> -- > >> Jonathan Hui > >> > >> > >> Pascal Thubert (pthubert) wrote: > >>> Hi Jonathan and all: > >>> > >>> I'd wish to move forward on the original subject for this thread. > >>> > >>> Basically the question is whether it is worth consuming a dispatch > > for > >>> an HC3 that would represent the best case of what HC1 and HC2 can > >>> compress. > >>> > >>> Pros: saves one byte in the headers and a fast path in the code > >>> Cons: Additional encoding complexity and one dispatch. > >>> > >>> On the side, there's a compression mechanism coming up for ULA/GLO > >>> (HC1g). > >>> Can we make HC3 ready for that upcoming mechanism? Should we wait? > >>> > >>> I'll ask Geoff if some discussion can happen in Philly to conclude on > >>> the topic. > >>> > >>> Pascal > > > ------------------------------ > > Message: 2 > Date: Thu, 06 Mar 2008 15:51:59 -0800 > From: Jonathan Hui > Subject: Re: [6lowpan] HC1g and HC2g > To: "Pascal Thubert (pthubert)" > Cc: Jay Werb , 6lowpan <6lowpan@ietf.org>, > enns@stanfordalumni.org > Message-ID: <47D0839F.8000609@archrock.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Hi Pascal, > > Pascal Thubert (pthubert) wrote: > >> Rather than having the Next > >> Hop field be in potentially three different places, how about this > > idea: > >> Leave the L4C bit in HC1 as before, but rename it to NHC for > > next-header > >> compression (if NHC is 0, then the Next Header field is carried inline > >> and no HC2 header appears; if NHC is 1, then an HC2 header follows). > >> Then we define a HC2_UDP as follows: > >> > >> 0 1 2 3 4 5 6 7 > >> +-+-+-+-+-+-+-+-+ > >> |0|S|P|C| rsv | > >> +-+-+-+-+-+-+-+-+ > >> > >> The difference here is that we fix the first bit as '0' for UDP and > >> leave compression mechanisms for other Next Header values undefined for > >> now. As we define new NHC compression mechanisms, they can be added by > >> setting the first bit to '1' and some other bit-pattern following. It's > >> a huffman-style encoding, but we're just assuming that UDP is going to > >> be the most common case, so we give it the best case. > >> > >> I've also taken out the 'L' option, opting to say that UDP length > > should > >> always be elided and derived from lower layers, just as we've done with > >> the IP header. > > > > [Pascal] I love it. Note that it's too bad that UDP comes first in this > > encoding though it needs few bits... So the hop limit compression now > > resides in one of the 2 freed NH bits and the other one is reserved, > > right? > > It is too bad that UDP needs only a few bits. But there are ways to > utilize those extra bits :-). If you mean the hop limit compression > resides in one of the freed HLIM bits, then that's correct. > > -- > Jonathan Hui > > > ------------------------------ > > Message: 3 > Date: Thu, 06 Mar 2008 22:52:42 -0700 > From: Geoff Mulligan > Subject: [6lowpan] agenda > To: 6lowpan <6lowpan@ietf.org> > Message-ID: <1204869162.24625.17.camel@dellx1> > Content-Type: text/plain > > The agenda for the 6lowpan wg meeting has been posted to ietf.org. > > Sorry for it being late. I actually posted earlier, but forgot to send > out this message. > > geoff > > > > > ------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > End of 6lowpan Digest, Vol 38, Issue 15 > *************************************** > ------=_Part_37699_17707717.1205123327100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Friends,
I am Dhananjay Singh from India but now a days i am doing my research work at in Ubiquitous Sensor Laboratory, Dongseo University Busan Korea
Friends, i am working on ip-based Wirelesss Sensor Networks so i have to need 6lowpan stack for telosb mode on tinyos2.02 OS
firstly i want to test  communication between two teloseb modes.if anybody have stack code on 6lowpan then let me know.......
thanks in advance!
with best regard's
Dan


On 3/8/08, 6lowpan-request@ietf.org <6lowpan-request@ietf.org> wrote:
Send 6lowpan mailing list submissions to
        6lowpan@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/6lowpan
or, via email, send a message with subject or body 'help' to
        6lowpan-request@ietf.org

You can reach the person managing the list at
        6lowpan-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of 6lowpan digest..."


Today's Topics:

   1. Re: Compressing HC1 and HC2 into HC3 (Jonathan Hui)
   2. Re: HC1g and HC2g (Jonathan Hui)
   3. agenda (Geoff Mulligan)


----------------------------------------------------------------------

Message: 1
Date: Thu, 06 Mar 2008 15:48:40 -0800
From: Jonathan Hui <jhui@archrock.com>
Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: 6lowpan <6lowpan@ietf.org>
Message-ID: <47D082D8.9030307@archrock.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


Hi Pascal,

I've asked for a time slot to talk about HCx and will incorporate stuff
we've been discussing so far. We can bring up the discussion of further
compressing the HC's there as well.

--
Jonathan Hui


Pascal Thubert (pthubert) wrote:
> Hi Jonathan:
>
> I'm can't wait to see the proposal that saves the 3 additional bytes as
> we discussed turn into a WG doc, and that would be the priority. I'm
> also concerned that the 3 bytes be elided when the addresses are link
> local because that's the current use in ISA100, though I'm pretty sure
> we could use HC1G there.
>
> I think that the work on compressing the HCs themselves is also
> important because each byte in the headers is a percentage of
> battery-life (or something). And that's mostly orthogonal work. They
> intersect if:
>
> - we need to delay HC3 till HC1's are well defined
> - We're missing dispatch bits.
>
> So I still wish to have the question discussed in Philly if that's
> possible within constraints...
>
> Pascal
>
>> -----Original Message-----
>> From: Jonathan Hui [mailto:jhui@archrock.com]
>> Sent: jeudi 6 mars 2008 17:29
>> To: Pascal Thubert (pthubert)
>> Cc: 6lowpan
>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3
>>
>>
>> Hi Pascal,
>>
>> Given that it looks like we can include two of your three proposals
> into
>> HC1g, I'm not so sure whether defining a new format adds that much
>> benefit. Adding the ability to elide the UDP checksum and the hop limit
>> into HC1g already provides 3 bytes of savings. Compared to your
> proposed
>> modifications to HC1g, HC3 only saves one byte (which you've observed).
>> I'll put this idea out now, but I believe HC1g has the potential to
>> supersede HC1+HC2. Really, we should rename HC1g to be something like
>> HCx since it's not really specific to routable addresses.
>>
>> My alternative proposal is as follows:
>> - Use the HCx format for both link-local and non-link-local
> communication.
>> - Define a dispatch HCl when communicating with link-local addresses.
>> - Define a dispatch HCr when communicating with routable addresses.
>>
>> The reason why I'm pushing for a single format is that I believe the
>> most optimized code will work with the format directly to save RAM and
>> code. That means that 6LoWPAN nodes generally do not expand compressed
>> datagrams into uncompressed datagrams and the other way around. Thus,
> it
>> involves more than just the encoder/decoder functions and could involve
>> the entire stack (including the application).
>>
>> What do you/others think?
>>
>> --
>> Jonathan Hui
>>
>>
>> Pascal Thubert (pthubert) wrote:
>>> Hi Jonathan and all:
>>>
>>> I'd wish to move forward on the original subject for this thread.
>>>
>>> Basically the question is whether it is worth consuming a dispatch
> for
>>> an HC3 that would represent the best case of what HC1 and HC2 can
>>> compress.
>>>
>>> Pros: saves one byte in the headers and a fast path in the code
>>> Cons: Additional encoding complexity and one dispatch.
>>>
>>> On the side, there's a compression mechanism coming up for ULA/GLO
>>> (HC1g).
>>> Can we make HC3 ready for that upcoming mechanism? Should we wait?
>>>
>>> I'll ask Geoff if some discussion can happen in Philly to conclude on
>>> the topic.
>>>
>>> Pascal


------------------------------

Message: 2
Date: Thu, 06 Mar 2008 15:51:59 -0800
From: Jonathan Hui <jhui@archrock.com>
Subject: Re: [6lowpan] HC1g and HC2g
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Jay Werb <jwerb07@sensicast.com>, 6lowpan <6lowpan@ietf.org>,
        enns@stanfordalumni.org
Message-ID: <47D0839F.8000609@archrock.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


Hi Pascal,

Pascal Thubert (pthubert) wrote:
>>                                            Rather than having the Next
>> Hop field be in potentially three different places, how about this
> idea:
>> Leave the L4C bit in HC1 as before, but rename it to NHC for
> next-header
>> compression (if NHC is 0, then the Next Header field is carried inline
>> and no HC2 header appears; if NHC is 1, then an HC2 header follows).
>> Then we define a HC2_UDP as follows:
>>
>>    0 1 2 3 4 5 6 7
>>   +-+-+-+-+-+-+-+-+
>>   |0|S|P|C|  rsv  |
>>   +-+-+-+-+-+-+-+-+
>>
>> The difference here is that we fix the first bit as '0' for UDP and
>> leave compression mechanisms for other Next Header values undefined for
>> now. As we define new NHC compression mechanisms, they can be added by
>> setting the first bit to '1' and some other bit-pattern following. It's
>> a huffman-style encoding, but we're just assuming that UDP is going to
>> be the most common case, so we give it the best case.
>>
>> I've also taken out the 'L' option, opting to say that UDP length
> should
>> always be elided and derived from lower layers, just as we've done with
>> the IP header.
>
> [Pascal] I love it. Note that it's too bad that UDP comes first in this
> encoding though it needs few bits... So the hop limit compression now
> resides in one of the 2 freed NH bits and the other one is reserved,
> right?

It is too bad that UDP needs only a few bits. But there are ways to
utilize those extra bits :-). If you mean the hop limit compression
resides in one of the freed HLIM bits, then that's correct.

--
Jonathan Hui


------------------------------

Message: 3
Date: Thu, 06 Mar 2008 22:52:42 -0700
From: Geoff Mulligan <geoff@mulligan.com>
Subject: [6lowpan] agenda
To: 6lowpan <6lowpan@ietf.org>
Message-ID: <1204869162.24625.17.camel@dellx1>
Content-Type: text/plain

The agenda for the 6lowpan wg meeting has been posted to ietf.org.

Sorry for it being late.  I actually posted earlier, but forgot to send
out this message.

        geoff




------------------------------

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


End of 6lowpan Digest, Vol 38, Issue 15
***************************************

------=_Part_37699_17707717.1205123327100-- --===============0747839435== 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 --===============0747839435==-- From 6lowpan-bounces@ietf.org Mon Mar 10 08:17:45 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605BD28D470; Mon, 10 Mar 2008 08:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.218 X-Spam-Level: X-Spam-Status: No, score=-102.218 tagged_above=-999 required=5 tests=[AWL=-1.781, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 zvg+Nwn5w6AP; Mon, 10 Mar 2008 08:17:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DE428C836; Mon, 10 Mar 2008 07:57:38 -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 CB2C428C8B4 for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 07:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 auJljaonto1m for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 07:57:30 -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 B2B2B28E1BB for <6lowpan@ietf.org>; Mon, 10 Mar 2008 02:35:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,473,1199660400"; d="scan'208";a="2970363" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Mar 2008 10:33:08 +0100 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 m2A9X6tH007422; Mon, 10 Mar 2008 10:33:06 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m2A9WwHO010974; Mon, 10 Mar 2008 09:33:06 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, 10 Mar 2008 10:33:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 10:32:35 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC054D84F4@xmb-ams-337.emea.cisco.com> In-Reply-To: <31227.76.160.222.32.1205108691.squirrel@webserver6.intec.ugent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Syncronized Wake thread-index: AciCRTWqlZMJmjWyTd+iA+XLwFrFhAAR7fPw From: "Pascal Thubert (pthubert)" To: "Pieter De Mil" , "Kris Pister" X-OriginalArrivalTime: 10 Mar 2008 09:33:02.0849 (UTC) FILETIME=[BCBDE710:01C88291] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9372; t=1205141586; x=1206005586; 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]=20Syncronized=20Wake |Sender:=20; bh=PVDz1ipKayjStA4Enz1hffkGAlFGtGgmkwptto9z/RE=; b=TPvk61Sy2kWxo41Sot5V3RQVwGt+j7wnjPuxDPj7I7HiqX2meSUbwLWyVq NO6Jp1mHHnU+kxkxyZ40Ln0JHE90ZbtgA9jAdkHdvT1CJYQgZiCXInBZgfeS Q8SfSKD0Ti; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Syncronized Wake 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 Pieter: Actually the novelty happens in the Data Link Layer (DLL), and it is, indeed, extremely flexible by design. To the point that some additional documentation can be very welcome to use the DLL implement specific requirements... Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Pieter De Mil >Sent: lundi 10 mars 2008 01:25 >To: Kris Pister >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] Syncronized Wake > > Hi Kris, All; > >Thanks for the info, the ISA100.11a MAC seems to be a very flexible MAC >layer. >Some questions inline. > >> Pieter, Collin: >> the ISA100.11a MAC is based on TSMP (http://en.wikipedia.org/wiki/TSMP), >although it's been made very general because of political requirements in >getting the .11 group off the ground. So it's actually possible to >configure it to be pure scheduled unicast channel-hopping TDMA, pure >single-channel CSMA, or anything in between. >> One likely operating mode would look something like this (this is >basically what Wireless HART does): >> * 10ms slot length. Single packet sent and acknowledged in a single >slot. Most scheduled slots would be unicast for "upstream" data >collection. Some scheduled slots would be broadcast for downstream >communication. Some might be shared bandwidth (slotted aloha). >> Scheduled slots repeat in one or more superframes, similar to but far >more flexible than the 15.4 GTS mechanism. > > >Do you mean that the same scheduled slot "No 1" (assuming 1000 slots in 1 >superframe) can be configured as "upstream" at time0 and as "broasdcast >for downstream" at time0+10s? > > > >> * +/- 1ms guard time at the beginning of the slot to allow for >> synchronization errors. Depending on the temperature range and the >quality of the time-keeping at each mote, this leads to a >> synchronization requirement of between 10 seconds and a minute. Motes >keep track of their last synchronization (optionally on a path-by-path >basis) and send a keepalive packet if their synch timer expires. Every >acknowledged packet carries time information in both directions, so they >reset the synchronization timer. > > >Can you disable this extra time information for some ack packets? > > > >> For many/most motes in many/all >> networks there is no need for additional synchronization traffic above >and beyond normal data traffic. For low traffic networks, beaconing may >be used if it makes more sense energetically than keepalives. > > >Can you have a beacon-enabled ISA100.11a MAC? >I've read you can assign the communication cells >centrally/distributed/hybrid. Is this scheduling algorithm defined for >beacons in low traffic networks? Or is this out of scope of the standard >spec? > > > >> For >> 802.15.4 radios, the overhead for maintaining +/-1ms synchronization >across the entire network is less than 0.01% radio duty cycle. >> Since all motes share a common sense of time, they can pseudo-randomly >channel hop, dramatically reducing the chance of a link between two motes >"going down" due to external or multi-path interference. > > >Great! > > > >> * Communication cells (={slot, channel_offset} pair) may be assigned by >some central manager, or via purely distributed algorithms, or some >combination of both. Enforcing unicast with no collisions, 1,600 cells >per second are available (100 slots/second * 16 channels). >> >> Cells are collected into graphs. Graphs provide QoS to applications, >and can be turned on and off to dynamically vary power and performance >over many orders of magnitude in response to application requests. This >is where things get interesting with 6LoWPAN and RoLL. TSMP provides the >mechanisms to bind layer 4 quality of service to layer 3 routes and layer >2 performance/power provisioning. This is critical in industrial >automation, and seems likely to be very useful in other applications as >well. I don't think that it violates anything that the IETF holds dear, >but I've been wrong about that before :) > > >:-) The need for an abstraction layer is clear, because some MAC layers do >not offer slots or synchronization. The routing layer has to know this. > >One option is defining a profile or information base that every MAC layer >(implementer) has to fill in. This profile must describe the MAC >capabilities (available channels, transmit power, synchronized, slotted, >slotlength,...). > >Someone has already started? > >Pieter > >> >> ksjp >> >> Pieter De Mil wrote: >>> Hi Robert, >>> I don't know if Colin is interested in more details, but I certainly >am. >>> How frequently do you have to exchange sync. messages? Every 10/60/.. >seconds? >>> How are your sync. messages scheduled? Via a distributed assignment? Do >you use CSMA/CA in a time slot? >>> Pieter >>> ----- Original Message ----- >>> From: "Robert Assimiti" >>> To: "Colin O'Flynn" ; <6lowpan@ietf.org> >>> Sent: Thursday, March 06, 2008 10:17 PM >>> Subject: Re: [6lowpan] Syncronized Wake >>> Hello Colin, >>> The currently undergoing ISA100.11a standardization effort would be the >perfect paradigm for what you are trying to accomplish. It is a >standard >>> geared towards industrial process and automation, but it definitely has >applicability in commercial applications as well. >>> Currently employing the 802.15.4 PHY/MAC (although alternate PHY/MACs >are >>> being considered), the Field Devices (FFD/RFDs in 802.15.4 semantics) >communicate during strictly enforced "time slots" without using >beacons. >>> This allows for prolonged battery life although frequent time >>> synchronization messages must be exchanged. >>> Let me know if you are interested in more details. >>> "The nice thing about standards is that there are so many to choose >from." - >>> Andrew S. Tanenbaum >>> Robert Assimiti >>> Executive Staff Engineer >>> Office: [678]-202-6859 >>> Mobile: [404]-578-0205 >>> robert.assimiti@nivis.com >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >Behalf >>> Of Colin O'Flynn >>> Sent: Sunday, March 02, 2008 9:21 AM >>> To: 6lowpan@ietf.org >>> Subject: [6lowpan] Syncronized Wake >>> Hello All, >>> First a quick question - I found this list on the IETF site. I assume >it's a >>> public list, you don't have to be a member of the working group to >submit? >>> Anyway, a few of us are working on doing a 6lowpan implementation. I >was >>> looking at doing a 'syncronized wake' to help save power yet get >reasonable >>> response times. By my calculations you could wake every few seconds and >still >>> have an exceptional battery life (year+). >>> Since some nodes might need to wake up more often than others they >might >>> have >>> different schedules, and obviously you'd need some sort of beacon to >syncronize. The idea is each node has a "wake schedule" that nearby nodes >>> know, and will be listening at that time. But any node can TX at almost >any >>> time. >>> I don't want to do GTS though, as nodes can talk at any time. But I >need >>> a >>> way >>> to (a) sync nodes and (b) transmit wake schedule. >>> So the question: would their be a standards-compliant way to do this? >Or >>> is >>> it >>> worth it trying to be standards compliant at this stage? It would be >easy >>> enough to make some simple protocol up to do this for testing. >>> Warm Regards, >>> -Colin O'Flynn >>> PS: If you are interested: hardware is 8-bit AVR devices, using uIP for >IPv6 >>> implementation. The gateway router is AVR32 device, which can route >over >>> ethernet. >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> This e-mail (including any attachments to it) is confidential, >>> proprietary, >>> legally privileged, subject to copyright and is sent for the personal >attention of the intended recipient only. If you have received this e-mail >>> in error, please reply to advise us immediately, delete it and destroy >any >>> printed copies of it. You are notified that reading, disclosing, >copying, >>> distributing or taking any action in reliance on the contents of this >information is strictly prohibited. No employee is authorized to >conclude >>> any binding agreement on behalf of NIVIS LLC with another party by >e-mail >>> without express written confirmation by an officer of the company. >Although >>> we have taken reasonable precautions to ensure no viruses are present >in >>> this e-mail, we cannot accept responsibility for any loss or damage >arising >>> from the viruses in this e-mail or attachments. >>> _______________________________________________ >>> 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 Mon Mar 10 09:40:24 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C532228C48B; Mon, 10 Mar 2008 09:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.327 X-Spam-Level: X-Spam-Status: No, score=-100.327 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 WF9qTyo3arc1; Mon, 10 Mar 2008 09:40:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1335628C29C; Mon, 10 Mar 2008 09:24:12 -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 761B328C29C for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 09:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ik-HhP-OTIsm for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 09:24:08 -0700 (PDT) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by core3.amsl.com (Postfix) with ESMTP id 1466628CE06 for <6lowpan@ietf.org>; Mon, 10 Mar 2008 09:11:04 -0700 (PDT) Received: by rv-out-0910.google.com with SMTP id l15so1055186rvb.49 for <6lowpan@ietf.org>; Mon, 10 Mar 2008 09:08:43 -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:mime-version:content-type; bh=PnHmpLsCz1c/HFkxMmUuqaYV1011KqZeYYwGcfSekpc=; b=K6tGPzm973D8AEvhBFk3rk9FB2/Gv/x09TakyeLSbOtbbf9MqOyyiDGgXMnU9BI52Sq0ldqNxwh/Xpy0Ul08jRLZaDsvZvMsEpReOfZlim5lcKes6IXtZYTqTMTh/C39fRg2ioGm/uO7AL6kR8aMMf4D7/zc7NBpDLOz1jASZsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=AOjrCJsmeHAGYgl+IOoCJlv947KreAuT5szwEY0MXTW2EbjBf3daewGwudBY8zOw8R8ZWTKxv+jesPP7a/25jEVLNvFzXolHcweCPg0bSZxBjYlys9NemOAmr3fhdbOh1GPzwWWOSZyvxKXLltN/ml8glEQQB0Ihnm0IP0EAKu0= Received: by 10.141.180.5 with SMTP id h5mr3209795rvp.240.1205165323667; Mon, 10 Mar 2008 09:08:43 -0700 (PDT) Received: by 10.140.174.14 with HTTP; Mon, 10 Mar 2008 09:08:43 -0700 (PDT) Message-ID: Date: Tue, 11 Mar 2008 01:08:43 +0900 From: "Ki-Hyung Kim" To: 6lowpan@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_45114_20932409.1205165323658" Cc: Carsten Subject: [6lowpan] commissioning in 6lowpan draft updated 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org ------=_Part_45114_20932409.1205165323658 Content-Type: multipart/alternative; boundary="----=_Part_45115_31299192.1205165323658" ------=_Part_45115_31299192.1205165323658 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, All, We have submitted an updated version of 6lowpan commissioning draft to IETF. While it is being published, please refer to the following link and the attached draft in this mail. http://www.ietf.org/proceedings/staging/draft-daniel-6lowpan-commissioning-01.txt Please read the draft and provide comments in the mailing list. Thanks, -- Ki-Hyung Kim. ------=_Part_45115_31299192.1205165323658 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello, All,

We have submitted an updated version of 6lowpan commissioning draft to IETF.
While it is being published, please refer to the following link and the attached draft in this mail.
http://www.ietf.org/proceedings/staging/draft-daniel-6lowpan-commissioning-01.txt

Please read the draft and provide comments in the mailing list.
 
Thanks,
--
Ki-Hyung Kim.
------=_Part_45115_31299192.1205165323658-- ------=_Part_45114_20932409.1205165323658 Content-Type: text/plain; name=draft-daniel-6lowpan-commissioning-01.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_fdn89bce Content-Disposition: attachment; filename=draft-daniel-6lowpan-commissioning-01.txt CgpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSy4gS2ltLCBFZC4KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQy4gTGltCkludGVuZGVkIHN0YXR1czogU3RhbmRh cmRzIFRyYWNrICAgICAgICAgICAgICAgIHBpY29zTmV0IENvcnAvQWpvdSBVbml2LgpFeHBpcmVz OiBTZXB0ZW1iZXIgMTEsIDIwMDggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBTLiBZb28KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQWpvdSBVbml2ZXJzaXR5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFMuIFBhcmssIEVkLgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNBTVNVTkcgRWxlY3Ryb25pY3MK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEcuIE11bGxpZ2FuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNYXJjaCAxMCwgMjAwOAoKCiAgICAgICAgICAgICAgICAgICAgICAg IENvbW1pc3Npb25pbmcgaW4gNkxvV1BBTgogICAgICAgICAgICAgICBkcmFmdC1kYW5pZWwtNmxv d3Bhbi1jb21taXNzaW9uaW5nLTAxLnR4dAoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgQnkgc3Vi bWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQg YW55CiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUg b3Igc2hlIGlzIGF3YXJlCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFu eSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcwogICBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwg aW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFm dHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBU YXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90 ZSB0aGF0CiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1l bnRzIGFzIEludGVybmV0LQogICBEcmFmdHMuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0 IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBi ZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBh bnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBh cyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndv cmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMg Y2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJh Y3RzLnR4dC4KCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3Rvcmll cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4K CiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gU2VwdGVtYmVyIDExLCAyMDA4 LgoKQWJzdHJhY3QKCiAgIFRoZSBjb21taXNpb25pbmcgcHJvY2VzcyBkZWZpbmVzIHRoZSBzdGFy dHVwIHByb2NlZHVyZSB0YWtlbiBieSB0aGUKICAgNkxvV1BBTiBkZXZpY2UuICBUaGlzIGRvY3Vt ZW50IGRlZmluZXMgdGhlIHN0YXJ0dXAgcHJvY2VkdXJlIHRoYXQgYWxsCiAgIGtpbmRzIG9mIGRl dmljZXMgbXVzdCB0YWtlIHRvIGJlY29tZSBwYXJ0IG9mIHRoZSBuZXR3b3JrLgoKCgoKCgoKS2lt LCBFZC4sIGV0IGFsLiAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMSwgMjAwOCAgICAgICAgICAg ICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgQ29tbWlzc2lvbmluZyBpbiA2 TG9XUEFOICAgICAgICAgICAgICBNYXJjaCAyMDA4CgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEu ICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMwogICAyLiAgVGVybWlub2xvZ3kgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMKICAgICAyLjEuICBSZXF1aXJlbWVudHMgbm90YXRp b24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgIDMuICBCb290c3Ry YXBwaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg NAogICAgIDMuMS4gIFJlc2V0dGluZyB0aGUgZGV2aWNlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDQKICAgICAzLjIuICBTY2FubmluZyB0aHJvdWdoIGNoYW5uZWxzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgMy4zLiAgU3RhcnRpbmcgYSBu ZXcgbmV0d29yayAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAgIDMu NC4gIEpvaW5pbmcgdGhlIG5ldHdvcmsgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDYKICAgICAgIDMuNC4xLiAgSm9pbmluZyB0aGUgbmV0d29yayB3aXRoIGFzc29jaWF0 aW9uIC4gLiAuIC4gLiAuIC4gLiAuICA2CiAgICAgICAzLjQuMi4gIEpvaW5pbmcgdGhlIG5ldHdv cmsgd2l0aG91dCBhc3NvY2lhdGlvbiAgLiAuIC4gLiAuIC4gLiAgOAogICAgIDMuNS4gIFNldHRp bmcgdGhlIGJlYWNvbiBkYXRhIHN0cnVjdHVyZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgK ICAgNC4gIEFzc2lnbmluZyB0aGUgc2hvcnQgYWRkcmVzcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA4CiAgIDUuICBPYnRhaW5pbmcgSVB2NiBhZGRyZXNzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICA2LiAgQ29uZmlndXJhdGlvbiBQYXJh bWV0ZXJzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgNy4gIElB TkEgQ29uc2lkZXJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDEwCiAgIDguICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxMAogICA5LiAgQWNrbm93bGVkZ21lbnRzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgMTAuIFJlZmVyZW5jZXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAg ICAgMTAuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxMQogICAgIDEwLjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgIEludGVsbGVj dHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4g LiAxMwoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpLaW0sIEVkLiwgZXQgYWwuICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA4ICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICBDb21taXNzaW9uaW5nIGluIDZMb1dQQU4gICAgICAgICAgICAgIE1h cmNoIDIwMDgKCgoxLiAgSW50cm9kdWN0aW9uCgogICA2TG9XUEFOIGlzIGEgbG93LXBvd2VyIHdp cmVsZXNzIHBlcnNvbmFsIGFyZWEgbmV0d29yayhMb1dQQU4pIHdoaWNoCiAgIGlzIGNvbXByaXNl ZCBvZiB0aGUgSUVFRSA4MDIuMTUuNC0yMDAzIHN0YW5kYXJkIFtpZWVlODAyLjE1LjRdCiAgIGRl dmljZXMuICBFdmVyeSBkZXZpY2UgbmVlZHMgc3BlY2lmaWMgcHJvY2VkdXJlIHRvIHN0YXJ0IHRo ZWlyCiAgIGZ1bmN0aW9uaW5nLiAgVGhpcyBwcm9jZWR1cmUgbmVlZHMgdG8gYmUgd2VsbCBkZWZp bmVkIGZvcgogICBpbnRlcm9wZXJhYmlsaXR5IG9mIGRldmljZXMgZnJvbSBkaWZmZXJlbnQgdmVu ZG9ycy4gIFRoaXMgZG9jdW1lbnQKICAgZGVmaW5lcyB0aGUgcHJvY2VkdXJlIHRha2VuIGJ5IDZM b1dQQU4gY29uc3RpdHVlbnQgZGV2aWNlcyB3aGVuIHRoZXkKICAgZmlyc3Qgc3RhcnQgb3BlcmF0 aW9uLiAgVGhpcyBwcm9jZWR1cmUgaW52b2x2ZXMgc3RhcnRpbmcgYSBuZXcKICAgbmV0d29yaywg YmVjb21pbmcgcGFydCBvZiBleGlzdGluZyBuZXR3b3JrIGFuZCBvYnRhaW5pbmcgSVAgc2V0dGlu Z3MuCgoKMi4gIFRlcm1pbm9sb2d5CgogICAgICBBY3RpdmUgU2NhbgogICAgICAgICBBbiBhY3Rp dmUgc2NhbiBpcyB1c2VkIGJ5IGFuIEZGRCB0byBsb2NhdGUgYWxsIGNvb3JkaW5hdG9ycwogICAg ICAgICB0cmFuc21pdHRpbmcgYmVhY29uIGZyYW1lcyB3aXRoaW4gaXRzIHBlcnNvbmFsIG9wZXJh dGluZyBzcGFjZSwKICAgICAgICAgd2hpY2ggaXMgcHJvdmlkZWQgYnkgSUVFRSA4MDIuMTUuNC4g IEl0IHJlcXVlc3Qgb3RoZXIgZGV2aWNlcwogICAgICAgICB0byB0cmFuc21pdCB0aGUgYmVhY29u IGZyYW1lLgoKICAgICAgQXNzb2NpYXRpb24KICAgICAgICAgQSBJRUVFIDgwMi4xNS40IGRldmlj ZSBjYW4gYmUgYXNzaWduZWQgYSBkeW5hbWljIDE2IGJpdCBzaG9ydAogICAgICAgICBhZGRyZXNz IGR1cmluZyBhbiBhc3NvY2lhdGlvbiBvcGVyYXRpb24gd2l0aCBhIG5laWdoYm9yIGRldmljZQog ICAgICAgICAob3Igcm91dGVyKSB3aGljaCBpcyBhbHNvIGNhbGxlZCBhcyB0aGUgcGFyZW50IGRl dmljZS4gIEFmdGVyCiAgICAgICAgIGdldHRpbmcgdGhlIHNob3J0IGFkZHJlc3MsIGEgZGV2aWNl IGNhbiBjb21tdW5pY2F0ZSB3aXRoIGl0cwogICAgICAgICBwYXJlbnQgb3IgY2hpbGQgYnkgdXNp bmcgb25seSB0aGUgYXNzaWduZWQgc2hvcnQgYWRkcmVzcy4KCiAgICAgIENvb3JkaW5hdG9yCiAg ICAgICAgIEEgZnVsbC1mdW5jdGlvbiBkZXZpY2UgKEZGRCkgd2hpY2ggaXMgdGhlIHByaW5jaXBh bCBjb250cm9sbGVyCiAgICAgICAgIG9mIGEgNkxvV1BBTi4gIEl0IGlzIGFsc28gY2FsbGVkIGFz IFBBTiBjb29yZGluYXRvci4gIEl0IE1BWQogICAgICAgICBpbml0aWF0ZSB0aGUgc3luY2hyb25p emF0aW9uIG9mIHRoZSBlbnRpcmUgNkxvV1BBTiBieQogICAgICAgICB0cmFuc21pdHRpbmcgYmVh Y29ucy4KCiAgICAgIEVEIFNjYW4KICAgICAgICAgQW4gRUQgc2NhbiBhbGxvd3MgYSBkZXZpY2Ug dG8gb2J0YWluIGEgbWVhc3VyZSBvZiB0aGUgcGVhawogICAgICAgICBlbmVyZ3kgaW4gZWFjaCBy ZXF1ZXN0ZWQgY2hhbm5lbCwgd2hpY2ggaXMgcHJvdmlkZWQgYnkgSUVFRQogICAgICAgICA4MDIu MTUuNC4KCiAgICAgIEZ1bGwgRnVuY3Rpb24gRGV2aWNlIChGRkQpCiAgICAgICAgIEEgZGV2aWNl IGltcGxlbWVudGluZyB0aGUgY29tcGxldGUgcHJvdG9jb2wgc2V0IG9mIElFRUUKICAgICAgICAg ODAyLjE1LjQuICBJdCBpcyBjYXBhYmxlIG9mIG9wZXJhdGluZyBhcyBhIHJvdXRlciAobXVsdGkt aG9wCiAgICAgICAgIHBhY2tldCBmb3J3YXJkaW5nKSBmb3IgaXRzIGFzc29jaWF0ZWQgbmVpZ2hi b3JzLgoKICAgICAgTmVpZ2hib3IgVGFibGUKICAgICAgICAgQSB0YWJsZSB3aGljaCBoYXMgdGhl IGluZm9ybWF0aW9uIG9mIG5laWdoYm9yIGRldmljZXMgaW4gYQogICAgICAgICBwZXJzb25hbCBv cGVyYXRpbmcgc3BhY2UuCgoKCgoKS2ltLCBFZC4sIGV0IGFsLiAgICAgICBFeHBpcmVzIFNlcHRl bWJlciAxMSwgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgQ29tbWlzc2lvbmluZyBpbiA2TG9XUEFOICAgICAgICAgICAgICBNYXJjaCAyMDA4CgoK CiAgICAgIFBBTiBJZAogICAgICAgICBUaGUgMTYgYml0IDZMb1dQQU4gaWRlbnRpZmllciB3aGlj aCBpcyBhZG1pbmlzdHJhdGl2ZWx5CiAgICAgICAgIGFzc2lnbmVkIHRvIGEgNkxvV1BBTi4KCiAg ICAgIFBhc3NpdmUgU2NhbgogICAgICAgICBBIHBhc3NpdmUgc2NhbiwgbGlrZSBhbiBhY3RpdmUg c2NhbiwgaXMgdXNlZCBieSBhbiBGRkQgdG8KICAgICAgICAgbG9jYXRlIGFsbCBjb29yZGluYXRv cnMgdHJhbnNtaXR0aW5nIGJlYWNvbiBmcmFtZXMgd2l0aGluIGl0cwogICAgICAgICBwZXJzb25h bCBvcGVyYXRpbmcgc3BhY2UsIHdoaWNoIGlzIHByb3ZpZGVkIGJ5IElFRUUgODAyLjE1LjQuCiAg ICAgICAgIFRoZSBkaWZmZXJlbmNlIGlzIHRoYXQgdGhlIHBhc3NpdmUgc2NhbiBpcyBhIHJlY2Vp dmUtb25seQogICAgICAgICBvcGVyYXRpb24gYW5kIGRvZXMgbm90IHJlcXVlc3QgdGhlIGJlYWNv biBmcmFtZS4KCiAgICAgIFBlcnNvbmFsIE9wZXJhdGluZyBTcGFjZSAoUE9TKQogICAgICAgICBU aGUgYXJlYSB3aXRoaW4gdGhlIHJlY2VwdGlvbiByYW5nZSBvZiB0aGUgd2lyZWxlc3MKICAgICAg ICAgdHJhbnNtaXNzaW9uIG9mIGEgSUVFRSA4MDIuMTUuNCBwYWNrZXQuCgogICAgICBSZWR1Y2Vk IEZ1bmN0aW9uIERldmljZSAoUkZEKQogICAgICAgICBBIElFRUUgODAyLjE1LjQgZGV2aWNlIG9m IDZMb1dQQU4gd2hpY2ggZG9lcyBub3QgaGF2ZSB0aGUKICAgICAgICAgZnVuY3Rpb25hbGl0eSBv ZiB0aGUgcm91dGVyLiAgVGhhdCBpcywgaXQgY2FuIG5vdCBmb3J3YXJkIElQdjYKICAgICAgICAg cGFja2V0cyB0byB0aGUgbmV4dCBob3AgZGV2aWNlLiAgSXQgY2FuIG9ubHkgYmUgdGhlIGVuZCBk ZXZpY2UKICAgICAgICAgb2YgNkxvV1BBTi4KCiAgICAgIFNob3J0IEFkZHJlc3MKICAgICAgICAg QSAxNiBiaXQgYWRkcmVzcyBkeW5hbWljYWxseSBhc3NpZ25lZCB0byBhIGRldmljZSBmcm9tIGl0 cwogICAgICAgICBwYXJlbnQuCgoKMi4xLiAgUmVxdWlyZW1lbnRzIG5vdGF0aW9uCgogICBUaGUg a2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxM IE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBh bmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBh cyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKCjMuICBCb290c3RyYXBwaW5nCgogICBCb290c3Ry YXBwaW5nIGlzIGRlZmluZWQgYXMgYXNzb2NpYXRpbmcgd2l0aCB0aGUgbmV0d29yayBhbmQKICAg b2J0YWluaW5nIElQdjYgYWRkcmVzcy4gIFNwZWNpZmljYWxseSwgdGhpcyBpbmNsdWRlcyB0aGUg cHJvY2VzcyBvZgogICBzdGFydGluZyB0aGUgbmV0d29yaywgYXNzb2NpYXRpbmcgd2l0aCBvdGhl ciBub2Rlcywgb2J0YWluaW5nIHRoZQogICB1bmlxdWUgSVB2NiBhZGRyZXNzLCBhbmQgY29uc3Ry dWN0aW5nIHNlY3VyaXR5IGNyZWRlbnRpYWxzIGZvcgogICA2TG9XUEFOLgoKMy4xLiAgUmVzZXR0 aW5nIHRoZSBkZXZpY2UKCiAgIEFmdGVyIHRoZSBkZXZpY2UgaXMgc3RhcnRlZCwgaXQgZmlyc3Qg cGVyZm9ybWVkIGEgTUFDIGxheWVyIHJlc2V0LCBieQogICBpc3N1aW5nIE1MTUUtUkVTRVQucmVx dWVzdCB3aXRoIHRoZSBTZXREZWZhdWx0UElCIHBhcmFtZXRlciBzZXQgdG8KICAgVFJVRS4KCgoK CktpbSwgRWQuLCBldCBhbC4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTEsIDIwMDggICAgICAg ICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIENvbW1pc3Npb25pbmcg aW4gNkxvV1BBTiAgICAgICAgICAgICAgTWFyY2ggMjAwOAoKCjMuMi4gIFNjYW5uaW5nIHRocm91 Z2ggY2hhbm5lbHMKCiAgIER1cmluZyB0aGlzIHBoYXNlLCBmdW5jdGlvbmFsIHN1cHBvcnRzIGJ5 IDgwMi4xNS40IGFyZSB1c2VkIGZvcgogICBzY2FubmluZyBjaGFubmVscy4KCiAgICAgICBBZGFw dGF0aW9uICAgICAgICAgICAgICAgICAgICAgICAgRGV2aWNlCiAgICAgICAgICBMYXllciAgICAg ICAgICAgICAgICAgICAgICAgICAgICBNQUMKICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICAgICAgIHwgICAgICBNTE1FLVNDQU4ucmVxdWVzdChhY3Rp dmUpfAogICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwKICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICBCZWFjb24gcmVxdWVzdAogICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0+CiAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBCZWFjb24KICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0t LQogICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAg ICAgfCBNTE1FLVNDQU4uY29uZmlybSAgICAgICAgICAgICB8CiAgICAgICAgICAgIHw8LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwKCiAgIEFjdGl2ZSBTY2FuCgogICAgICAgIEFkYXB0YXRpb24gICAgICAg ICAgICAgICAgICAgICAgIERldmljZQogICAgICAgICAgTGF5ZXIgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTUFDCiAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICAgICAgICB8ICAgIE1MTUUtU0NBTi5yZXF1ZXN0KHBhc3NpdmUpIHwKICAgICAgICAg ICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58CiAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgQmVhY29uCiAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0KICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgIHwgTUxNRS1TQ0FOLmNvbmZpcm0gICAgICAg ICAgICAgfAogICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CgogICBQYXNzaXZlIFNj YW4KCiAgIEZvciBnZXR0aW5nIHRoZSBpbmZvcm1hdGlvbiBvZiBvdGhlciBkZXZpY2VzIHdpdGhp biBQT1MsIHRoZSBkZXZpY2UKICAgc2hvdWxkIHBlcmZvcm0gYSBzY2FuIGFjcm9zcyBhIHNwZWNp ZmllZCBsaXN0IG9mIGNoYW5uZWxzIHdoaWNoIGlzCiAgIGRlZmluZWQgYXMgQ0hBTk5FTF9MSVNU IGZvciBTQ0FOX0RVUkFUSU9OIHRpbWUuICBUaGUgZGV2aWNlIGNhbiB1c2UKICAgZWl0aGVyIGFu IGFjdGl2ZSBzY2FuIG9yIGEgcGFzc2l2ZSBzY2FuLiAgRHVyaW5nIHNjYW5uaW5nIHByb2NlZHVy ZSwKICAgdGhlIGRldmljZSByZWNlaXZlIGJlYWNvbiBmcmFtZXMgZnJvbSBvdGhlciBkZXZpY2Vz LiAgVGhlIGJlYWNvbgogICBmcmFtZSBjb250YWlucyB0aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhl IGRldmljZSBzZW5kaW5nIGl0LCB3aGljaCBpcwogICB1c2VkIGZvciBkZXRlcm1pbmUgd2hldGhl ciBhIGRldmljZSBpcyA2TG9XUEFOIGRldmljZSBvciBub3QuICBJZiB0aGUKICAgZGV2aWNlIHdo aWNoIHNlbmQgdGhlIGJlYWNvbiBmcmFtZSBpcyBkaXN0aW5ndXNoZWQgYXMgdGhlIDZMb1dQQU4K ICAgZGV2aWNlLCBpdHMgaW5mb3JtYXRpb24gc2hvdWxkIGJlIHN0b3JlZCBpbiB0aGUgbmVpZ2hi b3IgdGFibGUuCgoKCgoKS2ltLCBFZC4sIGV0IGFsLiAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAx MSwgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg Q29tbWlzc2lvbmluZyBpbiA2TG9XUEFOICAgICAgICAgICAgICBNYXJjaCAyMDA4CgoKMy4zLiAg U3RhcnRpbmcgYSBuZXcgbmV0d29yawoKICAgQSBub2RlIHdoaWNoIHN0YXJ0cyBhIG5ldyBuZXR3 b3JrIG1heSBiZWNvbWUgdGhlIGNvb3JkaW5hdG9yLiAgV2hpY2gKICAgZGV2aWNlcyBiZWNvbWUg dGhlIGNvb3JkaW5hdG9yIGRlcGVuZHMgb24gdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlCiAgIGRl dmljZSBhbmQgdGhlIHN0YXRlIG9mIGV4aXN0aW5nIG5ldHdvcmtzLgoKICAgUHJpb3IgdG8gc3Rh cnRpbmcgYSBuZXcgbmV0d29yaywgdGhlIGRldmljZSBmaXJzdCBwZXJmb3JtIGEgc2NhbiBmb3IK ICAgbG9jYXRpbmcgdGhlIFBBTiB3aXRoaW4gaXRzIFBPUy4gIERldGFpbGVkIHByb2NlZHVyZSBv ZiBhIHNjYW4gaXMKICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4gIFRoZSBkZXZpY2Ugc2hvdWxk IHNlbGVjdCBhIGNoYW5uZWwgd2l0aCB0aGUKICAgbGVhc3QgbnVtYmVyIG9mIG5ldHdvcmtzLCBw cmVmZXJyYWJseSBzZWxlY3RpbmcgYSBjaGFubmVsIHdpdGggbm8KICAgbmV0d29yayBpZiBwb3Nz aWJsZS4gIE9uIHRoaXMgc3RlcCwgVGhlIGRldmljZSBtYXkgdXNlIGFuIEVEIHNjYW4gdG8KICAg c2VsZWN0IGEgY2hhbm5lbCB3aGljaCBoYXMgbGVzcyBjaGFubmVsIHVzYWdlLgoKICAgQWZ0ZXIg c2VsZWN0aW5nIGEgY2hhbm5lbCBmb3IgYSBuZXcgbmV0d29yaywgdGhlIGRldmljZSBzaGFsbCBz ZWxlY3QKICAgYSBQQU4gSWQgd2hpY2ggaXMgdW5pcXVlIGFtb25nIFBBTnMgd2l0aGluIGl0cyBQ T1MuICBJZiBhIG5vZGUgY2FuJ3QKICAgZmluZCBzdWl0YWJsZSBQQU4gSUQsIGl0IG1heSByZXRy eSB0aGlzIHByb2NlZHVyZSBhZnRlcgogICBTVEFSVF9SRVRSWV9USU1FLiAgVGhlIGFsZ29yaXRo bSBmb3Igc2VsZWN0aW5nIGEgc3VpdGFibGUgUEFOIElkIGlzCiAgIFRCRC4KCiAgIFRoZSBub2Rl IHdoaWNoIHN0YXJ0IGEgbmV3IG5ldHdvcmsgc2hhbGwgc2V0IHRoZSBuZXR3b3JrJ3Mgc3VwZXJm cmFtZQogICBvcmRlciBhbmQgYmVhY29uIG9yZGVyIHRvIFNVUEVSRlJBTUVfT1JERVIgYW5kIEJF QUNPTl9PUkRFUgogICByZXNwZWN0aXZlbHkuCgogICBBZnRlciBhbGwgcHJvY2VkdXJlIGlzIGRv bmUsIGEgbm9kZSBzaGFsbCBleGN1dGUgTUFDIHN0YXJ0IHByaW1pdGl2ZQogICBhbmQgc3RhcnQg dG8gYWN0IGFzIHRoZSBGRkQgbm9kZS4KCiAgICAgICAgQWRhcHRhdGlvbiAgICAgICAgICAgICAg ICAgICAgRkZECiAgICAgICAgICBMYXllciAgICAgICAgICAgICAgICAgICAgICAgTUFDCiAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgfCAgICAgICBN TE1FLVNUQVJULnJlcXVlc3QgfAogICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LT58CiAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICBCZWFjb24gZnJhbWUKICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0+CiAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgfCBNTE1FLVNUQVJULmNv bmZpcm0gICAgICAgfAogICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18CiAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKCjMuNC4gIEpvaW5pbmcgdGhl IG5ldHdvcmsKCjMuNC4xLiAgSm9pbmluZyB0aGUgbmV0d29yayB3aXRoIGFzc29jaWF0aW9uCgoK CgoKCgoKCktpbSwgRWQuLCBldCBhbC4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTEsIDIwMDgg ICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIENvbW1pc3Np b25pbmcgaW4gNkxvV1BBTiAgICAgICAgICAgICAgTWFyY2ggMjAwOAoKCiAgIERldmljZSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBEZXZpY2UKICBBZGFwdGF0aW9uICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNQUMKICAgIExheWVyCiAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgICAgfCAgICAgICAgICAgIE1MTUUtQVNTT0NJQVRFLnJlcXVl c3QgfAogICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58CiAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICBhc3NvY2lhdGlvbiBy ZXF1ZXN0CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPgogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgYXNz b2NpYXRpb24gcmVzcG9uc2UKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgICAgIHwgTUxNRS1BU1NPQ0lBVEUu Y29uZmlybSAgICAgICAgICAgIHwKICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tfAogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CgoKICAg ICAgICAgICAgICAgICAgICAgICAgICBDb29yZGluYXRvciAgICAgICAgICAgICAgICAgICAgICAg IENvb3JkaW5hdG9yCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1BQyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQWRhcHRhdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExheWVyCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg ICAgICAgICAgYXNzb2NpYXRpb24gcmVxdWVzdCB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CiAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgTUxNRS1BU1NPQ0lBVEUuaW5kaWNhdGlvbiB8CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IE1MTUUtQVNTT0NJQVRFLnJlc3BvbnNl ICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgIGFzc29jaWF0aW9uIHJl c3BvbnNlICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgPC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CgogICBUbyBqb2luIHRoZSBuZXR3b3JrLCB0aGUgZGV2aWNlIGZpcnN0 IHBlcmZvcm1zIHRoZSBzY2FubmluZyBmb3IKICAgZGlzY292ZXJ5aW5nIHRoZSBQQU4gd2l0aGlu IGl0cyBQT1MuICBEZXRhaWxlZCBwcm9jZWR1cmUgb2YgYSBzY2FuIGlzCiAgIGRlc2NyaWJlZCBp biBTZWN0aW9uIDQuICBPbiBjb21wbGV0aW9uIG9mIHNjYW4sIHRoZSBkZXZpY2Ugc2VsZWN0cwog ICB0aGUgbmV0d29yayBpdCB3aXNoZXMgdG8gam9pbiBmcm9tIHRoZSBzY2FubmluZyByZXN1bHQu ICBJdCB0aGVuCiAgIGZpbmRzIHRoZSBkZXZpY2Ugd2hpY2ggY29ycmVzcG9uZHMgdG8gdGhhdCBu ZXR3b3JrIGluIGl0cyBuZWlnaGJvcgogICB0YWJsZSBhbmQgaXQgcmVxdWVzdHMgdG8gYXNzb2Np YXRlIHVzaW5nIE1BQyBwcmltaXRpdmUgdG8gdGhhdAogICBwYXJ0aWN1bGFyIGRldmljZS4gIElm IHRoZSBkZXZpY2UgY291bGRuJ3Qgc3VjY2VzcyB0byBhc3NvY2lhdGUgd2l0aAogICBhIGRldmlj ZSwgaXQgbWF5IHJldHJ5IHRoZSBhc3NvY2lhdGlvbiBhZnRlciBBU1NPQ0lBVElPTl9SRVRSWV9U SU1FLgogICBBbmQgaWYgdGhlIGRldmljZSBmYWlsZWQgdG8gYXNzb2NpYXRlIHdpdGggYWxsIGRl dmljZXMgd2hpY2ggaXMKICAgZGlzY292ZXJlZCwgaXQgbWF5IHJldHJ5IHRoZSBzY2FubmluZyBw cm9jZWR1cmUgd2hpY2ggaXMgZGVzY3JpYmVkIGluCiAgIFNlY3Rpb24gMy4yIGFmdGVyIEpPSU5f UkVUUllfVElNRS4KCiAgIFRoZSBhbGdvcml0aG0gZm9yIHNlbGVjdGluZyBhIGRldmljZSBpdCB3 aXNoZXMgdG8gYXNzb2NpYXRlIGFtb25nCiAgIGRldmljZXMgaW4gdGhlIG5ldHdvcmsgaXMgVEJE LgoKCgoKCktpbSwgRWQuLCBldCBhbC4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTEsIDIwMDgg ICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIENvbW1pc3Np b25pbmcgaW4gNkxvV1BBTiAgICAgICAgICAgICAgTWFyY2ggMjAwOAoKCjMuNC4yLiAgSm9pbmlu ZyB0aGUgbmV0d29yayB3aXRob3V0IGFzc29jaWF0aW9uCgogICBUaGUgZGV2aWNlIGRvZXNuJ3Qg bmVlZCB0byBhc3NvY2lhdGUgd2l0aCBvdGhlciBkZXZpY2VzIHRvIGJlY29tZQogICBwYXJ0IG9m IHRoZSBuZXR3b3JrLiAgVGhlIG5vbi1hc3NvY2lhdGVkIGRldmljZSwgaG93ZXZlciwgbXVzdCB1 c2UKICAgdGhlIDY0LWJpdCBleHRlbmRlZCBhZGRyZXNzIHRvIGNvbW11bmljYXRlLiAgSW4gdGhp cyBjYXNlLCB0aGUgZGV2aWNlCiAgIHNob3VsZCBwZXJmb3JtIHNjYW5uaW5nIHBlcmlvZGljYWxs eSBzaW5jZSBkZXZpY2VzIGFyZW4ndCBib3VuZCB0bwogICBlYWNoIG90aGVyIHN0cm9uZ2x5LiAg RGV0YWlsZWQgcHJvY2VkdXJlIG9mIGEgc2NhbiBpcyBkZXNjcmliZWQgaW4KICAgU2VjdGlvbiA0 LgoKMy41LiAgU2V0dGluZyB0aGUgYmVhY29uIGRhdGEgc3RydWN0dXJlCgogICBBZnRlciBhc3Nv Y2lhdGluZyB3aXRoIHRoZSBuZXR3b3JrLCBUaGUgZGV2aWNlIHNob3VsZCBzZXQgaXRzIGJlYWNv bgogICBkYXRhIHN0cnVjdHVyZSwgd2hpY2ggaXMgYXR0YWNoZWQgdG8gdGhlIGJlYWNvbiBmcmFt ZS4gIEEgYmVhY29uCiAgIGZyYW1lIG9mIDgwMi4xNS40IE1BQyBoYXMgdGhlIGJlYWNvbiBwYXls b2FkIGZpZWxkcyB3aGljaCBoYXZlCiAgIHZhcmlhYmxlIGxlbmd0aC4gIFRoZSBiZWFjb24gcGF5 bG9hZCBjYW4gYmUgc2V0IGJ5IHRoZSB1cHBlcmxheWVyLgogICBUaGUgYmVhY29uIGRhdGEgc3Ry dWN0dXJlIGlzIGFzIGZvbGxvd3MuCgoKICAgICAgMCAgICAgICAgICAgICAgICAgICAxCiAgICAg IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUKICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsKICAgICB8ICAgVmVuZG9yIElEICAgfCAgIFByb2R1Y3QgSUQgIHwKICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgICArLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLSsK ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICArLSAgICAgICAgRVVJ LTY0IEFkZHJlc3MgICAgICAgLSsKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgICArLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLSsKICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKCiAgIFZlbmRvciBJRDogIENvbnRhaW5zIHRoZSBWZW5kb3IncyB1bmlxdWUgSUQKICAg UHJvZHVjdCBJRDogIENvbnRhaW5zIHRoZSBQcm9kdWN0J3MgdW5pcXVlIElECiAgIEVVSS02NCBB ZGRyZXNzOiAgQ29udGFpbnMgdGhlIEVVSS02NCBhZGRyZXNzIG9mIHRoZSBzZW5kZXIuCgogICBU aGlzIGJlYWNvbiBkYXRhIHN0cnVjdHVyZSBzaGFsbCBiZSBjb250YWluZWQgaW4gTUFDIGJlYWNv biBmcmFtZS4KICAgVGhlIGRldmljZSB3aGljaCByZWNlaXZlZCB0aGUgYmVhY29uIG1heSB1c2Ug dGhlIGluZm9ybWF0aW9uIG9mCiAgIGJlYWNvbiBkYXRhIHN0cnVjdHVyZSBmb3IgdmVyaWZ5aW5n IHRoZSBzYW1lIHByb2R1Y3QgYW5kIHRoZSBFVUktNjQKICAgYWRkcmVzcy4KCgo0LiAgQXNzaWdu aW5nIHRoZSBzaG9ydCBhZGRyZXNzCgogICBEdXJpbmcgYXNzb2NpYXRpb24gcHJvY2VkdXJlLCBl dmVyeSBkZXZpY2UgZXhjZXB0IHRoZSBjb29yZGluYXRvciBpcwogICBnaXZlbiBpdHMgc2hvcnQg YWRkcmVzcyBmcm9tIHRoZSBwYXJlbnQgZGV2aWNlIHdoaWNoIGlzIGJlaW5nCiAgIHJlcXVlc3Rl ZCB0byBhc3NvY2lhdGUuICBUaGUgY29vcmRpbmF0b3IgYXNzaWducyBpdHMgc2hvcnQgYWRkcmVz cwogICBhZnRlciBzZWxlY3RpbmcgYSBQQU4gSUQgYnkgaXRzZWxmLiAgVGhlIHNob3J0IGFkZHJl c3MgbXVzdCBiZSB1bmlxdWUKCgoKS2ltLCBFZC4sIGV0IGFsLiAgICAgICBFeHBpcmVzIFNlcHRl bWJlciAxMSwgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgQ29tbWlzc2lvbmluZyBpbiA2TG9XUEFOICAgICAgICAgICAgICBNYXJjaCAyMDA4CgoK ICAgaW4gYSBuZXR3b3JrIGFuZCBtYXkgYmUgZ2l2ZW4gYnkgYSBkaXN0cmlidXRlZCB3YXkuICBU aGUgc3BlY2lmaWMKICAgYWxnb3JpdGhtIGZvciBhc3NpZ25pbmcgdGhlIHNob3J0IGFkZHJlc3Mg aXMgVEJELgoKCjUuICBPYnRhaW5pbmcgSVB2NiBhZGRyZXNzCgogICBUaGUgSVB2NiBpbnRlcmZh Y2UgaWRlbnRpZmllciBvZiBhIGRldmljZSBjYW4gYmUgb2J0YWluZWQgYXMKICAgZGVzY3JpYmVk IGluIFNlY3Rpb24gNiBvZiBbcmZjNDk0NF0uCgogICBBZnRlciBoYXZpbmcgYSB1bmlxdWUgSVB2 NiBpbnRlcmZhY2UgaWRlbnRpZmllciwgdGhlIGRldmljZSBiZWdpbnMgdG8KICAgb2J0YWluIGFu IElQdjYgYWRkcmVzcyBwcmVmaXguICBUaGUgSVB2NiBhZGRyZXNzIHByZWZpeCBmb3IgYQogICBw YXJ0aWN1bGFyIDZMb1dQQU4gaXMgc3RvcmVkIGJ5IHRoZSBJUHY2IHJvdXRlciBpbiB0aGUgNkxv V1BBTi4KICAgSUNNUHY2IGlzIHVzZWQgdG8gc2hhcmUgdGhlc2UgcGFyYW1ldGVycy4gIFJvdXRl cnMgaW4gNkxvV1BBTiBhcmUKICAgc3VwcG9zZWQgdG8gYnJvYWRjYXN0IFJvdXRlciBBZHZlcnRp c2VtZW50cyhSQSkgbWVzc2FnZXMKICAgcGVyaW9kaWNhbGx5LiAgVGhlIFJBIG1lc3NhZ2UgbXVz dCBjb250YWluIHRoZSBwcmVmaXggb3B0aW9uIHdoaWNoCiAgIGNhbiBiZSB1c2VkIGluIHRoZSA2 TG9XUEFOLiAgRGV2aWNlcyB3aXNoIHRvIG9idGFpbiBJUHY2IGFkZHJlc3MKICAgcHJlZml4IG1h eSB3YWl0IGZvciBhbiBSQSBtZXNzYWdlIHVudGlsIFJBX1dBSVRfVElNRSBlbGFwc2VkLiAgQWZ0 ZXIKICAgdGhhdCwgaWYgbm8gUkEgbWVzc2FnZSBpcyByZWNlaXZlZCwgdGhleSBtYXkgYnJvYWRj YXN0IFJvdXRlcgogICBTb2xpY2l0YXRpb24oUlMpIG1lc3NhZ2UgZm9yIHJlcXVlc3RpbmcgdGhl IFJBIG1lc3NhZ2UuCgogICBUaGUgUlMgYW5kIFJBIG1lc3NhZ2VzIGNhbiBoYXZlIGFkZGl0aW9u YWwgb3B0aW9uIGZpZWxkcyBhcyBkZXNjcmliZWQKICAgaW4gW3JmYzQ4NjFdLiAgU291cmNlL1Rh cmdldCBsaW5rLWxheWVyIGFkZHJlc3Mgb3B0aW9uIGZpZWxkIHNob3VsZAogICBjb250YWluIHRo ZSBFVUktNjQgYWRkcmVzcyBvciB0aGUgY29tYmluZWQgYWRkcmVzcyB3aXRoIFBBTiBJRCBhbmQK ICAgMTZiaXQgc2hvcnQgYWRkcmVzcyBvZiB0aGUgc291cmNlIG9yIHRhcmdldCBkZXZpY2UgYXMg YmVsb3cuCgogICAgMCAgICAgICAgICAgICAgICAgICAxCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAg ICBUeXBlICAgICAgfCAgICBMZW5ndGggICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICArLSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLSsKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICstICAgICAgICBFVUktNjQgQWRkcmVzcyAgICAgICAtKwogICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0gICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0rCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgUmVzZXJ2ZWQgICAgICAgICAgICB8 CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKCgoKCgoKCgoKCktpbSwgRWQu LCBldCBhbC4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTEsIDIwMDggICAgICAgICAgICAgICBb UGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIENvbW1pc3Npb25pbmcgaW4gNkxvV1BB TiAgICAgICAgICAgICAgTWFyY2ggMjAwOAoKCiAgICAwICAgICAgICAgICAgICAgICAgIDEKICAg IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUKICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgIHwgICAgIFR5cGUgICAgICB8ICAgIExlbmd0aCAgICAgfAogICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICBQQU4gSUQgICAg ICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAg ICAgU2hvcnQgQWRkcmVzcyAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgIHwgICAgICAgICAgICBSZXNlcnZlZCAgICAgICAgICAgfAogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgIFNvdXJjZS9UYXJnZXQgTGluay1sYXllciBBZGRy ZXNzIG9wdGlvbiBmaWVsZAoKICAgTXVsdGlwbGUgSVB2NiByb3V0ZXJzIGNvdWxkIGZvcm0gYSBz aW5nbGUgb3IgbXVsdGlwbGUgNmxvd3BhbihzKS4gIElmCiAgIHRoZXJlIGFyZSBtdWx0aXBsZSBy b3V0ZXJzIGluIGEgNkxvV1BBTiwgdGhlIGRldmljZSBzaG91bGQgY29uc2lkZXIKICAgd2hpY2gg b25lIGlzIHRvIGJlIHNlbGVjdGVkIGFzIGEgZGVmYXVsdCByb3V0ZXIuICBPbmUgcG9zc2libGUg d2F5IG9mCiAgIHNlbGVjdGlvbiBpcyB0byBjb21wYXJlIHRoZSBob3AgY291bnRzIHRyYXZlbGVk IG9mIHRoZSBSQSBtZXNzYWdlIG9mCiAgIGVhY2ggcm91dGVyLiAgVGhlIGRldGFpbGVkIGFsZ29y aXRobSBmb3IgdGhlIHNlbGVjdGlvbiBpcyBUQkQuCgoKNi4gIENvbmZpZ3VyYXRpb24gUGFyYW1l dGVycwoKICAgVGhpcyBzZWN0aW9uIGdpdmVzIGRlZmF1bHQgdmFsdWVzIGZvciBzb21lIGltcG9y dGFudCBwYXJhbWV0ZXJzCiAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgNkxvV1BBTiBjb21taXNzaW9u aW5nIHByb3RvY29sLiAgQSBwYXJ0aWN1bGFyCiAgIG5vZGUgbWF5IHdpc2ggdG8gY2hhbmdlIGNl cnRhaW4gb2YgdGhlIHBhcmFtZXRlcnMuCgogICAgICBQYXJhbWV0ZXIgTmFtZSAgICAgICAgICAg VmFsdWUKICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgIC0tLS0tCiAgICAgIENIQU5ORUxf TElTVCAgICAgICAgICAgICAweEZGRkY4MDAKICAgICAgU0NBTl9EVVJBVElPTiAgICAgICAgICAg IDMKICAgICAgU1VQRVJGUkFNRV9PUkRFUiAgICAgICAgIDE1CiAgICAgIEJFQUNPTl9PUkRFUiAg ICAgICAgICAgICAxNQogICAgICBTVEFSVF9SRVRSWV9USU1FICAgICAgICAgMTAwMCBtc2VjCiAg ICAgIEpPSU5fUkVUUllfVElNRSAgICAgICAgICA0MDAwIG1zZWMKICAgICAgQVNTT0NJQVRJT05f UkVUUllfVElNRSAgIDQwMDAgbXNlYwoKCjcuICBJQU5BIENvbnNpZGVyYXRpb24KCiAgIFRCRC4K Cgo4LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIElFRUUgODAyLjE1LjQgZGV2aWNlcyBp cyByZXF1aXJlZCB0byBzdXBwb3J0IEFFUyBsaW5rLWxheWVyIHNlY3VyaXR5LgogICBNQUMgbGF5 ZXIgYWxzbyBwcm92aWRlcyBhbGwga2V5aW5nIG1hdGVyaWFsIG5lY2Vzc2FyeSB0byBwcm92aWRl IHRoZQogICBzZWN1cml0eSBzZXJ2aWNlcy4KCgoKS2ltLCBFZC4sIGV0IGFsLiAgICAgICBFeHBp cmVzIFNlcHRlbWJlciAxMSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgQ29tbWlzc2lvbmluZyBpbiA2TG9XUEFOICAgICAgICAgICAgICBNYXJj aCAyMDA4CgoKICAgSXQgaXNuJ3QgZGVmaW5lZCwgaG93ZXZlciwgd2hlbiBzZWN1cml0eSBzaGFs bCBiZSB1c2VkIGVzcGVjaWFsbHkKICAgY29tYmluaW5nIHdpdGggYm9vdHN0cmFwcGluZy4gIEFm dGVyIHRoZSBkZXZpY2Ugc3RhcnQgYW5kIGpvaW4gdGhlCiAgIG5ldHdvcmssIHNlY3VyaXR5IHNl cnZpY2VzIHN1Y2ggYXMga2V5IG1hbmFnZW1lbnQgYW5kIGRldmljZQogICBhdXRoZW50aWNhdGlv biBzaG91bGQgYmUgZG9uZSBhdXRvbWF0aWNhbGx5LiAgRGV0YWlsZWQgYWxnb3JpdGhtIGZvcgog ICBzZWN1cml0eSBvbiBib290c3RyYXBwaW5nIGlzIFRCRC4KCgo5LiAgQWNrbm93bGVkZ21lbnRz CgogICBOL0EKCgoxMC4gIFJlZmVyZW5jZXMKCjEwLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoK ICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8g SW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAy MTE5LCBNYXJjaCAxOTk3LgoKICAgW1JGQzQ4NjFdICBOYXJ0ZW4sIFQuLCBOb3JkbWFyaywgRS4s IFNpbXBzb24sIFcuLCBhbmQgSC4gU29saW1hbiwKICAgICAgICAgICAgICAiTmVpZ2hib3IgRGlz Y292ZXJ5IGZvciBJUCB2ZXJzaW9uIDYgKElQdjYpIiwgUkZDIDQ4NjEsCiAgICAgICAgICAgICAg U2VwdGVtYmVyIDIwMDcuCgogICBbUkZDNDk0NF0gIE1vbnRlbmVncm8sIEcuLCBLdXNoYWxuYWdh ciwgTi4sIEh1aSwgSi4sIGFuZCBELiBDdWxsZXIsCiAgICAgICAgICAgICAgIlRyYW5zbWlzc2lv biBvZiBJUHY2IFBhY2tldHMgb3ZlciBJRUVFIDgwMi4xNS40CiAgICAgICAgICAgICAgTmV0d29y a3MiLCBSRkMgNDk0NCwgU2VwdGVtYmVyIDIwMDcuCgogICBbaWVlZTgwMi4xNS40XQogICAgICAg ICAgICAgIElFRUUgQ29tcHV0ZXIgU29jaWV0eSwgIklFRUUgU3RkLiA4MDIuMTUuNC0yMDA2Ii4K CjEwLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMzUxM10gIEhpbmRlbiwgUi4g YW5kIFMuIERlZXJpbmcsICJJbnRlcm5ldCBQcm90b2NvbCBWZXJzaW9uIDYKICAgICAgICAgICAg ICAoSVB2NikgQWRkcmVzc2luZyBBcmNoaXRlY3R1cmUiLCBSRkMgMzUxMywgQXByaWwgMjAwMy4K CgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIEtpLUh5dW5nIEtpbSAoZWRpdG9yKQogICBwaWNvc05l dCBDb3JwL0Fqb3UgVW5pdi4KICAgU2FuIDUgV29uY2h1bi1kb25nLCBZZW9uZ3RvbmctZ3UKICAg U3V3b24tc2ksIEd5ZW9uZ2dpLWRvICA0NDItNzQ5CiAgIEtPUkVBCgogICBQaG9uZTogKzgyIDMx IDIxOSAyNDMzCiAgIEVtYWlsOiBra2ltODZAcGljb3NuZXQuY29tCgoKCgoKS2ltLCBFZC4sIGV0 IGFsLiAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2Ug MTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgQ29tbWlzc2lvbmluZyBpbiA2TG9XUEFOICAg ICAgICAgICAgICBNYXJjaCAyMDA4CgoKICAgQ2hhZS1TZW9uZyBMaW0KICAgcGljb3NOZXQgQ29y cC9Bam91IFVuaXYuCiAgIFNhbiA1IFdvbmNodW4tZG9uZywgWWVvbmd0b25nLWd1CiAgIFN1d29u LXNpLCBHeWVvbmdnaS1kbyAgNDQyLTc0OQogICBLT1JFQQoKICAgUGhvbmU6ICs4MiAzMSAyMTYg MTc2NQogICBFbWFpbDogY3JpbXN1bmlAZ21haWwuY29tCgoKICAgU2V1bmcgV2hhIFlvbwogICBB am91IFVuaXZlcnNpdHkKICAgU2FuIDUgV29uY2h1bi1kb25nLCBZZW9uZ3RvbmctZ3UKICAgU3V3 b24tc2ksIEd5ZW9uZ2dpLWRvICA0NDItNzQ5CiAgIEtPUkVBCgogICBQaG9uZTogKzgyIDMxIDIx NiAxNjAzCiAgIEVtYWlsOiBzd3lvb0Bham91LmFjLmtyCgoKICAgU29vaG9uZyBEYW5pZWwgUGFy ayAoZWRpdG9yKQogICBTQU1TVU5HIEVsZWN0cm9uaWNzCiAgIE1vYmlsZSBQbGF0Zm9ybSBMYWJv cmF0b3J5LCBTQU1TVU5HIEVsZWN0cm9uaWNzIDQxNiBNYWV0YW4tM2RvbmcKICAgWWVvbmd0b25n LWd1LCBTdXdvbi1zaSwgR3llb25nZ2ktZG8gIDQ0Mi03NDIKICAgS09SRUEKCiAgIFBob25lOiAr ODIgMzEgMjAwIDQ1MDgKICAgRW1haWw6IHNvb2hvbmcucGFya0BzYW1zdW5nLmNvbQoKCiAgIEdl b2ZmcmV5IE11bGxpZ2FuCgogICBFbWFpbDogZ2VvZmZAbXVsbGlnYW4uY29tCgoKCgoKCgoKCgoK CgoKCgoKCktpbSwgRWQuLCBldCBhbC4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTEsIDIwMDgg ICAgICAgICAgICAgIFtQYWdlIDEyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIENvbW1pc3Np b25pbmcgaW4gNkxvV1BBTiAgICAgICAgICAgICAgTWFyY2ggMjAwOAoKCkZ1bGwgQ29weXJpZ2h0 IFN0YXRlbWVudAoKICAgQ29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwOCkuCgogICBU aGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3Ry aWN0aW9ucwogICBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0 aGVyZWluLCB0aGUgYXV0aG9ycwogICByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4KCiAgIFRoaXMg ZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRl ZCBvbiBhbgogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTkla QVRJT04gSEUvU0hFIFJFUFJFU0VOVFMKICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBU SEUgSU5URVJORVQgU09DSUVUWSwgVEhFIElFVEYgVFJVU1QgQU5ECiAgIFRIRSBJTlRFUk5FVCBF TkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTCiAg IE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRI QVQgVEhFIFVTRSBPRgogICBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdF IEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQKICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJ VFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuCgoKSW50ZWxsZWN0dWFsIFBy b3BlcnR5CgogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlk aXR5IG9yIHNjb3BlIG9mIGFueQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90 aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8KICAgcGVydGFpbiB0byB0aGUgaW1w bGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbgogICB0aGlz IGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCBy aWdodHMKICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVw cmVzZW50IHRoYXQgaXQgaGFzCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVu dGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbgogICBvbiB0aGUgcHJvY2VkdXJlcyB3 aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlCiAgIGZvdW5kIGlu IEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRv IHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkKICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0 byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbgogICBhdHRlbXB0IG1hZGUg dG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YK ICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRo aXMKICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5l IElQUiByZXBvc2l0b3J5IGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLgoKICAgVGhlIElF VEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9u IGFueQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90 aGVyIHByb3ByaWV0YXJ5CiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQg bWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudAogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFk ZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0CiAgIGlldGYtaXByQGlldGYub3Jn LgoKCgoKCgoKCgoKCktpbSwgRWQuLCBldCBhbC4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTEs IDIwMDggICAgICAgICAgICAgIFtQYWdlIDEzXQoMCgo= ------=_Part_45114_20932409.1205165323658 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 ------=_Part_45114_20932409.1205165323658-- From 6lowpan-bounces@ietf.org Mon Mar 10 10:21:14 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6995A3A6AF7; Mon, 10 Mar 2008 10:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.378 X-Spam-Level: X-Spam-Status: No, score=-101.378 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 b4cvuvLbxG20; Mon, 10 Mar 2008 10:21:13 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603BA3A6CEB; Mon, 10 Mar 2008 10:18: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 844163A6CB7 for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 10:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 tX9liAUHVvbN for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 10:18:45 -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 81A813A6F15 for <6lowpan@ietf.org>; Mon, 10 Mar 2008 10:14:40 -0700 (PDT) Received: from dnab42216d.stanford.edu ([171.66.33.109]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1JYlXv-0004PA-3C; Mon, 10 Mar 2008 10:12:20 -0700 In-Reply-To: <7b2b19400803092128r6d001b91w84cd56621fda2362@mail.gmail.com> References: <7b2b19400803092128r6d001b91w84cd56621fda2362@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <21FEEDBC-3019-4029-AA6C-43F08F55D51E@cs.stanford.edu> From: Philip Levis Date: Mon, 10 Mar 2008 10:12:14 -0700 To: Dhananjay Singh X-Mailer: Apple Mail (2.753) X-Scan-Signature: d568c20fab0e2ccae07d583947984559 Cc: 6lowpan <6lowpan@ietf.org>, tinyos-help Mailing List Subject: Re: [6lowpan] 6lowpan Digest, Vol 38, Issue 15 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 On Mar 9, 2008, at 9:28 PM, Dhananjay Singh wrote: > Dear Friends, > I am Dhananjay Singh from India but now a days i am doing my > research work at in Ubiquitous Sensor Laboratory, Dongseo > University Busan Korea > Friends, i am working on ip-based Wirelesss Sensor Networks so i > have to need 6lowpan stack for telosb mode on tinyos2.02 OS > firstly i want to test communication between two teloseb modes.if > anybody have stack code on 6lowpan then let me know....... > thanks in advance! > with best regard's > Dan The tinyos lists (e.g., tinyos-help) might be a better place for this question (cc'd). There is a 6lowpan stack in the TinyOS CVS tree; the plan is to include it in the next release (2.1). Note that currently, as written, it is not actually interoperable with other 6lowpan stacks. Doing so requires shifting TinyOS from T-Frames to I-Frames (TEP 125), in order to respect the 6lowpan dispatch byte. This topic is on the core WG's agenda for next week. The implementation in tos/lib/net/ 6lowpan currently implements most of 4944 on top of TinyOS's active message layer. If you have questions about the implementation, you should email tinyos-help or the developer (Matus Harvan). Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 10 10:24:53 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130303A6BD8; Mon, 10 Mar 2008 10:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 y5YxPs5pP6fh; Mon, 10 Mar 2008 10:24:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E14E28C188; Mon, 10 Mar 2008 10:23: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 5AC8528C13F; Mon, 10 Mar 2008 10:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ep-cn8QJMhxc; Mon, 10 Mar 2008 10:23:52 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 66FEB3A6807; Mon, 10 Mar 2008 10:22:50 -0700 (PDT) Received: from [192.168.50.87] (64-199-205-2.ip.mcleodusa.net [64.199.205.2]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m2AHKQSw013267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Mar 2008 10:20:28 -0700 (PDT) Message-ID: <47D56DD6.5060009@eecs.berkeley.edu> Date: Mon, 10 Mar 2008 10:20:22 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Pieter De Mil References: <200803021021.10955.coflynn@newae.com> <001e01c87fd4$7264c4a0$8300a8c0@priveiqvfluhp9> <47D2F21A.7080309@eecs.berkeley.edu> <31227.76.160.222.32.1205108691.squirrel@webserver6.intec.ugent.be> In-Reply-To: <31227.76.160.222.32.1205108691.squirrel@webserver6.intec.ugent.be> Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] Syncronized Wake 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 responses inline Pieter De Mil wrote: > Hi Kris, All; > > Thanks for the info, the ISA100.11a MAC seems to be a very flexible MAC > layer. > There is some concern about it being too flexible :) > Some questions inline. > > >> Pieter, Collin: >> the ISA100.11a MAC is based on TSMP (http://en.wikipedia.org/wiki/TSMP), >> > although it's been made very general because of political requirements in > getting the .11 group off the ground. So it's actually possible to > configure it to be pure scheduled unicast channel-hopping TDMA, pure > single-channel CSMA, or anything in between. > >> One likely operating mode would look something like this (this is >> > basically what Wireless HART does): > >> * 10ms slot length. Single packet sent and acknowledged in a single >> > slot. Most scheduled slots would be unicast for "upstream" data > collection. Some scheduled slots would be broadcast for downstream > communication. Some might be shared bandwidth (slotted aloha). > >> Scheduled slots repeat in one or more superframes, similar to but far >> > more flexible than the 15.4 GTS mechanism. > > > Do you mean that the same scheduled slot "No 1" (assuming 1000 slots in 1 > superframe) can be configured as "upstream" at time0 and as "broasdcast > for downstream" at time0+10s? > > There are 16 cells in slot 0 that can be assigned independently without RF collision and without consideration of spatial frequency re-use. So you could have several unicast cells (A --> B) and several broadcast cells (Q --> *), and several aloha cells (* --> *), and still have some cells left to assign. All of these cells would fire every 10 seconds in a 1000 slot superframe, as you indicated. But a given cell would not change from superframe cycle to superframe cycle. (note that the actual channel used for each cell will hop pseudo-randomly - the cell gives the channel offset, not the absolute channel). > > >> * +/- 1ms guard time at the beginning of the slot to allow for >> synchronization errors. Depending on the temperature range and the >> > quality of the time-keeping at each mote, this leads to a > >> synchronization requirement of between 10 seconds and a minute. Motes >> > keep track of their last synchronization (optionally on a path-by-path > basis) and send a keepalive packet if their synch timer expires. Every > acknowledged packet carries time information in both directions, so they > reset the synchronization timer. > > > Can you disable this extra time information for some ack packets? > > hmm. Good question. You can disable the timer for certain paths (if you want to enforce regular updates between one pair of motes and not another). But I don't think that you can ignore the time update in the ack. What's the use case? > > >> For many/most motes in many/all >> networks there is no need for additional synchronization traffic above >> > and beyond normal data traffic. For low traffic networks, beaconing may > be used if it makes more sense energetically than keepalives. > > > Can you have a beacon-enabled ISA100.11a MAC? > I've read you can assign the communication cells > centrally/distributed/hybrid. Is this scheduling algorithm defined for > beacons in low traffic networks? Or is this out of scope of the standard > spec? > You can certainly distribute time via beacons if you want. If I don't hear your beacon a few times in a row, and my keepalive timer goes off, I would still send you a keepalive packet. The cell scheduling mechanism is out of scope, but assumed to be centralized in the first release of both wireless HART and forthcoming isa100. > > > >> For >> 802.15.4 radios, the overhead for maintaining +/-1ms synchronization >> > across the entire network is less than 0.01% radio duty cycle. > >> Since all motes share a common sense of time, they can pseudo-randomly >> > channel hop, dramatically reducing the chance of a link between two motes > "going down" due to external or multi-path interference. > > > Great! > > > > >> * Communication cells (={slot, channel_offset} pair) may be assigned by >> > some central manager, or via purely distributed algorithms, or some > combination of both. Enforcing unicast with no collisions, 1,600 cells > per second are available (100 slots/second * 16 channels). > >> Cells are collected into graphs. Graphs provide QoS to applications, >> > and can be turned on and off to dynamically vary power and performance > over many orders of magnitude in response to application requests. This > is where things get interesting with 6LoWPAN and RoLL. TSMP provides the > mechanisms to bind layer 4 quality of service to layer 3 routes and layer > 2 performance/power provisioning. This is critical in industrial > automation, and seems likely to be very useful in other applications as > well. I don't think that it violates anything that the IETF holds dear, > but I've been wrong about that before :) > > > :-) The need for an abstraction layer is clear, because some MAC layers do > not offer slots or synchronization. The routing layer has to know this. > > One option is defining a profile or information base that every MAC layer > (implementer) has to fill in. This profile must describe the MAC > capabilities (available channels, transmit power, synchronized, slotted, > slotlength,...). > > Someone has already started? > I don't think that anyone has started. Does that concept of a profile violate anything that ietf holds dear? ksjp > Pieter > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 10 11:06:45 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096653A6C0F; Mon, 10 Mar 2008 11:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.378 X-Spam-Level: X-Spam-Status: No, score=-100.378 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 H7CYPr-VGQk5; Mon, 10 Mar 2008 11:06:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2695528C2FF; Mon, 10 Mar 2008 11:06: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 2350528C367 for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 11:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 Cfd9UYpAxKzd for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 11:06:37 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 5006228C265 for <6lowpan@ietf.org>; Mon, 10 Mar 2008 11:06:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 5B139A920A for <6lowpan@ietf.org>; Mon, 10 Mar 2008 11:04:13 -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 R+2VTC2EBjVu for <6lowpan@ietf.org>; Mon, 10 Mar 2008 11:04:05 -0700 (PDT) Received: from [128.32.38.176] (dhcp-38-176.EECS.Berkeley.EDU [128.32.38.176]) by mail.sf.archrock.com (Postfix) with ESMTP id D5340A91FE for <6lowpan@ietf.org>; Mon, 10 Mar 2008 11:04:05 -0700 (PDT) Message-ID: <47D57813.10201@archrock.com> Date: Mon, 10 Mar 2008 11:04:03 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] New 6LoWPAN HC Draft Availble 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 6LoWPAN WG, There's a new draft available that specifies a new header compression format for 6LoWPAN networks. It's a follow-on to the HC1g draft. It also captures some of the discussion with Pascal last week. http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc-00.txt Read it over before the WG meeting if you get a chance. Provide comments or suggestions on the list. Thanks. -- Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 10 11:43:10 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246453A6C7D; Mon, 10 Mar 2008 11:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.58 X-Spam-Level: X-Spam-Status: No, score=-100.58 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 uLpMy7isLSbM; Mon, 10 Mar 2008 11:43:08 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42ED43A69BC; Mon, 10 Mar 2008 11:42:58 -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 86B6B3A690D for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 11:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 tF07PVi4r26l for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 11:42:56 -0700 (PDT) Received: from mama.tanu.org (w132233.ppp.asahi-net.or.jp [121.1.132.233]) by core3.amsl.com (Postfix) with ESMTP id D0DE728C1D5 for <6lowpan@ietf.org>; Mon, 10 Mar 2008 11:42:52 -0700 (PDT) Received: from shoichi.tanu.org (dhcp-34e9.ietf71.ietf.org [130.129.52.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTP id 189561A79AC; Tue, 11 Mar 2008 03:40:31 +0900 (JST) Message-ID: <47D5809A.7060108@tanu.org> Date: Tue, 11 Mar 2008 03:40:26 +0900 From: Shoichi Sakane User-Agent: Thunderbird 2.0.0.9 (X11/20080223) MIME-Version: 1.0 To: Daniel Park References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------020508050207080902090009" Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Security analysis 02 version is now available 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --------------020508050207080902090009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel, > Your comments are highly welcome... > http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-security-analysis-02.txt In section 7.2: >>Thei fact that IPsec additionally requires another header (AH or ESP) >>in every packet, thus increasing per-packet header overhead, makes its >>use problematic in 6lowpan environments. I agree. Actually, ESP with AES-CCM requires additional 32 bytes. It is considerable. I attached my response to your analysis draft-01. There was an analysis of the overhead. However, the security overhead of the packet size depends on the 6lowpan application. It might be drastically decreased. In section 8.1: >>Such a scheme is not suitable for sensor networks because there >>is usually no guarantee of communicating seamlessly with a trusted >>server at all the times in sensor networks. I disagree with this statement. I don't think a trusted third party model is not suitable to all sensor networks. Certainly, there might not be assurance to connect to the centralized server in several sensor networks. But it is true that some sensor networks are designed to be sure to connect to the server, e.g. typical industrial wireless networks like WiHART and ISA100. In this section, I think that it is enough to describe benefits and issues of each mechanism. No need to say which mechanism is good nor others are bad. Security is highly considerable issue in the wireless area. I believe that what mechanism is the best depends on application. Regards, -- Shoichi Sakane Yokogawa Electric Corporation --------------020508050207080902090009 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message" Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: sakane@tanu.org Delivered-To: sakane@tanu.org Received: by mama.tanu.org (Postfix, from userid 1003) id 98CF61A7C58; Wed, 8 Nov 2006 19:25:52 +0900 (JST) Received: from megatron.ietf.org (megatron.ietf.ORG [156.154.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTP id D5A901A7C47 for ; Wed, 8 Nov 2006 19:25:51 +0900 (JST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhkcT-0005Dz-B1; Wed, 08 Nov 2006 05:25:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhkcS-0005DE-3a for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 05:25:20 -0500 Received: from w132233.ppp.asahi-net.or.jp ([121.1.132.233] helo=mama.tanu.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhkW1-0007Rg-A5 for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 05:18:42 -0500 Received: from [192.168.21.125] (72-34-69-70.skyriver.net [72.34.69.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTP id A259C1A7C47 for <6lowpan@lists.ietf.org>; Wed, 8 Nov 2006 19:18:36 +0900 (JST) Message-ID: <4551AEEF.5000308@tanu.org> Date: Wed, 08 Nov 2006 19:18:23 +0900 From: Shoichi Sakane User-Agent: Mail/News 1.5.0.2 (X11/20060428) MIME-Version: 1.0 To: 6lowpan@lists.ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Subject: [6lowpan] comment about 6lowpan-security-analysis X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi all, # If you get double mails from me, I am sorry that it was my fault. # I sent the first mail from my wrong address, so it stacked at the # owner of this list. I read draft-daniel-6lowpan-security-analysis-01.txt. I believe that this activity is valuable to clarify the security problem for 6LoWPAN. I thank the authors. I would like to cooperate with the work as much as I can. At first, I have some comments in the section 7.2. >> Basically, IPsec targets to general IP nodes operated over ethernet. It seems questionable. I believe that it does not assume always using over ethernet. >> It means each node has some of fluent stack size, bandwidth and non- >> low cost limitations like 6lowpan. IPsec basically is based on symmetric cryptography. This sentence is only correct for some key mangement protocols to establish the keys, like IKE. I believe that KINK is suitable in term of power consumption. Bandwidth consumption was not considered in both cases. >> Given the IPsec background, it is at least not suitable for 6lowpan >> nodes. Especially, 6lowpan node may not be able to operate all IPsec >> algorithms on its own capability either FFD or RFD. It is not needed to support all of likely algorithms of IPsec. Algorithm to be implemented for interoperability can be reduced according to RFC4305. And RFC4309 defines how to use AES-CCM with IPsec so that a stack size might be reduced because IEEE 802.15.4 does include AEC-CCM. >> Bandwidth is very sensitive element in the 6lowpan, but IPsec >> generates some of redundant packets such as AH/ESP header. RFC4301 defined that AH is no longer mandated to implement. I believe that we use just ESP to protect from almost 6LoWPAN threats. However it is needed to investigate each threat if we do not need AH. If we need ESP with AES-CCM, the packet size increases 32 bytes. 4 bytes for SPI. 4 bytes for sequence number as no ESN. 8 bytes for IV. 6 bytes for padding in minimum. 1 bytes for pad length. 1 bytes for next header. 8 bytes for ICV. Multiple security association between a 6lowpan node and different end points make packet sizes increase. However I do not think such usage is not suitable for a 6lowpan node. such usage is not realistic even for a full function devices like PC. >> IPsec needs shared secret key between nodes called IKE (Internet Key >> Exchange), and it will make the key exchange in secrecy possible. It >> can, however cause some of redundant packets over the 6lowpan >> networks. Need a minor fix. IKE is a protocol to establish such keys securely, not secret keys. And packets for key exchange is not redundant. They are obviously necessary to establish keys even if any method except manual keying are applied. However, for low computaional power devices, IKE requires much power to process asymmetric cryptography. Indeed, a certain algorithm like ECC or XTR can save power. But it might not be still suitable for a 6lowpan devices. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --------------020508050207080902090009 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 --------------020508050207080902090009-- From 6lowpan-bounces@ietf.org Mon Mar 10 13:09:45 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBAE13A6C4F; Mon, 10 Mar 2008 13:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.963 X-Spam-Level: X-Spam-Status: No, score=-100.963 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Pii0XO9gM1em; Mon, 10 Mar 2008 13:09:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1CFA3A6AB4; Mon, 10 Mar 2008 13:09: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 ACD053A690E for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 13:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 Mf7nB6aikg9X for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 13:09:42 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id 40BBC3A6833 for <6lowpan@ietf.org>; Mon, 10 Mar 2008 13:09:42 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so607238and.122 for <6lowpan@ietf.org>; Mon, 10 Mar 2008 13:07:21 -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=JjsJBeSleTqdQh9XnNNVpKYjt9ioWxIepaTPbAlvWUE=; b=QG0MyOPQK4KJMo0/d0Dl6dQSalaDgzzkrGaxkzDOajvWWCnDLQG+Ca/zvpxCSo32nIXzoB7YvmXKSegEQvakijuvyziZeKqWLK8kXSV+44FjFj006qjDmM4LrTBqsz2Mqc3Fs9wDg4HOmg5lFpzj7NjpQkUzEe1o6pFpVlnurCY= 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=Lqihx8b9Qd7iq4VFZDRgsF4DIaK4Z2h0xtMCRRHAP8BkOFi44o2mHzFtASXhx+79tJ894OuGkGDQaHKAif5c3SktjMIkWDRKr67gDbtxOSIZp84AkumvsAtDYwZwZsuoSwL69O1MkXZtDZaUEXmSNBwLO6IaCIcgLbO4oTqSfyE= Received: by 10.100.232.13 with SMTP id e13mr11674519anh.26.1205179641686; Mon, 10 Mar 2008 13:07:21 -0700 (PDT) Received: by 10.100.215.8 with HTTP; Mon, 10 Mar 2008 13:07:21 -0700 (PDT) Message-ID: Date: Tue, 11 Mar 2008 05:07:21 +0900 From: "Daniel Park" To: "Shoichi Sakane" In-Reply-To: <47D5809A.7060108@tanu.org> MIME-Version: 1.0 Content-Disposition: inline References: <47D5809A.7060108@tanu.org> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Security analysis 02 version is now available 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 Thanks your comments, On Tue, Mar 11, 2008 at 3:40 AM, Shoichi Sakane wrote: > Hi Daniel, > > > Your comments are highly welcome... > > http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-security-analysis-02.txt > > In section 7.2: > >>Thei fact that IPsec additionally requires another header (AH or ESP) > >>in every packet, thus increasing per-packet header overhead, makes its > >>use problematic in 6lowpan environments. > > I agree. Actually, ESP with AES-CCM requires additional 32 bytes. > It is considerable. I attached my response to your analysis draft-01. > There was an analysis of the overhead. > > However, the security overhead of the packet size depends on the 6lowpan > application. It might be drastically decreased. > > In section 8.1: > >>Such a scheme is not suitable for sensor networks because there > >>is usually no guarantee of communicating seamlessly with a trusted > >>server at all the times in sensor networks. > > I disagree with this statement. I don't think a trusted third party > model is not suitable to all sensor networks. Certainly, there might > not be assurance to connect to the centralized server in several sensor > networks. But it is true that some sensor networks are designed to > be sure to connect to the server, e.g. typical industrial wireless > networks like WiHART and ISA100. > > In this section, I think that it is enough to describe benefits and > issues of each mechanism. No need to say which mechanism is good > nor others are bad. > > Security is highly considerable issue in the wireless area. > I believe that what mechanism is the best depends on application. That's why we are now focusing on security analysis not proposing solution itself. Can you elaborate on any examples of 6lowpan security applications ? > -- > Shoichi Sakane > Yokogawa Electric Corporation > > > ---------- Forwarded message ---------- > From: Shoichi Sakane > To: 6lowpan@lists.ietf.org > Date: Wed, 08 Nov 2006 19:18:23 +0900 > Subject: [6lowpan] comment about 6lowpan-security-analysis > Hi all, > > # If you get double mails from me, I am sorry that it was my fault. > # I sent the first mail from my wrong address, so it stacked at the > # owner of this list. > > I read draft-daniel-6lowpan-security-analysis-01.txt. I believe that > this activity is valuable to clarify the security problem for 6LoWPAN. > I thank the authors. I would like to cooperate with the work as much as > I can. At first, I have some comments in the section 7.2. > > >> Basically, IPsec targets to general IP nodes operated over ethernet. > > It seems questionable. I believe that it does not assume always using > over ethernet. > > >> It means each node has some of fluent stack size, bandwidth and non- > >> low cost limitations like 6lowpan. > > IPsec basically is based on symmetric cryptography. This sentence is > only correct for some key mangement protocols to establish the keys, > like IKE. I believe that KINK is suitable in term of power consumption. > Bandwidth consumption was not considered in both cases. > > >> Given the IPsec background, it is at least not suitable for 6lowpan > >> nodes. Especially, 6lowpan node may not be able to operate all IPsec > >> algorithms on its own capability either FFD or RFD. > > It is not needed to support all of likely algorithms of IPsec. Algorithm > to be implemented for interoperability can be reduced according to RFC4305. > And RFC4309 defines how to use AES-CCM with IPsec so that a stack size might > be reduced because IEEE 802.15.4 does include AEC-CCM. > > >> Bandwidth is very sensitive element in the 6lowpan, but IPsec > >> generates some of redundant packets such as AH/ESP header. > > RFC4301 defined that AH is no longer mandated to implement. > I believe that we use just ESP to protect from almost 6LoWPAN threats. > However it is needed to investigate each threat if we do not need AH. > If we need ESP with AES-CCM, the packet size increases 32 bytes. > 4 bytes for SPI. > 4 bytes for sequence number as no ESN. > 8 bytes for IV. > 6 bytes for padding in minimum. > 1 bytes for pad length. > 1 bytes for next header. > 8 bytes for ICV. > > Multiple security association between a 6lowpan node and different end > points make packet sizes increase. However I do not think such usage > is not suitable for a 6lowpan node. such usage is not realistic even > for a full function devices like PC. > > >> IPsec needs shared secret key between nodes called IKE (Internet Key > >> Exchange), and it will make the key exchange in secrecy possible. It > >> can, however cause some of redundant packets over the 6lowpan > >> networks. > > Need a minor fix. IKE is a protocol to establish such keys securely, > not secret keys. > > And packets for key exchange is not redundant. They are obviously necessary > to establish keys even if any method except manual keying are applied. > However, for low computaional power devices, IKE requires much power to > process asymmetric cryptography. Indeed, a certain algorithm like ECC or > XTR can save power. But it might not be still suitable for a 6lowpan devices. > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 10 15:29:12 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF60528C3AD; Mon, 10 Mar 2008 15:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 5EGK7VjrlCvR; Mon, 10 Mar 2008 15:29:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC143A6BDF; Mon, 10 Mar 2008 15:29: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 97CA33A6BF7 for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 15:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 xWt6dKfH4QZi for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 15:29:09 -0700 (PDT) Received: from smtpout.eastlink.ca (smtpout.eastlink.ca [24.222.0.30]) by core3.amsl.com (Postfix) with ESMTP id 8E1F73A68D5 for <6lowpan@ietf.org>; Mon, 10 Mar 2008 15:29:08 -0700 (PDT) Received: from ip01.eastlink.ca ([24.222.39.10]) by mta02.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JXJ00832D0BH5W0@mta02.eastlink.ca> for 6lowpan@ietf.org; Mon, 10 Mar 2008 19:26:35 -0300 (ADT) Received: from blk-89-207-57.eastlink.ca (HELO [192.168.0.112]) ([24.89.207.57]) by ip01.eastlink.ca with ESMTP; Mon, 10 Mar 2008 19:21:45 -0300 Date: Mon, 10 Mar 2008 19:25:43 -0300 From: Colin O'Flynn In-reply-to: <47D56DD6.5060009@eecs.berkeley.edu> To: 6lowpan@ietf.org Message-id: <200803101925.43852.coflynn@newae.com> Organization: NewAE MIME-version: 1.0 Content-disposition: inline X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkBAJJS1UcYWc85/2dsb2JhbAAIkkWYMA X-IronPort-AV: E=Sophos;i="4.25,476,1199678400"; d="scan'208";a="341694294" References: <200803021021.10955.coflynn@newae.com> <31227.76.160.222.32.1205108691.squirrel@webserver6.intec.ugent.be> <47D56DD6.5060009@eecs.berkeley.edu> User-Agent: KMail/1.9.6 (enterprise 0.20071204.744707) Subject: Re: [6lowpan] Syncronized Wake 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, > There is some concern about it being too flexible :) I could see where that comes from. One presentation I found included lines such as: "Address needs of users ranging from unsophisticated to networking experts" "interoperability of ISA100 devices"..."Standardize the necessary interfaces while leaving other aspects for vendor customization" Which - well it sounds good, but really too good for me to trust ;-) However the ISA100 looks like it could be quite useful, from what I can read of it. However is the ISA100.11a around somewhere? I couldn't seem to find the actual spec, and the link to 'Join Now' says that "As a token of your support, you are requested to make a one time financial donation of $10,000 to ISA.". A bit rich perhaps for me... Thanks! -Colin > > Some questions inline. > > > >> Pieter, Collin: > >> the ISA100.11a MAC is based on TSMP (http://en.wikipedia.org/wiki/TSMP), > > > > although it's been made very general because of political requirements in > > getting the .11 group off the ground. So it's actually possible to > > configure it to be pure scheduled unicast channel-hopping TDMA, pure > > single-channel CSMA, or anything in between. > > > >> One likely operating mode would look something like this (this is > > > > basically what Wireless HART does): > >> * 10ms slot length. Single packet sent and acknowledged in a single > > > > slot. Most scheduled slots would be unicast for "upstream" data > > collection. Some scheduled slots would be broadcast for downstream > > communication. Some might be shared bandwidth (slotted aloha). > > > >> Scheduled slots repeat in one or more superframes, similar to but far > > > > more flexible than the 15.4 GTS mechanism. > > > > > > Do you mean that the same scheduled slot "No 1" (assuming 1000 slots in 1 > > superframe) can be configured as "upstream" at time0 and as "broasdcast > > for downstream" at time0+10s? > > There are 16 cells in slot 0 that can be assigned independently without > RF collision and without consideration of spatial frequency re-use. So > you could have several unicast cells (A --> B) and several broadcast > cells (Q --> *), and several aloha cells (* --> *), and still have some > cells left to assign. All of these cells would fire every 10 seconds in > a 1000 slot superframe, as you indicated. But a given cell would not > change from superframe cycle to superframe cycle. (note that the actual > channel used for each cell will hop pseudo-randomly - the cell gives the > channel offset, not the absolute channel). > > >> * +/- 1ms guard time at the beginning of the slot to allow for > >> synchronization errors. Depending on the temperature range and the > > > > quality of the time-keeping at each mote, this leads to a > > > >> synchronization requirement of between 10 seconds and a minute. Motes > > > > keep track of their last synchronization (optionally on a path-by-path > > basis) and send a keepalive packet if their synch timer expires. Every > > acknowledged packet carries time information in both directions, so they > > reset the synchronization timer. > > > > > > Can you disable this extra time information for some ack packets? > > hmm. Good question. You can disable the timer for certain paths (if > you want to enforce regular updates between one pair of motes and not > another). But I don't think that you can ignore the time update in the > ack. What's the use case? > > >> For many/most motes in many/all > >> networks there is no need for additional synchronization traffic above > > > > and beyond normal data traffic. For low traffic networks, beaconing may > > be used if it makes more sense energetically than keepalives. > > > > > > Can you have a beacon-enabled ISA100.11a MAC? > > I've read you can assign the communication cells > > centrally/distributed/hybrid. Is this scheduling algorithm defined for > > beacons in low traffic networks? Or is this out of scope of the standard > > spec? > > You can certainly distribute time via beacons if you want. If I don't > hear your beacon a few times in a row, and my keepalive timer goes off, > I would still send you a keepalive packet. > The cell scheduling mechanism is out of scope, but assumed to be > centralized in the first release of both wireless HART and forthcoming > isa100. > > >> For > >> 802.15.4 radios, the overhead for maintaining +/-1ms synchronization > > > > across the entire network is less than 0.01% radio duty cycle. > > > >> Since all motes share a common sense of time, they can pseudo-randomly > > > > channel hop, dramatically reducing the chance of a link between two motes > > "going down" due to external or multi-path interference. > > > > > > Great! > > > >> * Communication cells (={slot, channel_offset} pair) may be assigned by > > > > some central manager, or via purely distributed algorithms, or some > > combination of both. Enforcing unicast with no collisions, 1,600 cells > > per second are available (100 slots/second * 16 channels). > > > >> Cells are collected into graphs. Graphs provide QoS to applications, > > > > and can be turned on and off to dynamically vary power and performance > > over many orders of magnitude in response to application requests. This > > is where things get interesting with 6LoWPAN and RoLL. TSMP provides the > > mechanisms to bind layer 4 quality of service to layer 3 routes and layer > > 2 performance/power provisioning. This is critical in industrial > > automation, and seems likely to be very useful in other applications as > > well. I don't think that it violates anything that the IETF holds dear, > > but I've been wrong about that before :) > > > > :-) The need for an abstraction layer is clear, because some MAC layers > > : do > > > > not offer slots or synchronization. The routing layer has to know this. > > > > One option is defining a profile or information base that every MAC layer > > (implementer) has to fill in. This profile must describe the MAC > > capabilities (available channels, transmit power, synchronized, slotted, > > slotlength,...). > > > > Someone has already started? > > I don't think that anyone has started. Does that concept of a profile > violate anything that ietf holds dear? > > ksjp > > > Pieter > > _______________________________________________ > 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 Mar 10 17:56:42 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D9A3A69E9; Mon, 10 Mar 2008 17:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.378 X-Spam-Level: X-Spam-Status: No, score=-100.378 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 uxVP0J8maQ8B; Mon, 10 Mar 2008 17:56:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 113343A67F3; Mon, 10 Mar 2008 17:56: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 8440C3A67F3 for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 17:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 IU+l7LaoQjV0 for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 17:56:39 -0700 (PDT) Received: from mail.nivis.com (mail.nivis.com [65.205.163.229]) by core3.amsl.com (Postfix) with SMTP id 5387F3A63CA for <6lowpan@ietf.org>; Mon, 10 Mar 2008 17:56:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 20:54:15 -0400 Message-ID: In-Reply-To: <47D05BA6.6050609@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HC1g and HC2g Thread-Index: Ach/zUVj+4j2pIQPS1O3TTF28s7RLQDROAig References: <7892795E1A87F04CADFCCF41FADD00FC054D7EA0@xmb-ams-337.emea.cisco.com> <47D05BA6.6050609@archrock.com> From: "Robert Assimiti" To: "Jonathan Hui" , "Pascal Thubert (pthubert)" Cc: Jay Werb , 6lowpan <6lowpan@ietf.org>, enns@stanfordalumni.org Subject: Re: [6lowpan] HC1g and HC2g 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-8859-1" Content-Transfer-Encoding: quoted-printable Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hello, For the newbies out here in 6LowPan land, what does HC1g refer to? I assume it is part of some current draft proposed within IETF. = Could you point me to the exact draft? Thks "The nice thing about standards is that there are so many to choose from." = - Andrew S. Tanenbaum = Robert Assimiti Executive Staff=A0Engineer Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] = Sent: Thursday, March 06, 2008 4:01 PM To: Pascal Thubert (pthubert) Cc: 6lowpan; Jay Werb; enns@stanfordalumni.org; Robert Assimiti Subject: Re: HC1g and HC2g Hi Pascal, -- Jonathan Hui Pascal Thubert (pthubert) wrote: > On the first hop, either the packet reaches onlink destination, or the > router that terminates the 6LoWPAN compression can use a default Hop > limit to forward to the world. On the last hop, whatever is is above 1 > is as good as 1 since you're done with L3. > = > So the rules can turn out to be: > = > - LoWPAN node that originates the packet can elide the Hop limit. > - router performing local delivery over the LoWPAN can elide the Hop > Limit > ; else the Hop limit MUST NOT be compressed > = > With that set of rules in place I think we're fine with one bit. There > are a number of assumptions behind about proxy and stubs, but I think > we're OK. Yup. The reason why I tied it to the eliding of L3 addresses is in the = case where each 15.4 node is doing L3 forwarding and modifying the Hop = Limit. I don't want a 15.4 node having to do a memmove() simply to = insert a Hop Limit when forwarding it to the next hop. But I am fine = with having a router that's forwarding to the outside world to eat this = cost. Maybe the rule should state if more than one IP hop is taken in = the PAN, then the Hop Limit must not be compressed. For the assumptions, yes, I'm continuing to assume that 15.4 nodes will = operate in stub networks. > I still like the idea to move the NH to HC2. Even if it is an IP header > field, it really talks about the HC2 content, and that balances the > preserved bits leaving flexibility in HC1G. I had originally proposed with HC1g to move HC2 after the compressed L3 = header. In this scenario, putting NH into HC2 doesn't work because the = position of HC2 depends on whether the Next Hop field appears in the = compressed L3 header or not. If you look at the IPv6 header = architecture, the Next Header field always describes what header is = coming next. So it's a pretty well understood concept. In the 6LoWPAN = adaptation layer, however, we did design it in the way you suggest. If we want flexibility in the HC1 header, I'd argue replacing VTF with a = bit that expands the HC1 header by another byte and put the VTF bit = there. I like reserving extra room in the HC2 header because I'd also = like to make provisions for using stateful compression of the UDP ports. -- Jonathan Hui > Pascal > = >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: jeudi 6 mars 2008 17:57 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan >> Subject: Re: HC1g and HC2g >> >> >> Hi Pascal, >> >> I think it's reasonable to incorporate some of your ideas into HC1g. > UDP >> checksums make sense. >> >> I also understand the motivation for eliding the Hop Limit field. But >> I'd like to find a way to make it only a single bit. The motivation for >> this is in the following paragraph. To me, eliding the Hop Limit field >> only makes sense when communicating over a single IP hop. How about a >> single bit states if the HLIM is elided or not, and can only be elided >> when one of the L3 addresses are completely elided. The latter >> restriction ensures that Hop Limit is only elided on the 6LoWPAN side >> for a single IP hop. Am I missing a case here? >> >> If we can remove one bit from HLIM, then I think we can move the NH >> field back into HC1. I would remove the L4C bit and say that if NH is >> non-zero, then HC2 must be included. I believe NH is still part of the >> L3 header, so it should remain in HC1. The S, D, L, and C fields in HC2 >> should remain there because they are UDP specific. Also, I was > proposing >> to move HC2 to the start of the L4 header and putting the NH field > there >> seems strange to me. >> >> What do you think? >> >> -- >> Jonathan Hui >> >> >> Pascal Thubert (pthubert) wrote: >>> Hi Jonathan: >>> >>> We've been discussing HC1g quite extensively. I'd wish to discuss >>> variations on your initial proposal: >>> >>> ------------------------------------------------------ >>> The LOWPAN_HC1g encoding as currently in the draft >>> >>> 0 1 2 3 4 5 6 7 >>> +---+---+---+---+---+---+---+---+ >>> | SC | DC |VTF| NH |L4C| >>> +---+---+---+---+---+---+---+---+ >>> >>> HC2g for UDP >>> >>> >>> 0 1 2 3 4 5 6 7 >>> +---+---+---+---+---+---+---+---+ >>> | S | D | L | reserved | >>> +---+---+---+---+---+---+---+---+ >>> >>> >>> ------------------------------------------------------ >>> >>> What seeems to be missing: >>> >>> - Hop limit compression (takes 2 bits) >>> - UDP checksum compression >>> >>> >>> My proposal includes to keep using the mesh header format for route > over >>> to carry the short addresses and hop limit. >>> >>> 0 1 2 3 4 5 6 7 >>> +---+---+---+---+---+---+---+---+ >>> | SC | DC |VTF| Hlim |L4C| >>> +---+---+---+---+---+---+---+---+ >>> >>> HLIM: >>> 00 not compressed >>> 01 placed in the mesh header to count PAN hops >>> 10 fully elided, packet generated inside the PAN >>> 11 fully elided, packet came in a stub >>> >>> >>> >>> HC2g for UDP >>> >>> >>> 0 1 2 3 4 5 6 7 >>> +---+---+---+---+---+---+---+---+ >>> | NH | S | D | L | C | rsvrd | >>> +---+---+---+---+---+---+---+---+ >>> >>> C: checksum is compressed. >>> >>> Note1: with that new format you need an HC2g to be able to compress > NH. >>> I do not mind. >>> Note2: if NH is 0 then the NH is placed after the HC2G as it is taken > as >>> an L4 parm not between HC1G and HC2G. The parsing of bits 2..7 > depends >>> on that NH. >>> >>> What do you think? >>> >>> Pascal This e-mail (including any attachments to it) is confidential, proprietary,= legally privileged, subject to copyright and is sent for the personal atte= ntion of the intended recipient only. If you have received this e-mail in e= rror, please reply to advise us immediately, delete it and destroy any prin= ted copies of it. You are notified that reading, disclosing, copying, distr= ibuting or taking any action in reliance on the contents of this informatio= n is strictly prohibited. No employee is authorized to conclude any binding= agreement on behalf of NIVIS LLC with another party by e-mail without expr= ess written confirmation by an officer of the company. Although we have tak= en reasonable precautions to ensure no viruses are present in this e-mail, = we cannot accept responsibility for any loss or damage arising from the vir= uses in this e-mail or attachments. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 10 18:33:15 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCB628C12F; Mon, 10 Mar 2008 18:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.918 X-Spam-Level: X-Spam-Status: No, score=-100.918 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Rq4Fn0ozf6tX; Mon, 10 Mar 2008 18:33:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752453A6891; Mon, 10 Mar 2008 18:33: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 881493A6891 for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 18:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 TBWiLTRbiS96 for <6lowpan@core3.amsl.com>; Mon, 10 Mar 2008 18:33:11 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 7AB943A63CA for <6lowpan@ietf.org>; Mon, 10 Mar 2008 18:33:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 7CF84A9286; Mon, 10 Mar 2008 18:30:51 -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 uT-vdGC8LnQK; Mon, 10 Mar 2008 18:30:44 -0700 (PDT) Received: from [192.168.1.110] (adsl-71-142-65-177.dsl.pltn13.pacbell.net [71.142.65.177]) by mail.sf.archrock.com (Postfix) with ESMTP id 54869A921E; Mon, 10 Mar 2008 18:30:44 -0700 (PDT) Message-ID: <47D5E0C1.6020709@archrock.com> Date: Mon, 10 Mar 2008 18:30:41 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Robert Assimiti References: <7892795E1A87F04CADFCCF41FADD00FC054D7EA0@xmb-ams-337.emea.cisco.com> <47D05BA6.6050609@archrock.com> In-Reply-To: Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] HC1g and HC2g 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 HC1g refers to a (now expired) draft that attempted to provide effective header compression for non-link-local communication. HC1g has been replaced with the 6lowpan-hc draft that I posted to the mailing list earlier today. -- Jonathan Hui Robert Assimiti wrote: > Hello, > > For the newbies out here in 6LowPan land, what does HC1g refer to? > > I assume it is part of some current draft proposed within IETF. > > Could you point me to the exact draft? > > Thks > > "The nice thing about standards is that there are so many to choose from." - Andrew S. Tanenbaum > Robert Assimiti > Executive Staff Engineer > Office: [678]-202-6859 > Mobile: [404]-578-0205 > robert.assimiti@nivis.com > > > -----Original Message----- > From: Jonathan Hui [mailto:jhui@archrock.com] > Sent: Thursday, March 06, 2008 4:01 PM > To: Pascal Thubert (pthubert) > Cc: 6lowpan; Jay Werb; enns@stanfordalumni.org; Robert Assimiti > Subject: Re: HC1g and HC2g > > > Hi Pascal, > > -- > Jonathan Hui > > > Pascal Thubert (pthubert) wrote: >> On the first hop, either the packet reaches onlink destination, or the >> router that terminates the 6LoWPAN compression can use a default Hop >> limit to forward to the world. On the last hop, whatever is is above 1 >> is as good as 1 since you're done with L3. >> >> So the rules can turn out to be: >> >> - LoWPAN node that originates the packet can elide the Hop limit. >> - router performing local delivery over the LoWPAN can elide the Hop >> Limit >> ; else the Hop limit MUST NOT be compressed >> >> With that set of rules in place I think we're fine with one bit. There >> are a number of assumptions behind about proxy and stubs, but I think >> we're OK. > > Yup. The reason why I tied it to the eliding of L3 addresses is in the > case where each 15.4 node is doing L3 forwarding and modifying the Hop > Limit. I don't want a 15.4 node having to do a memmove() simply to > insert a Hop Limit when forwarding it to the next hop. But I am fine > with having a router that's forwarding to the outside world to eat this > cost. Maybe the rule should state if more than one IP hop is taken in > the PAN, then the Hop Limit must not be compressed. > > For the assumptions, yes, I'm continuing to assume that 15.4 nodes will > operate in stub networks. > >> I still like the idea to move the NH to HC2. Even if it is an IP header >> field, it really talks about the HC2 content, and that balances the >> preserved bits leaving flexibility in HC1G. > > I had originally proposed with HC1g to move HC2 after the compressed L3 > header. In this scenario, putting NH into HC2 doesn't work because the > position of HC2 depends on whether the Next Hop field appears in the > compressed L3 header or not. If you look at the IPv6 header > architecture, the Next Header field always describes what header is > coming next. So it's a pretty well understood concept. In the 6LoWPAN > adaptation layer, however, we did design it in the way you suggest. > > If we want flexibility in the HC1 header, I'd argue replacing VTF with a > bit that expands the HC1 header by another byte and put the VTF bit > there. I like reserving extra room in the HC2 header because I'd also > like to make provisions for using stateful compression of the UDP ports. > > -- > Jonathan Hui > > >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: jeudi 6 mars 2008 17:57 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan >>> Subject: Re: HC1g and HC2g >>> >>> >>> Hi Pascal, >>> >>> I think it's reasonable to incorporate some of your ideas into HC1g. >> UDP >>> checksums make sense. >>> >>> I also understand the motivation for eliding the Hop Limit field. But >>> I'd like to find a way to make it only a single bit. The motivation for >>> this is in the following paragraph. To me, eliding the Hop Limit field >>> only makes sense when communicating over a single IP hop. How about a >>> single bit states if the HLIM is elided or not, and can only be elided >>> when one of the L3 addresses are completely elided. The latter >>> restriction ensures that Hop Limit is only elided on the 6LoWPAN side >>> for a single IP hop. Am I missing a case here? >>> >>> If we can remove one bit from HLIM, then I think we can move the NH >>> field back into HC1. I would remove the L4C bit and say that if NH is >>> non-zero, then HC2 must be included. I believe NH is still part of the >>> L3 header, so it should remain in HC1. The S, D, L, and C fields in HC2 >>> should remain there because they are UDP specific. Also, I was >> proposing >>> to move HC2 to the start of the L4 header and putting the NH field >> there >>> seems strange to me. >>> >>> What do you think? >>> >>> -- >>> Jonathan Hui >>> >>> >>> Pascal Thubert (pthubert) wrote: >>>> Hi Jonathan: >>>> >>>> We've been discussing HC1g quite extensively. I'd wish to discuss >>>> variations on your initial proposal: >>>> >>>> ------------------------------------------------------ >>>> The LOWPAN_HC1g encoding as currently in the draft >>>> >>>> 0 1 2 3 4 5 6 7 >>>> +---+---+---+---+---+---+---+---+ >>>> | SC | DC |VTF| NH |L4C| >>>> +---+---+---+---+---+---+---+---+ >>>> >>>> HC2g for UDP >>>> >>>> >>>> 0 1 2 3 4 5 6 7 >>>> +---+---+---+---+---+---+---+---+ >>>> | S | D | L | reserved | >>>> +---+---+---+---+---+---+---+---+ >>>> >>>> >>>> ------------------------------------------------------ >>>> >>>> What seeems to be missing: >>>> >>>> - Hop limit compression (takes 2 bits) >>>> - UDP checksum compression >>>> >>>> >>>> My proposal includes to keep using the mesh header format for route >> over >>>> to carry the short addresses and hop limit. >>>> >>>> 0 1 2 3 4 5 6 7 >>>> +---+---+---+---+---+---+---+---+ >>>> | SC | DC |VTF| Hlim |L4C| >>>> +---+---+---+---+---+---+---+---+ >>>> >>>> HLIM: >>>> 00 not compressed >>>> 01 placed in the mesh header to count PAN hops >>>> 10 fully elided, packet generated inside the PAN >>>> 11 fully elided, packet came in a stub >>>> >>>> >>>> >>>> HC2g for UDP >>>> >>>> >>>> 0 1 2 3 4 5 6 7 >>>> +---+---+---+---+---+---+---+---+ >>>> | NH | S | D | L | C | rsvrd | >>>> +---+---+---+---+---+---+---+---+ >>>> >>>> C: checksum is compressed. >>>> >>>> Note1: with that new format you need an HC2g to be able to compress >> NH. >>>> I do not mind. >>>> Note2: if NH is 0 then the NH is placed after the HC2G as it is taken >> as >>>> an L4 parm not between HC1G and HC2G. The parsing of bits 2..7 >> depends >>>> on that NH. >>>> >>>> What do you think? >>>> >>>> Pascal > > > This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 10 20:26:30 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B902A3A6B08; Mon, 10 Mar 2008 20:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.033 X-Spam-Level: X-Spam-Status: No, score=-100.033 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 UDq1M-pp7Lig; Mon, 10 Mar 2008 20:26:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2DE33A6A39; Mon, 10 Mar 2008 20:26:29 -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 3A7373A6A39; Mon, 10 Mar 2008 20:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 gTTSpPk4NtzP; Mon, 10 Mar 2008 20:26:28 -0700 (PDT) Received: from cypress.ugent.be (cypress.ugent.be [157.193.71.48]) by core3.amsl.com (Postfix) with ESMTP id 19A8A3A67FC; Mon, 10 Mar 2008 20:26:27 -0700 (PDT) Received: from gorilla.ugent.be (HELO localhost) ([157.193.49.20]) by cypress.ugent.be with ESMTP; 11 Mar 2008 04:24:07 +0100 Received: from cypress.ugent.be ([157.193.71.48]) by localhost (gorilla.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 06489-09-3; Tue, 11 Mar 2008 04:24:07 +0100 (CET) Received: from mail4.intec.ugent.be ([157.193.214.4]) by cypress.ugent.be with ESMTP; 11 Mar 2008 04:24:07 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMeX1UedwdYE/2dsb2JhbACrKQ Received: from localhost (localhost [127.0.0.1]) by mail4.intec.ugent.be (Postfix) with ESMTP id 2F1B340B2BB; Tue, 11 Mar 2008 04:23:57 +0100 (CET) Received: from mail4.intec.ugent.be ([127.0.0.1]) by localhost (mail4.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEPCCzsJ6GEr; Tue, 11 Mar 2008 04:23:57 +0100 (CET) Received: from webserver6.intec.ugent.be (webserver6.intec.ugent.be [157.193.214.11]) by mail4.intec.ugent.be (Postfix) with ESMTP id 0386140B2BA; Tue, 11 Mar 2008 04:23:56 +0100 (CET) Received: from 76.160.222.32 (SquirrelMail authenticated user pdemil) by webserver6.intec.ugent.be with HTTP; Tue, 11 Mar 2008 04:24:07 +0100 (CET) Message-ID: <56871.76.160.222.32.1205205847.squirrel@webserver6.intec.ugent.be> In-Reply-To: <47D56DD6.5060009@eecs.berkeley.edu> References: <200803021021.10955.coflynn@newae.com> <001e01c87fd4$7264c4a0$8300a8c0@priveiqvfluhp9> <47D2F21A.7080309@eecs.berkeley.edu> <31227.76.160.222.32.1205108691.squirrel@webserver6.intec.ugent.be> <47D56DD6.5060009@eecs.berkeley.edu> Date: Tue, 11 Mar 2008 04:24:07 +0100 (CET) From: "Pieter De Mil" To: "Kris Pister" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by UGent DICT Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] Syncronized Wake 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 >> Can you disable this extra time information for some ack packets? >> > hmm. Good question. You can disable the timer for certain paths (if > you want to enforce regular updates between one pair of motes and not > another). But I don't think that you can ignore the time update in the > ack. What's the use case? In a network with a lot of traffic, I can imagine that this time information in the ack's is not always necessary for the motes to stay synchronized. It is necessary sometimes, but not for all successive acks. Disabling this time information in the ack = saving battery juice. To keep things simple, it may be OK to keep the time info always in the ack. I was just wondering if the DLL was *that* flexible :-) Pieter _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 11 04:56:03 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60D83A6DB8; Tue, 11 Mar 2008 04:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.492 X-Spam-Level: X-Spam-Status: No, score=-100.492 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 9e-QA+0gTrpK; Tue, 11 Mar 2008 04:56:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10EF03A6A5B; Tue, 11 Mar 2008 04:56: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 50B853A6882 for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 04:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 7T3s9ckHn9zB for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 04:56:01 -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 D894528C34D for <6lowpan@ietf.org>; Tue, 11 Mar 2008 04:56:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,480,1199660400"; d="scan'208";a="3115615" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Mar 2008 12:53:32 +0100 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 m2BBrVPj021001; Tue, 11 Mar 2008 12:53:31 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m2BBrVHC001606; Tue, 11 Mar 2008 11:53:31 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, 11 Mar 2008 12:53:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Mar 2008 12:53:02 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05539302@xmb-ams-337.emea.cisco.com> In-Reply-To: <47D57813.10201@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New 6LoWPAN HC Draft Availble thread-index: AciC2Zs406q3hThiTUuwMSzVunpMkgAk1EWw From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 11 Mar 2008 11:53:31.0101 (UTC) FILETIME=[86C8D8D0:01C8836E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1576; t=1205236411; x=1206100411; 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]=20New=206LoWPAN=20HC=20Draft= 20Availble |Sender:=20; bh=+TApIvlFw5IXl1pFdSh+gSBknU1behL3kbdZ4gtF+qw=; b=JbFBeasDsYNVaBTcv2/UV7K+4+Oa6iqF0TlCtptORP/ZxV8+4B5BAklu0L Kw2q81eIoMAn/BEekn2by2UhTLYT3Ixa2qkSy1OluiYTlyjlnHA8fzfe6IYZ ZtoyGdUR1p; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [6lowpan] New 6LoWPAN HC Draft Availble 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: Thanks a lot for this excellent draft. From the standpoint of ISA100.11a, it is going a long way in the right direction. I think it is actually ripe for election as WG document and you've got my vote for it. This is hardly surprising considering your earlier work on RFC 4944 and HC1G. I'll provide my detailed comments separately; the substance, though, is that: - we need to refine the Hop limit text as you point out - we should be able to extend the concept of common prefix compress global addresses that result from states without being specific on how the addresses are passed on, which I understand is another charter item. - I'm still interesting in compressing the HCs, but that can be done separately. Thanks again, Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: lundi 10 mars 2008 19:04 >To: 6lowpan >Subject: [6lowpan] New 6LoWPAN HC Draft Availble > > >6LoWPAN WG, > >There's a new draft available that specifies a new header compression >format for 6LoWPAN networks. It's a follow-on to the HC1g draft. It also >captures some of the discussion with Pascal last week. > >http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc-00.txt > >Read it over before the WG meeting if you get a chance. Provide comments >or suggestions on the list. > >Thanks. > >-- >Jonathan Hui >_______________________________________________ >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 Mar 11 05:05:43 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416A328C38D; Tue, 11 Mar 2008 05:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.609 X-Spam-Level: X-Spam-Status: No, score=-101.609 tagged_above=-999 required=5 tests=[AWL=-1.172, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 ta03mHOa1Hlo; Tue, 11 Mar 2008 05:05:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F0328C1D4; Tue, 11 Mar 2008 05:05: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 AC3AC3A6AE2 for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 05:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 xxywHZYYYm9g for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 05:05:33 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 847D03A6AE5 for <6lowpan@ietf.org>; Tue, 11 Mar 2008 05:05:33 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 Mar 2008 05:03:14 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2BC3C7u020025; Tue, 11 Mar 2008 05:03:12 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2BC3CLh007266; Tue, 11 Mar 2008 12:03:12 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 05:03:11 -0700 Received: from dhcp-159f.ietf71.ietf.org ([10.21.144.87]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 05:03:10 -0700 Message-ID: <47D674FC.4010601@cisco.com> Date: Tue, 11 Mar 2008 08:03:08 -0400 From: Mark Townsley User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: 6lowpan@ietf.org, 6lowpan-chairs@tools.ietf.org, roll-chairs@tools.ietf.org X-OriginalArrivalTime: 11 Mar 2008 12:03:10.0726 (UTC) FILETIME=[E0449A60:01C8836F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=416; t=1205236992; x=1206100992; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Missing=20your=20meeting=20today |Sender:=20; bh=a5CrAFr6RnC5ThAE3q3v+/N0+qVWerTqk9m3pQWtRQg=; b=ujVCJXpm/KPmjTQe9RlW2H4MVFT2jA5xDKW7H/rnQdEPj4EW4M2kkM3F1E 27NLAqa8ZTbTvpmqEM///VSFt7KxUlSQ8EUXUI4gF4gYKJzchFlxN8LihLGw 98PMVoTtVg; Authentication-Results: sj-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [6lowpan] Missing your meeting today 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 Apologizes to all... I will likely miss most of your meeting today due to scheduling conflicts. I understand that we need to get your recharter finished up and approved. No need to dwell on that today during your meeting time. Most important I believe is to advance on your deliverables, and ensure that the division of labor between 6lowpan and the new roll WG is well understood by all. - Mark _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 11 05:30:28 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2677F28C379; Tue, 11 Mar 2008 05:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.378 X-Spam-Level: X-Spam-Status: No, score=-100.378 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 zT5kQKRm13g0; Tue, 11 Mar 2008 05:30:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43AA23A69C7; Tue, 11 Mar 2008 05:30:27 -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 7CAA23A67AC for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 05:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 l+0g-WDWgjGI for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 05:30:25 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id B76523A69C7 for <6lowpan@ietf.org>; Tue, 11 Mar 2008 05:30:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 25695A92F7; Tue, 11 Mar 2008 05:28: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 4Ic-lFRrVBtv; Tue, 11 Mar 2008 05:28:00 -0700 (PDT) Received: from [130.129.22.182] (dhcp-16b6.ietf71.ietf.org [130.129.22.182]) by mail.sf.archrock.com (Postfix) with ESMTP id 0EE91A92F6; Tue, 11 Mar 2008 05:27:59 -0700 (PDT) Message-ID: <47D67AC4.2080701@archrock.com> Date: Tue, 11 Mar 2008 05:27:48 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC05539302@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05539302@xmb-ams-337.emea.cisco.com> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New 6LoWPAN HC Draft Availble 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 Pascal, Pascal Thubert (pthubert) wrote: > Hi Jonathan: > > Thanks a lot for this excellent draft. From the standpoint of > ISA100.11a, it is going a long way in the right direction. I think it is > actually ripe for election as WG document and you've got my vote for it. > This is hardly surprising considering your earlier work on RFC 4944 and > HC1G. Thanks. > I'll provide my detailed comments separately; the substance, though, is > that: > - we need to refine the Hop limit text as you point out After some discussion with Carsten, it seems that we may need both bits for Hop Limit compression. Current idea now is that 1-bit indicates compression, another bit indicates whether the elided Hop Limit is 63 or 1. I originally thought we could do egress filtering based on the destination address, but Carsten thought that it missed the point of the Hop Limit. The cost is we utilize the reserved bit in the IPHC encoding and remove any flexibility it could have provided. > - we should be able to extend the concept of common prefix compress > global addresses that result from states without being specific on how > the addresses are passed on, which I understand is another charter item. Right. > - I'm still interesting in compressing the HCs, but that can be done > separately. Sure. Thanks. -- Jonathan Hui > > Thanks again, > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jonathan Hui >> Sent: lundi 10 mars 2008 19:04 >> To: 6lowpan >> Subject: [6lowpan] New 6LoWPAN HC Draft Availble >> >> >> 6LoWPAN WG, >> >> There's a new draft available that specifies a new header compression >> format for 6LoWPAN networks. It's a follow-on to the HC1g draft. It > also >> captures some of the discussion with Pascal last week. >> >> http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc-00.txt >> >> Read it over before the WG meeting if you get a chance. Provide > comments >> or suggestions on the list. >> >> Thanks. >> >> -- >> Jonathan Hui >> _______________________________________________ >> 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 Mar 11 06:34:26 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF6328C42E; Tue, 11 Mar 2008 06:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.334 X-Spam-Level: X-Spam-Status: No, score=-100.334 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 RfTwvxEGWU3b; Tue, 11 Mar 2008 06:34:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7606628C3FC; Tue, 11 Mar 2008 06:34: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 CC7A328C404 for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 06:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 7K-yc6OLgjtl for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 06:34:19 -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 2824628C40C for <6lowpan@ietf.org>; Tue, 11 Mar 2008 06:34:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,480,1199660400"; d="scan'208";a="3129478" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Mar 2008 14:31:56 +0100 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 m2BDVukH029177; Tue, 11 Mar 2008 14:31:56 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m2BDVuHC012524; Tue, 11 Mar 2008 13:31:56 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, 11 Mar 2008 14:31:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Mar 2008 14:31:24 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC055393E9@xmb-ams-337.emea.cisco.com> In-Reply-To: <47D67AC4.2080701@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New HC Draft: 2 bits for Hop Limit thread-index: AciDc2vVXujW3bMUQJ2nPS1OorhsDwABHmWQ From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 11 Mar 2008 13:31:55.0954 (UTC) FILETIME=[4659E920:01C8837C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3740; t=1205242316; x=1206106316; 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:=20New=20HC=20Draft=3A=202=20bits=20for=20Hop=20Li mit |Sender:=20; bh=qs4KJbTlGWFphoDLoGSdwNBfPSoJVPEfC9ovXsQpMwk=; b=KOMQV4CUNZ7/GdR9i9GzCy++DtYJwK7wtASgRbBRVlPszqTmtFXiGBz2Uh CT5cVzadN0YXBLHH4mjAtQQ5rhlHKAe8uTSnhYAvpjRaBLkjH/ddv0hPa2uZ ncWR85ImI7; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] New HC Draft: 2 bits for Hop Limit 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: >After some discussion with Carsten, it seems that we may need both bits >for Hop Limit compression. Current idea now is that 1-bit indicates >compression, another bit indicates whether the elided Hop Limit is 63 or >1. I originally thought we could do egress filtering based on the >destination address, but Carsten thought that it missed the point of the >Hop Limit. The cost is we utilize the reserved bit in the IPHC encoding >and remove any flexibility it could have provided. You know I started exactly like Carsten. In the thread with you, we discussed that the router that performs a local delivery could elide the Hop limit without the additional bit because it expects that the packet will never appear at L3 again. There are a number of caveats to that approach, including proxy, and indirection. So I do feel safer if we stick to the 2 bits. This might look expensive but if we do the fast path HC3 that we discussed already, then the first bit will be easily defaulted due to the assumption that the LoWPAN is a stub, so the fast path clearly compresses the hop limit. So I'm all for the proposed change. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mardi 11 mars 2008 13:28 >To: Pascal Thubert (pthubert) >Cc: 6lowpan >Subject: Re: [6lowpan] New 6LoWPAN HC Draft Availble > > >Hi Pascal, > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >> Thanks a lot for this excellent draft. From the standpoint of >> ISA100.11a, it is going a long way in the right direction. I think it is >> actually ripe for election as WG document and you've got my vote for it. >> This is hardly surprising considering your earlier work on RFC 4944 and >> HC1G. > >Thanks. > >> I'll provide my detailed comments separately; the substance, though, is >> that: >> - we need to refine the Hop limit text as you point out > >After some discussion with Carsten, it seems that we may need both bits >for Hop Limit compression. Current idea now is that 1-bit indicates >compression, another bit indicates whether the elided Hop Limit is 63 or >1. I originally thought we could do egress filtering based on the >destination address, but Carsten thought that it missed the point of the >Hop Limit. The cost is we utilize the reserved bit in the IPHC encoding >and remove any flexibility it could have provided. > >> - we should be able to extend the concept of common prefix compress >> global addresses that result from states without being specific on how >> the addresses are passed on, which I understand is another charter item. > >Right. > >> - I'm still interesting in compressing the HCs, but that can be done >> separately. > >Sure. > >Thanks. > >-- >Jonathan Hui > >> >> Thanks again, >> >> Pascal >> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Jonathan Hui >>> Sent: lundi 10 mars 2008 19:04 >>> To: 6lowpan >>> Subject: [6lowpan] New 6LoWPAN HC Draft Availble >>> >>> >>> 6LoWPAN WG, >>> >>> There's a new draft available that specifies a new header compression >>> format for 6LoWPAN networks. It's a follow-on to the HC1g draft. It >> also >>> captures some of the discussion with Pascal last week. >>> >>> http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc-00.txt >>> >>> Read it over before the WG meeting if you get a chance. Provide >> comments >>> or suggestions on the list. >>> >>> Thanks. >>> >>> -- >>> Jonathan Hui >>> _______________________________________________ >>> 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 Mar 11 07:54:09 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CBA13A6D6D; Tue, 11 Mar 2008 07:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.473 X-Spam-Level: X-Spam-Status: No, score=-100.473 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 6bPc7slcUD1V; Tue, 11 Mar 2008 07:54:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B184D28C50F; Tue, 11 Mar 2008 07:53: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 596BF28C3F1 for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 07:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 MYjTIwY1x+qt for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 07:52:58 -0700 (PDT) Received: from mama.tanu.org (w132233.ppp.asahi-net.or.jp [121.1.132.233]) by core3.amsl.com (Postfix) with ESMTP id E246328C52A for <6lowpan@ietf.org>; Tue, 11 Mar 2008 07:50:28 -0700 (PDT) Received: from shoichi.tanu.org (dhcp-17da.ietf71.ietf.org [130.129.23.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTP id 63E311A7B34; Tue, 11 Mar 2008 23:48:08 +0900 (JST) Message-ID: <47D69BA1.2030803@tanu.org> Date: Tue, 11 Mar 2008 23:48:01 +0900 From: Shoichi Sakane User-Agent: Thunderbird 2.0.0.9 (X11/20080223) MIME-Version: 1.0 To: Daniel Park References: <47D5809A.7060108@tanu.org> In-Reply-To: Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Security analysis 02 version is now available 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, I probably misread. If the goal of the document is to describe that the current upper layer security mechanism is too heavy to realize the 6lowpan security network, that is O.K. to me. my concern at the meeting is that which mechanism we can use to realize the 6lowpan security when an application needs certain security. and the application needs inter-communication with the Internet. we have to consider any security mechanism in the upper layer of the 6lowpan. again, if the devices in the 6lowpan network need to securely communicate with the devices at the Internet, a secure layer is required upon the 6lowpan layer. ipsec could be the layer. but ipsec is not always required because there is other security layer like TLS which is most useful currently. but overhead of TLS is much bigger than ipsec. >>> http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-security-analysis-02.txt >> In section 7.2: >> >>Thei fact that IPsec additionally requires another header (AH or ESP) >> >>in every packet, thus increasing per-packet header overhead, makes its >> >>use problematic in 6lowpan environments. >> I agree. Actually, ESP with AES-CCM requires additional 32 bytes. >> It is considerable. I attached my response to your analysis draft-01. >> There was an analysis of the overhead. >> >> However, the security overhead of the packet size depends on the 6lowpan >> application. It might be drastically decreased. we could define a transform which is less packet size than the transforms which had been standardized already so that the overhead of the packet could be half. but it maybe still considerable size. >> Security is highly considerable issue in the wireless area. >> I believe that what mechanism is the best depends on application. > > That's why we are now focusing on security analysis not proposing > solution itself. Can you elaborate on any examples of 6lowpan security > applications ? well, SP100 could be one of the application. but the specification assumed presence of the key management under the 6lowpan. regards, _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 11 08:49:30 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681E73A6E1F; Tue, 11 Mar 2008 08:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.304 X-Spam-Level: X-Spam-Status: No, score=-100.304 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 nvKa2MuthA8u; Tue, 11 Mar 2008 08:49:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CAC93A6DD8; Tue, 11 Mar 2008 08:49:29 -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 324BD3A698C for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 08:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 bHgY6W+zZtTf for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 08:49:27 -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 90BE33A6E00 for <6lowpan@ietf.org>; Tue, 11 Mar 2008 08:49:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,480,1199660400"; d="scan'208";a="3150221" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Mar 2008 16:47:06 +0100 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 m2BFl6oQ009490; Tue, 11 Mar 2008 16:47:06 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m2BFl5vB013200; Tue, 11 Mar 2008 15:47:06 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); Tue, 11 Mar 2008 16:47:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Mar 2008 16:46:26 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05539509@xmb-ams-337.emea.cisco.com> In-Reply-To: <47D67AC4.2080701@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New 6LoWPAN HC Draft Availble thread-index: AciDc2vVXujW3bMUQJ2nPS1OorhsDwAC7OZQ From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 11 Mar 2008 15:47:05.0920 (UTC) FILETIME=[28448400:01C8838F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4827; t=1205250426; x=1206114426; 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]=20New=206LoWPAN=20HC=20Draft= 20Availble |Sender:=20; bh=OOb7wjak5NSFPTgHx2fvtX26kK3ad9q1Z0bTD/fVyFc=; b=isN6IYPJigv6uDL9lrDlGVRHVkuHTqr3E+Sc71wrQmy6k7UsHmroMsuOkK eBRu3tWJ+Z5TyuFzyaHFXnD75DLr2YoQENShB2xfierzz5wQygfgUK2JycCb yF44Sm4NWZ; 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] New 6LoWPAN HC Draft Availble 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: >> - we should be able to extend the concept of common prefix compress >> global addresses that result from states without being specific on how >> the addresses are passed on, which I understand is another charter item. > >Right. Let me propose some text then. I feel that a limited change in section 2.2 should do the trick: Before " IPv6 unicast addresses may be compressed to 64, 16, or 0 bits. When an IPv6 unicast address is compressed, the elided bits are implicitly the Common Prefix (CP). The CP can either be the link-local prefix or Common Routable Prefix (CRP). The 6LoWPAN dispatch value identifies which CP is being used. A 6LoWPAN dispatch value of 0x03 (TBD) indicates a LOWPAN_IPHC compressed IPv6 header and the CP is the link-local prefix. A 6LoWPAN dispatch value of 0x04 (TBD) indicates a LOWPAN_IPHC compressed IPv6 header and the CP is the Common Routable Prefix. The Common Routable Prefix may be obtained with IPv6 Stateless Address Autoconfiguration when autoconfiguring an address[RFC4862]. Other mechanisms for obtaining the CRP or selecting a CRP among two or more routable prefixes are out of scope of this document. " What about " IPv6 unicast addresses may be compressed to 64, 16, or 0 bits. A 6LoWPAN dispatch value of 0x03 indicates that the compressed Address is a link local address whereas a 6LoWPAN dispatch value of 0x04 (TBD) indicates a wider scope, for instance a Unique Local Address or a Global Unicast address. In the latter case, it is expected that the IPv6 address can be unambiguously inferred from the information in the packet and states present in the LoWPAN node. For instance, if the address is compressed to 64 bits, then the prefix is elided and it is expected that there is a Common Routable Prefix that can unambiguously be determined to recover the complete address. The Common Routable Prefix may be obtained with IPv6 Stateless Address Autoconfiguration when autoconfiguring an address[RFC4862]. Other mechanisms for obtaining the elided information are out of scope of this document. " Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mardi 11 mars 2008 13:28 >To: Pascal Thubert (pthubert) >Cc: 6lowpan >Subject: Re: [6lowpan] New 6LoWPAN HC Draft Availble > > >Hi Pascal, > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >> Thanks a lot for this excellent draft. From the standpoint of >> ISA100.11a, it is going a long way in the right direction. I think it is >> actually ripe for election as WG document and you've got my vote for it. >> This is hardly surprising considering your earlier work on RFC 4944 and >> HC1G. > >Thanks. > >> I'll provide my detailed comments separately; the substance, though, is >> that: >> - we need to refine the Hop limit text as you point out > >After some discussion with Carsten, it seems that we may need both bits >for Hop Limit compression. Current idea now is that 1-bit indicates >compression, another bit indicates whether the elided Hop Limit is 63 or >1. I originally thought we could do egress filtering based on the >destination address, but Carsten thought that it missed the point of the >Hop Limit. The cost is we utilize the reserved bit in the IPHC encoding >and remove any flexibility it could have provided. > >> - we should be able to extend the concept of common prefix compress >> global addresses that result from states without being specific on how >> the addresses are passed on, which I understand is another charter item. > >Right. > >> - I'm still interesting in compressing the HCs, but that can be done >> separately. > >Sure. > >Thanks. > >-- >Jonathan Hui > >> >> Thanks again, >> >> Pascal >> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Jonathan Hui >>> Sent: lundi 10 mars 2008 19:04 >>> To: 6lowpan >>> Subject: [6lowpan] New 6LoWPAN HC Draft Availble >>> >>> >>> 6LoWPAN WG, >>> >>> There's a new draft available that specifies a new header compression >>> format for 6LoWPAN networks. It's a follow-on to the HC1g draft. It >> also >>> captures some of the discussion with Pascal last week. >>> >>> http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc-00.txt >>> >>> Read it over before the WG meeting if you get a chance. Provide >> comments >>> or suggestions on the list. >>> >>> Thanks. >>> >>> -- >>> Jonathan Hui >>> _______________________________________________ >>> 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 Mar 11 08:58:34 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358833A689C; Tue, 11 Mar 2008 08:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.64 X-Spam-Level: X-Spam-Status: No, score=-100.64 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 WzWrxF8TcgzR; Tue, 11 Mar 2008 08:58:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D4C3A69C0; Tue, 11 Mar 2008 08:58: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 4E9323A689C for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 08:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 LU2CfKFdWu2g for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 08:58:28 -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 29F4B3A6DA5 for <6lowpan@ietf.org>; Tue, 11 Mar 2008 08:58:27 -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.0/8.14.0) with ESMTP id m2BFtmpa027399; Tue, 11 Mar 2008 16:55:48 +0100 (CET) Message-Id: <9C9F8945-9866-4905-A659-86AB485B3376@tzi.org> From: Carsten Bormann To: Jonathan Hui In-Reply-To: <47D67AC4.2080701@archrock.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 11 Mar 2008 11:55:48 -0400 References: <7892795E1A87F04CADFCCF41FADD00FC05539302@xmb-ams-337.emea.cisco.com> <47D67AC4.2080701@archrock.com> X-Mailer: Apple Mail (2.919.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New 6LoWPAN HC Draft Availble 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 On Mar 11 2008, at 08:27, Jonathan Hui wrote: > The cost is we utilize the reserved bit in the IPHC encoding > and remove any flexibility it could have provided. We still have 1/2 bit (we use only 3 out of 4 bit combinations). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 11 09:45:44 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72C728C43B; Tue, 11 Mar 2008 09:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.591 X-Spam-Level: X-Spam-Status: No, score=-100.591 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 mLRroAAcqnuV; Tue, 11 Mar 2008 09:45:43 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5143128C3ED; Tue, 11 Mar 2008 09:45: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 909D53A6E50 for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 09:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ShdxSd8zUZLv for <6lowpan@core3.amsl.com>; Tue, 11 Mar 2008 09:45:41 -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 0A8E93A6860 for <6lowpan@ietf.org>; Tue, 11 Mar 2008 09:45:40 -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.0/8.14.0) with ESMTP id m2BGh43C006008; Tue, 11 Mar 2008 17:43:12 +0100 (CET) Message-Id: <6E53130E-6802-4870-BD7A-481E01D74A16@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 11 Mar 2008 12:43:03 -0400 X-Mailer: Apple Mail (2.919.2) Cc: Carsten Bormann Subject: [6lowpan] WG meeting at IETF71 is done 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 Lowpanners, I have put a quick (personal view) summary up at http:// 6lowpan.tzi.org -- will expand this as minutes become available. Thanks to all presenters and commenters. There is a lot of work ahead, but there also is a lot of high-quality input, so the next months should be very interesting. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 13 08:44:33 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799C428C854; Thu, 13 Mar 2008 08:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.46 X-Spam-Level: X-Spam-Status: No, score=-100.46 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 WVII1aqx-zBY; Thu, 13 Mar 2008 08:44:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9835828C873; Thu, 13 Mar 2008 08:44: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 0667C28C70C; Thu, 13 Mar 2008 08:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ybznTYZCbWvY; Thu, 13 Mar 2008 08:44:14 -0700 (PDT) Received: from mail.nivis.com (mail.nivis.com [65.205.163.229]) by core3.amsl.com (Postfix) with SMTP id D0CD028C240; Thu, 13 Mar 2008 08:43:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Mar 2008 11:40:52 -0400 Message-ID: In-Reply-To: <56871.76.160.222.32.1205205847.squirrel@webserver6.intec.ugent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Syncronized Wake Thread-Index: AciDJ2Cd0aW2nfL5SrmhMlfzwPpfvwB9Be2A References: <200803021021.10955.coflynn@newae.com><001e01c87fd4$7264c4a0$8300a8c0@priveiqvfluhp9><47D2F21A.7080309@eecs.berkeley.edu><31227.76.160.222.32.1205108691.squirrel@webserver6.intec.ugent.be><47D56DD6.5060009@eecs.berkeley.edu> <56871.76.160.222.32.1205205847.squirrel@webserver6.intec.ugent.be> From: "Robert Assimiti" To: "Pieter De Mil" , "Kris Pister" Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] Syncronized Wake 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="===============1822961994==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1822961994== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88520.A2393EE6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C88520.A2393EE6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Pieter, =20 Yes, the DLL is that flexible....and more. =20 Minimizing battery consumption was one of the primary design constraints for the DLL. =20 Time corrections can be accomplished in two ways: =20 1. Through ACK=20 a. Time corrections can be enabled/disabled in the ACK b. Other fun data can be enabled/disabled in the ACK such as LQI/RSSI data or the EUI-64 of the receiving device =20 2. Through advertisement headers =20 =20 =20 "The nice thing about standards is that there are so many to choose from." - Andrew S. Tanenbaum=20 Robert Assimiti Executive Staff Engineer Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com =20 =20 -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Pieter De Mil Sent: Monday, March 10, 2008 11:24 PM To: Kris Pister Cc: roll@ietf.org; 6lowpan@ietf.org Subject: Re: [6lowpan] Syncronized Wake =20 =20 >> Can you disable this extra time information for some ack packets? >>=20 > hmm. Good question. You can disable the timer for certain paths (if > you want to enforce regular updates between one pair of motes and not > another). But I don't think that you can ignore the time update in the > ack. What's the use case? =20 =20 In a network with a lot of traffic, I can imagine that this time information in the ack's is not always necessary for the motes to stay synchronized. It is necessary sometimes, but not for all successive acks. Disabling this time information in the ack =3D saving battery juice. To keep things simple, it may be OK to keep the time info always in the ack. I was just wondering if the DLL was *that* flexible :-) =20 Pieter _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan This e-mail (including any attachments to it) is confidential, proprietar= y, legally privileged, subject to copyright and is sent for the personal = attention of the intended recipient only. If you have received this e-mai= l in error, please reply to advise us immediately, delete it and destroy = any printed copies of it. You are notified that reading, disclosing, copy= ing, distributing or taking any action in reliance on the contents of thi= s information is strictly prohibited. No employee is authorized to conclu= de any binding agreement on behalf of NIVIS LLC with another party by e-m= ail without express written confirmation by an officer of the company. Al= though we have taken reasonable precautions to ensure no viruses are pres= ent in this e-mail, we cannot accept responsibility for any loss or damag= e arising from the viruses in this e-mail or attachments. ------_=_NextPart_001_01C88520.A2393EE6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Pieter,

=

 

Yes, the DLL is that flexible....and more.

 

Minimizing battery consumption was one of the primary design constraints for the DLL= =2E

 

Time corrections can be accomplished in two ways:

=

 

1.  Through ACK

a.&nb= sp; Time corrections can be enabled/disabled in the ACK

b.&nb= sp; Other fun data can be enabled/disabled in the ACK such as LQI/RSSI data or the = EUI-64 of the receiving device

 

2.  Through advertisement header= s

 

 

 

"The nice thing about standards is that there are so many to choose from."= ; - Andrew S. Tanenbaum

Robert Assimiti

Executive Staff Engineer

Office: [678]-202-6859

Mobile: [404]-578-0205

robert.assimiti@nivis.com

 

 

-----Original Message-----
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behal= f Of Pieter De Mil
Sent: Monday, March 10, 2008 11:24 PM
To: Kris Pister
Cc: roll@ietf.org; 6lowpan@ietf.org
Subject: Re: [6lowpan] Syncronized Wake

 

 

>> Can you disable this extra time information for some ack packets?

>> 

> hmm.  Good question.  You can disable the timer for certain pat= hs (if

> you want to enforce regular updates between one pair of motes and not

> another).  But I don't think that you can ignore the time update in = the

> ack.  What's the use case?

 

 

In a network with a lot of traffic, I can imagine that this time<= /span>

information in the ack's is not always necessary for the motes to stay

synchronized. It is necessary sometimes, but not for all successive acks.

Disabling this time information  in the ack =3D saving battery juice.

To keep things simple, it may be OK to keep the time info always in the=

ack. I was just wondering if the DLL was *that* flexible :-)=

 

Pieter

_______________________________________________=

6lowpan mailing list

6lowpan@ietf.org

https://www.ietf.org/mailman/listinfo/6lowpan



This e-mail (including any attachments to it) is confidential, pr= oprietary, legally privileged, subject to copyright and is sent for the p= ersonal attention of the intended recipient only. If you have received th= is e-mail in error, please reply to advise us immediately, delete it and = destroy any printed copies of it. You are notified that reading, disclosi= ng, copying, distributing or taking any action in reliance on the content= s of this information is strictly prohibited. No employee is authorized t= o conclude any binding agreement on behalf of NIVIS LLC with another part= y by e-mail without express written confirmation by an officer of the com= pany. Although we have taken reasonable precautions to ensure no viruses = are present in this e-mail, we cannot accept responsibility for any loss = or damage arising from the viruses in this e-mail or attachments. ------_=_NextPart_001_01C88520.A2393EE6-- --===============1822961994== 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 --===============1822961994==-- From 6lowpan-bounces@ietf.org Mon Mar 17 07:47:02 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A513A6B36; Mon, 17 Mar 2008 07:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.634 X-Spam-Level: X-Spam-Status: No, score=-100.634 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 gMc7QAKke4BV; Mon, 17 Mar 2008 07:46:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03CF28C3F9; Mon, 17 Mar 2008 07:46:58 -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 750F528C38F for <6lowpan@core3.amsl.com>; Mon, 17 Mar 2008 07:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 lrRKOZRCM4Nf for <6lowpan@core3.amsl.com>; Mon, 17 Mar 2008 07:46:53 -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 000B128C3F2 for <6lowpan@ietf.org>; Mon, 17 Mar 2008 07:46:52 -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 m2HEiRdM005034; Mon, 17 Mar 2008 15:44:27 +0100 (CET) Message-Id: From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 17 Mar 2008 15:44:27 +0100 X-Mailer: Apple Mail (2.919.2) Cc: Carsten Bormann Subject: [6lowpan] Issue of the week: Security 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 Lowpanners, as we discussed in Philadelphia, we need to make progress on our new charter items. A very important work item that will influence most of the others is the security model. First of all, there is the Internet-Draft draft-daniel-6lowpan-security-analysis-02.txt, which in particular describes the threats a 6lowpan is subjected to and various existing specifications that may aid us in countering them. In Philadelphia, I said that I would like to see one more round of this document as an individual contribution and then ask the WG to decide to take it on as a WG document for charter item 5. In addition to the existing authors, Shoichi Sakane and Robert Moskowitz have volunteered to take an active role in this. To obtain more input to this document, I would like the mailing list to discuss four aspects of 6lowpan security this week: 1) end-to-end security. I have heard a lot of people saying IKE is too heavy for a 6lowpan node; but there has been little evidence that ESP can't be made to work. What would be the right ciphersuite (and how can we trade off security with our strict packet size requirements)? What is the field of application (i.e., where would even ESP be too heavy)? What key management solutions make sense here instead of IKE? 2) where even ESP is too heavy for a node, a border device on the 6lowpan might act as a proxy, doing the heavy lifting. This might mean that we use existing AES-CCM on-chip hardware for the intra-lowpan hop(s), and encapsulate in ESP on the proxy border device (just as a VPN gateway would do). Note that none of this is application-specific, but we still need to understand how to split the work between the low-capability end node and the security proxy. (The security proxy might even speak IKE, making this solution more compatible to today's security gateways in der Internet.) What key management solutions work right in this three-party system? 3) how do we protect the network? ND, routing/meshing, and multicasting need availability protection beyond the end-to-end integrity/confidentiality that ESP can afford. In particular, we need to protect the batteries of the devices. From simple group keying solutions to GDOI (see MSEC WG and KMART BOF the previous week), a lot of alternatives are out there. What role does the AES-CCM hardware play here? What key management solutions work to protect ND and routing/meshing? How much battery protection can we achieve? 4) how do the various forms of key management interface to commissioning? Commissioning (i.e., the process of "making friends" as opposed to the process of "finding the friends" and building the network that we call bootstrapping) will be a process that involves user interfaces, special buttons on devices, bar code labels, serial/USB/NFC communication -- clearly mostly outside of the scope of the communication standards, but with much influence on interoperability. When replying to this message, please indicate which of the four items above (or anything else that I forgot) you are addressing. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 18 09:56:49 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEEDE3A69FB; Tue, 18 Mar 2008 09:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Z4CiKUN2dRYX; Tue, 18 Mar 2008 09:56:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53EF83A6F35; Tue, 18 Mar 2008 09:56: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 C54B228C48C for <6lowpan@core3.amsl.com>; Tue, 18 Mar 2008 09:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 QcMhvNOop6I2 for <6lowpan@core3.amsl.com>; Tue, 18 Mar 2008 09:55:51 -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 A50233A6D90 for <6lowpan@ietf.org>; Tue, 18 Mar 2008 09:55:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,519,1199660400"; d="scan'208";a="3850918" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2008 17:53:32 +0100 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 m2IGrW2W011366 for <6lowpan@ietf.org>; Tue, 18 Mar 2008 17:53:32 +0100 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 m2IGrW7S007301 for <6lowpan@ietf.org>; Tue, 18 Mar 2008 16:53:32 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); Tue, 18 Mar 2008 17:53:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Mar 2008 17:53:02 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0558DCDD@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "cry out loud" vs. "white board" thread-index: AciJGHr+D1UqKfllT7+CFV1nm3Ltqg== From: "Pascal Thubert (pthubert)" To: "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 18 Mar 2008 16:53:32.0510 (UTC) FILETIME=[995A1FE0:01C88918] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2159; t=1205859212; x=1206723212; 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:=20=22cry=20out=20loud=22=20vs.=20=22white=20board =22 |Sender:=20; bh=nZj8x3AdysJy/+6KnGytemVAKffhiwNlHBP2m+LCenc=; b=kovnLxeznpGW6nnwJkFaTcwUqoEBedp1Q+ICC8c4rAokhrwJkqN5WtIoCc ccDt8dvXc0xQUQn5cJ0HDUD6+8jxkwlqSf6ChXZDk2vMPDobYBm9cufAP4kg ZT0oLpt+KS; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [6lowpan] "cry out loud" vs. "white board" 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: Neighbor Discovery is traditionally implemented over multicast. And multicast is more often than not implemented over a plain mac level broadcast. This is the "cry out loud" paradigm, perfectly suited for Ethernet, and totally unsuited for LowPANs. draft-chakrabarti-6lowpan-ipv6-nd makes a great point on explaining the steps that this takes and the associated cost. I think that this part of the document has already most of the attributes to be turned into a ND problem statement WG doc for 6LoWPAN. What I disagree with is the approach to solve the problem by patching optimizations all over the process. We have to face that the result is still not acceptable and that the whole paradigm should be revised for the LowPAN. In a memory constrained device, implementing MLDv2 is huge overkill, even if its use can be reduced in runtime by refined optimizations. In a same fashion, relying on mesh-under multicast support is unrealistic. At the other end of the routing spectrum from the "cry out loud" paradigm, the "white board" model proposes a solution where one node acts as a reference for all the others. With that model, every node claims an address by writing on the white board and looks up an address by reading from the white board. DAD is a lookup / commit collapsed in a single NS flow. All NS/NA become unicast activity, no MLD, dead simple. And RAs are broadcast. The catch is obviously that the white board is not a fully distributed model. Is that even acceptable? If we consider that LowPANs usually have a sink of some sort, probably a higher-power never-sleeping router, then it makes a lot of sense to use that special node for placing the function. So why not? I tried to capture this idea in http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. On top of the white board, the draft adds the capability for the white board to act as a ND proxy and extend the LoWPAN across an IP backbone and potentially scale the PAN into a very large link. Note that the draft was renamed from LoWPAN to 6lowpan but the content is unchanged. So, what do you think? Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 18 10:08:35 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431C928C675; Tue, 18 Mar 2008 10:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 dtKWXOtAJmla; Tue, 18 Mar 2008 10:08:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC0028C6D6; Tue, 18 Mar 2008 10:08: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 586313A683E for <6lowpan@core3.amsl.com>; Tue, 18 Mar 2008 10:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 cZXtD-yp-BKt for <6lowpan@core3.amsl.com>; Tue, 18 Mar 2008 10:08:18 -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 4166828C675 for <6lowpan@ietf.org>; Tue, 18 Mar 2008 10:08:06 -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 m2IH5cCN014586; Tue, 18 Mar 2008 18:05:38 +0100 (CET) Message-Id: <83EB1976-51E8-43DA-8D5A-062AF3C8BA84@tzi.org> From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0558DCDD@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 18 Mar 2008 18:05:37 +0100 References: <7892795E1A87F04CADFCCF41FADD00FC0558DCDD@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "cry out loud" vs. "white board" 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, the security properties of the ND protocol are well understood, so that SEND was developed to improve them. What would be a good security model for the "white board" approach? Could a "white board" in turn be useful for coordinating security? How to get rid of the single point of failure? Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 18 10:20:01 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A38928C48C; Tue, 18 Mar 2008 10:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.951 X-Spam-Level: X-Spam-Status: No, score=-100.951 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 mxQPNuHuFjXW; Tue, 18 Mar 2008 10:19:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044BE3A6900; Tue, 18 Mar 2008 10:19:58 -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 BFDE728C453 for <6lowpan@core3.amsl.com>; Tue, 18 Mar 2008 10:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 GfjDGhcRHPSd for <6lowpan@core3.amsl.com>; Tue, 18 Mar 2008 10:19:55 -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 576D13A68FC for <6lowpan@ietf.org>; Tue, 18 Mar 2008 10:19:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,519,1199660400"; d="scan'208";a="3853643" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2008 18:17:37 +0100 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 m2IHHbli018608; Tue, 18 Mar 2008 18:17:37 +0100 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 m2IHHbnN016501; Tue, 18 Mar 2008 17:17:37 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); Tue, 18 Mar 2008 18:17:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Mar 2008 18:17:05 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0558DCFF@xmb-ams-337.emea.cisco.com> In-Reply-To: <83EB1976-51E8-43DA-8D5A-062AF3C8BA84@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] "cry out loud" vs. "white board" thread-index: AciJGlQuLD7ioYUeRS+OTVfLSpa2UQAAATow From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 18 Mar 2008 17:17:37.0416 (UTC) FILETIME=[F6954880:01C8891B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1675; t=1205860657; x=1206724657; 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=22cry=20out=20loud=22=20vs .=20=22white=20board=22 |Sender:=20; bh=VzsEhNeHC88+3D2qHd4FVrKt5AJhSCpSoTLQe4bdHAE=; b=rMOhFZ1jfx+rWDxdyLyyLBi2CmdpefQu6YcoNgybcaGYJize8wo7aA6fPP 1Q/DX4T2lHgyftQ+xRk3W9H62xIr1v7Ek4y/HdMArSpCkyb5Zcs2IJBVpVE0 pexV5p1zEx; 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] "cry out loud" vs. "white board" 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 Carsten: Many good points: 1) current SeND is not compatible with the RFC 4944 compression 2) current SeND is unrealistic on motes, mostly due to the CPU cost of computing a CGA address But since the cga address is computed based on the public key it would be possible for the white board could do the CGA work as part of the registration process. 3) with white board, NA is proxied. So a proxy SeND is required, as documented in http://tools.ietf.org/html/rfc4389 http://tools.ietf.org/html/draft-daley-send-spnd-prob-02 RFC still in the oven but work exists: http://tools.ietf.org/html/draft-krishnan-cgaext-proxy-send-00 4) Could a "white board" in turn be useful for coordinating security? You need to answer that one. There are certainly interesting properties there. 5) How to get rid of the single point of failure? This is usually left to vendors, HSRP, VRRP or else. Note that the BbR is not on the way for intra LoWPAN data exchange, just lookup. It can die and restart but it's better if it can persist the caches. What do you think? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: mardi 18 mars 2008 18:06 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; 6lowpan >Subject: Re: [6lowpan] "cry out loud" vs. "white board" > >Pascal, > >the security properties of the ND protocol are well understood, so >that SEND was developed to improve them. >What would be a good security model for the "white board" approach? >Could a "white board" in turn be useful for coordinating security? >How to get rid of the single point of failure? > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Mar 19 16:50:17 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43BE3A6E79; Wed, 19 Mar 2008 16:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 sNRAGBTYcVRy; Wed, 19 Mar 2008 16:50:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C949C3A6D90; Wed, 19 Mar 2008 16:50: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 02FF83A69F4 for <6lowpan@core3.amsl.com>; Wed, 19 Mar 2008 16:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 7aplc9VfNXAr for <6lowpan@core3.amsl.com>; Wed, 19 Mar 2008 16:50:15 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 1E2203A6A79 for <6lowpan@ietf.org>; Wed, 19 Mar 2008 16:50:15 -0700 (PDT) Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.106]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1Jc80j-0007ib-M0; Wed, 19 Mar 2008 16:47:58 -0700 Message-ID: <47E1B5FC.3080805@cs.stanford.edu> Date: Wed, 19 Mar 2008 16:55:24 -0800 From: Philip Levis User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC0558DCDD@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0558DCDD@xmb-ams-337.emea.cisco.com> X-Scan-Signature: 1c1d34d4ae2aac1d1f929c6f17b0cb0c Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "cry out loud" vs. "white board" 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 Thubert (pthubert) wrote: > Hi: > > Neighbor Discovery is traditionally implemented over multicast. And > multicast is more often than not implemented over a plain mac level > broadcast. This is the "cry out loud" paradigm, perfectly suited for > Ethernet, and totally unsuited for LowPANs. > > draft-chakrabarti-6lowpan-ipv6-nd makes a great point on explaining the > steps that this takes and the associated cost. I think that this part of > the document has already most of the attributes to be turned into a ND > problem statement WG doc for 6LoWPAN. > > What I disagree with is the approach to solve the problem by patching > optimizations all over the process. We have to face that the result is > still not acceptable and that the whole paradigm should be revised for > the LowPAN. In a memory constrained device, implementing MLDv2 is huge > overkill, even if its use can be reduced in runtime by refined > optimizations. In a same fashion, relying on mesh-under multicast > support is unrealistic. > > At the other end of the routing spectrum from the "cry out loud" > paradigm, the "white board" model proposes a solution where one node > acts as a reference for all the others. With that model, every node > claims an address by writing on the white board and looks up an address > by reading from the white board. DAD is a lookup / commit collapsed in a > single NS flow. All NS/NA become unicast activity, no MLD, dead simple. > And RAs are broadcast. > > The catch is obviously that the white board is not a fully distributed > model. Is that even acceptable? If we consider that LowPANs usually have > a sink of some sort, probably a higher-power never-sleeping router, then > it makes a lot of sense to use that special node for placing the > function. So why not? > > I tried to capture this idea in > http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. On top > of the white board, the draft adds the capability for the white board to > act as a ND proxy and extend the LoWPAN across an IP backbone and > potentially scale the PAN into a very large link. > > Note that the draft was renamed from LoWPAN to 6lowpan but the content > is unchanged. > > So, what do you think? > I think the idea of a whiteboard is powerful. It definitely makes more sense than "shout out." I am leery of the requirement that there be a single coordinating node, however. Your text puts it precisely: "consider that LowPANs *usually* have a sink of some sort" (emphasis mine). Forcing this to be centralized requires such a node exist and therefore precludes certain kinds of LowPANs. That being said, this approach seems to implicitly assume mesh under? Nodes "use Neighbor Discovery to determine the link-layer addresses for neighbors known to reside on attached links and to quickly purge cached values that become invalid." ND could operate on a single hop basis. This simplifies everything. The place where the whiteboard approach is necessary is for DAD. But given that the goal is eventual consistency on address assignment, it may be possible to distribute the table in an effective way. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Mar 19 18:44:56 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039543A697C; Wed, 19 Mar 2008 18:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.797 X-Spam-Level: X-Spam-Status: No, score=-100.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 EZx9OomDf4dU; Wed, 19 Mar 2008 18:44:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54453A6D2E; Wed, 19 Mar 2008 18:44: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 347053A6A53 for <6lowpan@core3.amsl.com>; Wed, 19 Mar 2008 18:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 2hKpi6C+kwyz for <6lowpan@core3.amsl.com>; Wed, 19 Mar 2008 18:44:52 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 7508328C245 for <6lowpan@ietf.org>; Wed, 19 Mar 2008 18:43:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 56C79A935F; Wed, 19 Mar 2008 18:41:36 -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 xHsZuHeIziv9; Wed, 19 Mar 2008 18:41:29 -0700 (PDT) Received: from [192.168.1.103] (adsl-71-142-65-177.dsl.pltn13.pacbell.net [71.142.65.177]) by mail.sf.archrock.com (Postfix) with ESMTP id 7E177A9360; Wed, 19 Mar 2008 18:41:29 -0700 (PDT) Message-ID: <47E1C0C6.70707@archrock.com> Date: Wed, 19 Mar 2008 18:41:26 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Philip Levis References: <7892795E1A87F04CADFCCF41FADD00FC0558DCDD@xmb-ams-337.emea.cisco.com> <47E1B5FC.3080805@cs.stanford.edu> In-Reply-To: <47E1B5FC.3080805@cs.stanford.edu> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "cry out loud" vs. "white board" 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 Phil, Philip Levis wrote: > I think the idea of a whiteboard is powerful. It definitely makes more > sense than "shout out." Yes. DHCP has proven itself useful, and for many reasons other than just avoiding "shout out". > single coordinating node, however. Your text puts it precisely: > "consider that LowPANs *usually* have a sink of some sort" (emphasis > mine). Forcing this to be centralized requires such a node exist and > therefore precludes certain kinds of LowPANs. A solution may simply be to configure your IP addresses using an IID derived from the EUI-64, which must be unique within a PAN. If you really want automatic assignment of short addresses, then that's a different beast. But it might not be worth the overhead. > That being said, this approach seems to implicitly assume mesh under? > Nodes "use Neighbor Discovery to determine the link-layer addresses for > neighbors known to reside on attached links and to quickly purge cached > values that become invalid." ND could operate on a single hop basis. Let's be clear on what kind of hop. I'm sure you meant a single 15.4 radio hop, not an IP hop. > This simplifies everything. The place where the whiteboard approach is > necessary is for DAD. But given that the goal is eventual consistency on > address assignment, it may be possible to distribute the table in an > effective way. While I agree it does simplify many things, it doesn't simplify everything :-). RFC 4861 explicitly assumes multicast-capable links with reflexive and transitive reachability. DAD is only one example. ND is also used for redirect and to propagate network parameters. In a route-over configuration, the mechanisms currently defined aren't very useful in a route-over 15.4 PAN. I'm currently signed up to work on an I-D that addresses this case, as it is an interesting case to consider. -- Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 20 03:05:28 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F277A28C370; Thu, 20 Mar 2008 03:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.793 X-Spam-Level: X-Spam-Status: No, score=-100.793 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 lXp7g2QaMwoH; Thu, 20 Mar 2008 03:05:22 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C40328C2F7; Thu, 20 Mar 2008 03:05: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 9EE7728C218 for <6lowpan@core3.amsl.com>; Thu, 20 Mar 2008 03:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 OufOFjzm0URU for <6lowpan@core3.amsl.com>; Thu, 20 Mar 2008 03:05:19 -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 9B51D28C1FC for <6lowpan@ietf.org>; Thu, 20 Mar 2008 03:05:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,530,1199660400"; d="scan'208";a="4040133" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2008 11:02:58 +0100 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 m2KA2wZC027321; Thu, 20 Mar 2008 11:02:58 +0100 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 m2KA2w8K008289; Thu, 20 Mar 2008 10:02:58 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, 20 Mar 2008 11:02:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 11:02:26 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05646078@xmb-ams-337.emea.cisco.com> In-Reply-To: <47E1C0C6.70707@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] "cry out loud" vs. "white board" thread-index: AciKK5AHCj0pbuAjQBmekMiij91PDwAOdYEA From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Philip Levis" X-OriginalArrivalTime: 20 Mar 2008 10:02:57.0816 (UTC) FILETIME=[92C1A180:01C88A71] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3523; t=1206007378; x=1206871378; 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=22cry=20out=20loud=22=20vs .=20=22white=20board=22 |Sender:=20; bh=RH0jdjHJC9EBSjfffD1GrjazKnAJKyS8ddJf0bStr3U=; b=ZseXo+X6HzxFuleTmAL3ajCIZa0Pg5ICc/MgTDmfMqn/CevI7axwm+PShA iaUSyNxNBxGotfxBW5kWXNUWkW5ICQ6+fLbKmDCKNEeg7IVtDkUeGQ/Mk9tM V0k28x/4Cq; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org>, "Benoit Lourdelet \(blourdel\)" Subject: Re: [6lowpan] "cry out loud" vs. "white board" 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 and Phil IID derived from the EUI-64 and Optimistic DAD can save some ND flows. But then again this is only dampening the shouting and in any case less efficient than white board approach. About implementing white board, my initial draft extends ND but I seems clear now that this will create confusion. I'd rather follow Jonathan's view that DHCP is the protocol of choice to perform the registration. I'll have that in mind for version 01 and probably migrate to DHCP, and sollicit help of DHCP specialists. I'm not claiming that we get rid of ND, I'm saying that we propose a solution where NS and NAs are fully replaced by DHCP requests over the LoWPAN. We do not MUST or SHOULD the support of NS/NA and propose a clear DHCP based alternative. Whether we do mesh under or route over, it seems clear that DHCP will be supported, so the model will still work. The following tools already exist: RFC3315 (DHCPv6) that we can use to obtain a DADless address RFC5007 : (Lease query for Ipv6) that we can use to sollicit another node's address. For Carsten: http://www.ietf.org/internet-drafts/draft-van-beijnum-cga-dhcp-interacti on-00.txt explains that we do not need the dhcp server to generate the CGA address, a point that I certainly disagree with :) Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: jeudi 20 mars 2008 02:41 >To: Philip Levis >Cc: Pascal Thubert (pthubert); 6lowpan >Subject: Re: [6lowpan] "cry out loud" vs. "white board" > > >Hi Phil, > >Philip Levis wrote: >> I think the idea of a whiteboard is powerful. It definitely makes more >> sense than "shout out." > >Yes. DHCP has proven itself useful, and for many reasons other than just >avoiding "shout out". > >> single coordinating node, however. Your text puts it precisely: >> "consider that LowPANs *usually* have a sink of some sort" (emphasis >> mine). Forcing this to be centralized requires such a node exist and >> therefore precludes certain kinds of LowPANs. > >A solution may simply be to configure your IP addresses using an IID >derived from the EUI-64, which must be unique within a PAN. If you >really want automatic assignment of short addresses, then that's a >different beast. But it might not be worth the overhead. > >> That being said, this approach seems to implicitly assume mesh under? >> Nodes "use Neighbor Discovery to determine the link-layer addresses for >> neighbors known to reside on attached links and to quickly purge cached >> values that become invalid." ND could operate on a single hop basis. > >Let's be clear on what kind of hop. I'm sure you meant a single 15.4 >radio hop, not an IP hop. > >> This simplifies everything. The place where the whiteboard approach is >> necessary is for DAD. But given that the goal is eventual consistency on >> address assignment, it may be possible to distribute the table in an >> effective way. > >While I agree it does simplify many things, it doesn't simplify >everything :-). RFC 4861 explicitly assumes multicast-capable links with >reflexive and transitive reachability. DAD is only one example. ND is >also used for redirect and to propagate network parameters. In a >route-over configuration, the mechanisms currently defined aren't very >useful in a route-over 15.4 PAN. I'm currently signed up to work on an >I-D that addresses this case, as it is an interesting case to consider. > >-- >Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 20 03:28:08 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49773A6973; Thu, 20 Mar 2008 03:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.864 X-Spam-Level: X-Spam-Status: No, score=-100.864 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 zN3eaKtDzYfx; Thu, 20 Mar 2008 03:28:08 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC0E3A6B51; Thu, 20 Mar 2008 03:28: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 BFBAD28C287 for <6lowpan@core3.amsl.com>; Thu, 20 Mar 2008 03:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 vr7EjbQhEVa2 for <6lowpan@core3.amsl.com>; Thu, 20 Mar 2008 03:28:03 -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 9176728C0DD for <6lowpan@ietf.org>; Thu, 20 Mar 2008 03:28:02 -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 m2KAPOf0025863; Thu, 20 Mar 2008 11:25:24 +0100 (CET) Message-Id: <79D21245-EDB2-4A23-8340-9EEEDFE08D85@tzi.org> From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05646078@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 20 Mar 2008 11:25:23 +0100 References: <7892795E1A87F04CADFCCF41FADD00FC05646078@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: "Benoit Lourdelet \(blourdel\)" , Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "cry out loud" vs. "white board" 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 On Mar 20 2008, at 11:02, Pascal Thubert (pthubert) wrote: > DHCP is the protocol of choice to perform the registration Wait a minute; DHCP uses broadcast (well, link-scoped multicast). So I don't know how much this helps as is. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 20 05:24:12 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9CA53A6872; Thu, 20 Mar 2008 05:24:12 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | message/rfc822,message | multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -100.508 X-Spam-Level: X-Spam-Status: No, score=-100.508 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com 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 NtnlGO31tPn9; Thu, 20 Mar 2008 05:24:12 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1206015852-19907-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Subject: Re: [6lowpan] "cry out loud" vs. "white board" Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F051C28C115; Thu, 20 Mar 2008 05:24:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14443A6973 for <6lowpan@core3.amsl.com>; Thu, 20 Mar 2008 05:24:11 -0700 (PDT) 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 K5uhE9JorBuz for <6lowpan@core3.amsl.com>; Thu, 20 Mar 2008 05:24:10 -0700 (PDT) Received: from mailf.telecomitalia.it (mailf.telecomitalia.it [156.54.233.32]) by core3.amsl.com (Postfix) with ESMTP id 3B33528C2E3 for <6lowpan@ietf.org>; Thu, 20 Mar 2008 05:24:10 -0700 (PDT) Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 13:21:51 +0100 Received: from PTPTMP101BA020.idc.cww.telecomitalia.it ([156.54.240.116]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 13:21:50 +0100 Date: Thu, 20 Mar 2008 13:21:50 +0100 Message-ID: References: From: "Porcu Giorgio" To: <6lowpan@ietf.org> This is a multi-part message in MIME format... ------------=_1206015852-19907-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1206015852-19907-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F051C28C115; Thu, 20 Mar 2008 05:24: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 A14443A6973 for <6lowpan@core3.amsl.com>; Thu, 20 Mar 2008 05:24:11 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com 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 K5uhE9JorBuz for <6lowpan@core3.amsl.com>; Thu, 20 Mar 2008 05:24:10 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1206015851-20484-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from mailf.telecomitalia.it (mailf.telecomitalia.it [156.54.233.32]) by core3.amsl.com (Postfix) with ESMTP id 3B33528C2E3 for <6lowpan@ietf.org>; Thu, 20 Mar 2008 05:24:10 -0700 (PDT) Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 13:21:51 +0100 Received: from PTPTMP101BA020.idc.cww.telecomitalia.it ([156.54.240.116]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 13:21:50 +0100 Date: Thu, 20 Mar 2008 13:21:50 +0100 Message-ID: References: From: "Porcu Giorgio" To: <6lowpan@ietf.org> Subject: Re: [6lowpan] "cry out loud" vs. "white board" 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format... ------------=_1206015851-20484-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1206015851-20484-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from mailf.telecomitalia.it (mailf.telecomitalia.it [156.54.233.32]) by core3.amsl.com (Postfix) with ESMTP id 3B33528C2E3 for <6lowpan@ietf.org>; Thu, 20 Mar 2008 05:24:10 -0700 (PDT) Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 13:21:51 +0100 Received: from PTPTMP101BA020.idc.cww.telecomitalia.it ([156.54.240.116]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 13:21:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C88A84.F95C5FC0" Subject: RE: "cry out loud" vs. "white board" Date: Thu, 20 Mar 2008 13:21:50 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "cry out loud" vs. "white board" Thread-Index: AciJKijwTfPK75pRRemHT2IgvFuzMwBWcVnz References: From: "Porcu Giorgio" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 20 Mar 2008 12:21:50.0569 (UTC) FILETIME=[F976D590:01C88A84] This is a multi-part message in MIME format. ------_=_NextPart_001_01C88A84.F95C5FC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Pascal wrote: >>I tried to capture this idea in >>http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. ... >>So, what do you think? In my opinion it's a very good draft and I agree it would be a good idea = to try to reduce broadcast traffic for ND. For this reason, the "white board" approach is very appealing, but I = have some questions about it... Tell me if I'm wrong: the main idea is that there is a logical = centralized "white board" that includes all the IP addresses from = multiple PANs. But what happens within a PAN when a backbone router crashes? How can a = node get routing info about other nodes belonging to its same PAN if it = can't access the white board residing on the crashed backbone router? = The nodes may keep their own routing cache, but this is not a completely = reliable approach. Is that point interesting for the WG? (maybe is out of scope of this = specific draft) Let me know if you have any thoughts about this (or if this problem it's = been yet analized by the WG :p) Regards Giorgio =20 ------_=_NextPart_001_01C88A84.F95C5FC0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjMMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAJgAAAFJFOiAiY3J5IG91dCBsb3Vk IiB2cy4gIndoaXRlIGJvYXJkIiAA0wsBBYADAA4AAADYBwMAFAANABUAMgAEAE4BASCAAwAOAAAA 2AcDABQADQAVADIABABOAQEJgAEAIQAAADMwODEwMEMwQkY5M0Y2NDdCOUM2M0U0NTVBOTc1Mzkx AAcHAQOQBgA0DwAAOAAAAAMANgAAAAAAQAA5AMBfXPmEisgBHgA9AAEAAAAFAAAAUkU6IAAAAAAC AUcAAQAAAD8AAABjPVVTO2E9IDtwPVRlbGVjb20gSXRhbGlhIFM7bD1QVFBUTVAxMDFCQTAtMDgw MzIwMTIyMTUwWi0yMjU1NAAAHgBJAAEAAAAhAAAANmxvd3BhbiBEaWdlc3QsIFZvbCAzOCwgSXNz dWUgMjUAAAAAQABOAICvZ0oqicgBHgBaAAEAAAAZAAAANmxvd3Bhbi1ib3VuY2VzQGlldGYub3Jn AAAAAAIBWwABAAAATwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAADZsb3dwYW4tYm91bmNlc0Bp ZXRmLm9yZwBTTVRQADZsb3dwYW4tYm91bmNlc0BpZXRmLm9yZwAAAgFcAAEAAAAeAAAAU01UUDo2 TE9XUEFOLUJPVU5DRVNASUVURi5PUkcAAAAeAF0AAQAAABkAAAA2bG93cGFuLXJlcXVlc3RAaWV0 Zi5vcmcAAAAAAgFeAAEAAABPAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAANmxvd3Bhbi1yZXF1 ZXN0QGlldGYub3JnAFNNVFAANmxvd3Bhbi1yZXF1ZXN0QGlldGYub3JnAAACAV8AAQAAAB4AAABT TVRQOjZMT1dQQU4tUkVRVUVTVEBJRVRGLk9SRwAAAB4AZgABAAAABQAAAFNNVFAAAAAAHgBnAAEA AAAZAAAANmxvd3Bhbi1ib3VuY2VzQGlldGYub3JnAAAAAB4AaAABAAAABQAAAFNNVFAAAAAAHgBp AAEAAAAZAAAANmxvd3Bhbi1yZXF1ZXN0QGlldGYub3JnAAAAAB4AcAABAAAAIgAAACJjcnkgb3V0 IGxvdWQiIHZzLiAid2hpdGUgYm9hcmQiIAAAAAIBcQABAAAAGwAAAAHIiSoo8E3zyu+aUUXph09i ILxbszMAVnFZ8wAeAHQAAQAAABEAAAA2bG93cGFuQGlldGYub3JnAAAAAB4AGgwBAAAADgAAAFBv cmN1IEdpb3JnaW8AAAAeAB0OAQAAACIAAAAiY3J5IG91dCBsb3VkIiB2cy4gIndoaXRlIGJvYXJk IiAAAAACAQkQAQAAAMQHAADABwAAkRcAAExaRnVrprhsAwAKAHJjcGcxMjWCMgNDaHRtbDEDMD8B AwH3CoACpAPjAgBjaMEKwHNldDAgBxMCgP8QAwBQBFYIVQeyEdUOUQMB3RDXMgYABsMR1TMERhDZ +RLvZjQQbxF2EeMI7wn39jsavw4wNRvfG7ER4QxgzmMAUAsJAWQzNhFgC6XkNCAQAipcDrIBkA4Q ADkgPEhUTUwgEGRpcj0hUHI+fc8hEwAhAzAiYWRvAOAiYfkKsVxxGqAiYRDwAzAixRsRYCDLMyCg IcBFQUQTIpAgzDc3IbBUSVRcTEUmvSCQDvA2GlB3IwqwA6BEaWcHkHQsRCBWBvAgMzgqUEmbBBAK UCAOMCbNODUhsO4vJ/8hYgrjIC0fLi8OEAI2DvA8TUVUQSDHBaACMAnwdD0iBeAh0+A2LjAwLiAA MlEwkEEOQDUiIG5hB4A9AEdFTkVSQVRP/lImvSlBLJAmfykRL18hYYI1EWA8Qk9EWSa9IyARNs9n OTYhsERJIFYgaWQ9OyBPVwhBUmULUHlUZXhgdDk0MjcscCIvIP8AACPFJGMkISS/OO85/zsAzzyf Pa8+uiDpNjRCmj7vCSFENDghsEZPTlR8IGYA0DNwBxMxIRpRPVYjMpEykSAAkHozcDL3QosYMAMw YxPwA7IB0D7PXzSmQFUg6QHAJsw2SAFQfya+R/9JAUofSyRL3yDpOCEmQVNQQU5SQHR5CmwzcCJI Mi1TSVogRTogMTAFMDsggVaDRkFNSUxZVxCNBxMiQotUJ0hpIAdA/GwsIMwwkDgBNBEiuQuAZmUK gVQnUGEE8EkBd3sDYDFgOlqfW69cvFS+JnZnV2AiqD5gz2HfYu9JViAicAiQZGaQbzEgYWcFMAhw KzB0aAQAOxFl+mE7EG5eb19/YI9kL2U/D2s/bE9tWQ6wdHA6L2YvZwAG8HMuCJAAMC4JBbBnLw6y L2RyYeUBgC1nsHViBJBygCl1tC1iANBrBuBcsC0DYMJ1MWByLiAudLBof39pj2qfbj9vT3eveL95 yVM6bypQdxEABUAjgCB54whgZ6Juaz9073X/XLyCSQOgbXkgb3ALgGZpAiA7EHQnBCBoMHZ7BJCB oGdxEGbgckNaQG5/ZuBmgCFwCdGCMV3wCGBs/2bgctCCgYMDaANnASJwgaAvZwEdQR6gKzBiA2Bh ZO9dwCowZpFyYGYN4EhwBbH0TkR03DkU8CyQVcIimesip0b+NTqxL0gyif+LA/+M7435CqKKqFzY CuN3L05I/yyBUA5AT0VkT+NY7436Sy+/ke9Qv1HPUt+Y/1T/IAtgyG5nPTOgLVUF8FYf91cvWD9G PEYFsWezHUBdoO8CICpQZ7ArMCJ9QIJAhuHvhyALIDMgZ0BwhxEkkWfRr4KzppFoIFyRZypQYnRQ v2ZxEQCCsJvQA3ArMHEKUAsqMIIBc3p/bmJzcPF7qVwnYQFAnbcBoHRB/4IxdL9/T4BfiJ+Jr6/f i8//se+y/5qfm6+cv7WPVU+gn/+hr6K/ueg78FpggYCEUSMg+EknbV3yn8C84KVyAMD/C4Bn9QQg Z7B9YaVxZ4Fn0ftoMBpQZw3gSQIxcXJQXJDfuEBm4KW8wmMLgGMKQAEAp4JxwBGlcklQWkBkckD/ B5ARMAQgA1KBgITAqZALUP8rMLuhcUCwf7GPue+zr8pf/43vjv+QD5Efy1+TP5RPlV//vs+Xf5iP y3+277f/uQ/Zr9+7L7w/vU++X94HQqhhfUP/EQCnsQYxA/B+AoKB37J9QH8J8IKBc6aGgHRDMSBy UHN5pYBzP1oQKZBnIeVibv8EcYLwEUDm06gBaEECEKy1/14gwsHocwQgctAaUJ/A6VL3ZwGCQAQg czNR5ZPAcYRx9eghJ4ORY0igBBGlcqXJ/4aBAJBCEOlhghGlcudUhOF75mznwFSlgeqkAMCBoGvd CeBwpWJCIIGwdwOg6Rb7XcAQ8GWoNGe0BCDogIOR/TEhbchRMWA70IaBXJABoP/IYaaWrW+uf6+P yQ/KH/mf/8w/+6/Z/9sP3B/dL/9P30//4F/hb+J/A6/3r/i/ZjTCRfxwb8XQxbJ0Yaly6WGIIvml cldH58D6H/svCP/9T/8QbxF/AH8BjwKfFA+e35/v7wYvBz8ITxjCKPIBhQFn0f/qAyMgXbCBwCsw IAFns6sQ3GVjwHCH8XJDKQmfCq//+T8PLxA/JJ8SXyavFH8Vj/8WnxevKk8ZzxrfG+8c/x4P7CBM 6OHsMWvogOgAwHGvfcKos+gwhkForOBne9D3wyGs02ezKIgxwHFns6ax3/ZBwMCCQ3LQ5gF56OHo MI3ENWI20g6SIDpwIfz/Jd8pvyf/KQ/Xb0Cf0B/RL/8979NP1F/Vb9Z/14/Yn0Uv/ys/LE8tX0w/ BI8xPzJPM1/xCMtSZWfukancIt8j7/wgR4IAccCCADu/PM9Qz/8+71wvQQ9CH0MvRD9dL0ZfXUiz Mk3CXpVM7DBJES/4RElWXu9kT2g/aU9HD71IHTlYMWthfYDywD1IwD5yT2tv0W3xcMLz0Fxx/8PA bFhIW1WPbL9NuE8PS0H/UI9dr16/d6+qf6uPckxlYL98V2IOaj9rT3pfSKQ1ZtJQQk9EWWXON3kh SChUTUxGwH2GAB4ANRABAAAAUQAAADxFQkU2OTQwRjk0QjQ2NzRGOTU2NjJGM0FFMzYxMkY5NDAy RDY3MkBQVFBUTVAxMDFCQTAyMC5pZGMuY3d3LnRlbGVjb21pdGFsaWEuaXQ+AAAAAB4AORABAAAA LgAAADxtYWlsbWFuLjU3LjEyMDU4NjY4MTEuNTI1OC42bG93cGFuQGlldGYub3JnPgAAAB4ARxAB AAAADwAAAG1lc3NhZ2UvcmZjODIyAAALAPIQAQAAAB8A8xABAAAAZgAAAFIARQAlADMAQQAgACUA MgAyAGMAcgB5ACAAbwB1AHQAIABsAG8AdQBkACUAMgAyACAAdgBzAC4AIAAlADIAMgB3AGgAaQB0 AGUAIABiAG8AYQByAGQAJQAyADIALgBFAE0ATAAAAAAACwD2EAAAAABAAAcwwG9V7oOKyAFAAAgw JOll+YSKyAEDAN4/r28AAAMA8T8QBAAAHgD4PwEAAAAOAAAAUG9yY3UgR2lvcmdpbwAAAAIB+T8B AAAAXAAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1URUxFQ09NIElUQUxJQSBTLlAu QS4vT1U9UE9TVEEtVE9QL0NOPVJFQ0lQSUVOVFMvQ049VUUwMTgzNzEAHgD6PwEAAAAVAAAAU3lz dGVtIEFkbWluaXN0cmF0b3IAAAAAAgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAA AAAAAC4AAAADAP0/5AQAAAMAGUAAAAAAAwAaQAAAAAADAB1AAAAAAAMAHkAAAAAAHgAwQAEAAAAJ AAAAVUUwMTgzNzEAAAAAHgAxQAEAAAAJAAAAVUUwMTgzNzEAAAAAHgAyQAEAAAAZAAAANmxvd3Bh bi1ib3VuY2VzQGlldGYub3JnAAAAAB4AM0ABAAAAGQAAADZsb3dwYW4tcmVxdWVzdEBpZXRmLm9y ZwAAAAAeADhAAQAAAAkAAABVRTAxODM3MQAAAAAeADlAAQAAAAIAAAAuAAAAAwB2QP////8LACkA AAAAAAsAIwAAAAAAAwAGEP2SXR0DAAcQNwMAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABI SUFMTCxQQVNDQUxXUk9URTpJVFJJRURUT0NBUFRVUkVUSElTSURFQUlOSFRUUDovL1RPT0xTSUVU Rk9SRy9IVE1ML0RSQUZULVRIVUJFUlQtNkxPV1BBTi1CQUNLQk9ORS1SAAAAAAIBfwABAAAAUQAA ADxFQkU2OTQwRjk0QjQ2NzRGOTU2NjJGM0FFMzYxMkY5NDAyRDY3MkBQVFBUTVAxMDFCQTAyMC5p ZGMuY3d3LnRlbGVjb21pdGFsaWEuaXQ+AAAAAJTM ------_=_NextPart_001_01C88A84.F95C5FC0-- ------------=_1206015851-20484-1 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 ------------=_1206015851-20484-1-- ------------=_1206015852-19907-1-- From 6lowpan-bounces@ietf.org Thu Mar 20 05:46:30 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D00028C384; Thu, 20 Mar 2008 05:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.76 X-Spam-Level: X-Spam-Status: No, score=-100.76 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 IZsTUn9xOfjK; Thu, 20 Mar 2008 05:46:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4A328C2E3; Thu, 20 Mar 2008 05:46: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 2925228C2FD for <6lowpan@core3.amsl.com>; Thu, 20 Mar 2008 05:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 TgjQ3y8BP9sW for <6lowpan@core3.amsl.com>; Thu, 20 Mar 2008 05:46:20 -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 5FD6E3A6B53 for <6lowpan@ietf.org>; Thu, 20 Mar 2008 05:46:20 -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 m2KChsn0011210; Thu, 20 Mar 2008 13:43:54 +0100 (CET) Message-Id: <1615FCFF-03F7-442F-A563-843129465918@tzi.org> From: Carsten Bormann To: "Porcu Giorgio" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 20 Mar 2008 13:43:53 +0100 References: X-Mailer: Apple Mail (2.919.2) Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] "cry out loud" vs. "white board" 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 On Mar 20 2008, at 13:21, Porcu Giorgio wrote: > But what happens within a PAN when a backbone router crashes? How > can a = > node get routing info about other nodes belonging to its same PAN if > it = > can't access the white board residing on the crashed backbone > router? = I'd say: The "backbone router" as a SPOF is a problem *if* the network can do anything useful without the "backbone router". If it can't (e.g., the whole point is connecting the sensors to some other node on the Internet), then the network can just fall apart (of course, the failure still needs to be battery-efficient, and there needs to be an orderly re-bootstrap when the/a backbone router comes up again). If it can: you need to elect a new coordinator. That might work best if there is a backup coordinator in operation all the time. Multiple coordinator candidates do cause all the partition/merge problems that I won't go into right now. A coordinator is also a useful thing to have for key management, so I believe it is best to think of the address management and key management problems in combination. Gruesse, Carsten PS.: Giorgio: You need to fix your mail setup: you should never send ms-tnef towards the Internet; I'm not sure how many people could even read your message. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 20 08:21:01 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB6D28C66D; Thu, 20 Mar 2008 08:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 PyC2Tq1Z0GeN; Thu, 20 Mar 2008 08:21:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71EF228C640; Thu, 20 Mar 2008 08:20:58 -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 AE9A028C4E4 for <6lowpan@core3.amsl.com>; Thu, 20 Mar 2008 08:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 F+RFR0r8dIBL for <6lowpan@core3.amsl.com>; Thu, 20 Mar 2008 08:20:56 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id EE51828C54C for <6lowpan@ietf.org>; Thu, 20 Mar 2008 08:20:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id BFE63A9371; Thu, 20 Mar 2008 08:18:38 -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 afSoKO0WKANf; Thu, 20 Mar 2008 08:18:32 -0700 (PDT) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 9111EA9314; Thu, 20 Mar 2008 08:18:31 -0700 (PDT) Message-ID: <47E28043.30004@archrock.com> Date: Thu, 20 Mar 2008 08:18:27 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC05646078@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05646078@xmb-ams-337.emea.cisco.com> Cc: 6lowpan <6lowpan@ietf.org>, "Benoit Lourdelet \(blourdel\)" Subject: Re: [6lowpan] "cry out loud" vs. "white board" 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 Pascal, Pascal Thubert (pthubert) wrote: > IID derived from the EUI-64 and Optimistic DAD can save some ND flows. > But then again this is only dampening the shouting and in any case less > efficient than white board approach. Yes, IID from EUI-64 isn't the best solution for many cases. I was only suggesting a quick-and-dirty possibility for those cases where a centralized solution is not favorable. > About implementing white board, my initial draft extends ND but I seems > clear now that this will create confusion. I'd rather follow Jonathan's > view that DHCP is the protocol of choice to perform the registration. > I'll have that in mind for version 01 and probably migrate to DHCP, and > sollicit help of DHCP specialists. I plan to address both SAA and DHCPv6 in a route-over autoconfiguration for 6LoWPAN draft. We should coordinate our efforts to see if there's some commonality. While I expect mesh-under and route-over to utilize different mechanisms, it would still be good to make them similar in areas that they do overlap. On a side note, I'm not sure we want to use the formats as specified in RFC3315. I was thinking of scoping RFC3315 and making it less general to compress the DHCPv6 options formats. For Carsten: DHCP does use link-local multicast, but such a restriction hasn't stopped us from optimizing protocols in 6LoWPAN networks to utilize unicast communication. -- Jonathan Hui > I'm not claiming that we get rid of ND, I'm saying that we propose a > solution where NS and NAs are fully replaced by DHCP requests over the > LoWPAN. We do not MUST or SHOULD the support of NS/NA and propose a > clear DHCP based alternative. Whether we do mesh under or route over, it > seems clear that DHCP will be supported, so the model will still work. > > The following tools already exist: > > RFC3315 (DHCPv6) that we can use to obtain a DADless address > > RFC5007 : (Lease query for Ipv6) that we can use to sollicit another > node's address. > > For Carsten: > > http://www.ietf.org/internet-drafts/draft-van-beijnum-cga-dhcp-interacti > on-00.txt > > explains that we do not need the dhcp server to generate the CGA > address, a point that I certainly disagree with :) > > Pascal >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: jeudi 20 mars 2008 02:41 >> To: Philip Levis >> Cc: Pascal Thubert (pthubert); 6lowpan >> Subject: Re: [6lowpan] "cry out loud" vs. "white board" >> >> >> Hi Phil, >> >> Philip Levis wrote: >>> I think the idea of a whiteboard is powerful. It definitely makes > more >>> sense than "shout out." >> Yes. DHCP has proven itself useful, and for many reasons other than > just >> avoiding "shout out". >> >>> single coordinating node, however. Your text puts it precisely: >>> "consider that LowPANs *usually* have a sink of some sort" (emphasis >>> mine). Forcing this to be centralized requires such a node exist and >>> therefore precludes certain kinds of LowPANs. >> A solution may simply be to configure your IP addresses using an IID >> derived from the EUI-64, which must be unique within a PAN. If you >> really want automatic assignment of short addresses, then that's a >> different beast. But it might not be worth the overhead. >> >>> That being said, this approach seems to implicitly assume mesh under? >>> Nodes "use Neighbor Discovery to determine the link-layer addresses > for >>> neighbors known to reside on attached links and to quickly purge > cached >>> values that become invalid." ND could operate on a single hop basis. >> Let's be clear on what kind of hop. I'm sure you meant a single 15.4 >> radio hop, not an IP hop. >> >>> This simplifies everything. The place where the whiteboard approach > is >>> necessary is for DAD. But given that the goal is eventual consistency > on >>> address assignment, it may be possible to distribute the table in an >>> effective way. >> While I agree it does simplify many things, it doesn't simplify >> everything :-). RFC 4861 explicitly assumes multicast-capable links > with >> reflexive and transitive reachability. DAD is only one example. ND is >> also used for redirect and to propagate network parameters. In a >> route-over configuration, the mechanisms currently defined aren't very >> useful in a route-over 15.4 PAN. I'm currently signed up to work on an >> I-D that addresses this case, as it is an interesting case to consider. >> >> -- >> Jonathan Hui > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Mar 21 07:44:24 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3524B28C31D; Fri, 21 Mar 2008 07:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.862 X-Spam-Level: X-Spam-Status: No, score=-100.862 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 FsxAXk4vrqMQ; Fri, 21 Mar 2008 07:44:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B80B28C139; Fri, 21 Mar 2008 07:44:23 -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 35E823A68BE for <6lowpan@core3.amsl.com>; Fri, 21 Mar 2008 07:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 L3LpbP-VMxrt for <6lowpan@core3.amsl.com>; Fri, 21 Mar 2008 07:44:20 -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 A96833A6C28 for <6lowpan@ietf.org>; Fri, 21 Mar 2008 07:44:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,536,1199660400"; d="scan'208";a="4164603" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2008 15:41:37 +0100 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 m2LEfbiC025680; Fri, 21 Mar 2008 15:41:37 +0100 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 m2LEfbkv014308; Fri, 21 Mar 2008 14:41:37 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, 21 Mar 2008 15:41:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Mar 2008 15:41:05 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC056464BE@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] "cry out loud" vs. "white board" thread-index: AciKdMRyNXhXNjaLRXebripwXQjmKgAFqlnQADVnfIA= From: "Pascal Thubert (pthubert)" To: "Benoit Lourdelet (blourdel)" , "Carsten Bormann" X-OriginalArrivalTime: 21 Mar 2008 14:41:37.0396 (UTC) FILETIME=[AAD0D340:01C88B61] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1309; t=1206110497; x=1206974497; 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]=20=22cry=20out=20loud=22=20vs .=20=22white=20board=22 |Sender:=20; bh=JApTggrGCtOl4Lijj9u3PK0zzL6uQpCp+yJLV+wM+sY=; b=BdTRSiqQfKua31gcQLZt9HsEEwa7eSgRUOsGkXgXeDyNiZAuhPSIVax2VR iqNs2FpxJcbYpBvoMhrzONQaQF4p9eARvrTs8q5mAx5Lh8phVH9D/I1caZug CiTIzj1gmc; 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] "cry out loud" vs. "white board" 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 The point is: The nodes does not need to listen for multicast, and the SOLLICIT mcst can be actually be mapped onto a functional unicast address, in other words a 16bits PAN local address that targets the backbone router, as opposed to mac-level broadcast. Pascal >-----Original Message----- >From: Benoit Lourdelet (blourdel) >Sent: jeudi 20 mars 2008 14:10 >To: Carsten Bormann >Cc: Jonathan Hui; Philip Levis; 6lowpan; Pascal Thubert (pthubert) >Subject: RE: [6lowpan] "cry out loud" vs. "white board" > > Cartsten, > >If we push DHCPv6 to the limit, only the SOLLICIT is multicasted, the rest of the messages (ADVERTISE, >REQUEST (through the unicast option), and REPLY are unicasted). > > >Regards > >Benoit > >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: Thursday, March 20, 2008 11:25 AM >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; Jonathan Hui; Philip Levis; 6lowpan; Benoit Lourdelet (blourdel) >Subject: Re: [6lowpan] "cry out loud" vs. "white board" > >On Mar 20 2008, at 11:02, Pascal Thubert (pthubert) wrote: > >> DHCP is the protocol of choice to perform the registration > >Wait a minute; DHCP uses broadcast (well, link-scoped multicast). >So I don't know how much this helps as is. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 25 09:23:31 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5973A6C16; Tue, 25 Mar 2008 09:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.256 X-Spam-Level: X-Spam-Status: No, score=-99.256 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_53=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 PmNsmp+EHkvY; Tue, 25 Mar 2008 09:23:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9B03A695C; Tue, 25 Mar 2008 09:23: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 D15EB3A695C for <6lowpan@core3.amsl.com>; Tue, 25 Mar 2008 09:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 PvVMIpJ8bcYA for <6lowpan@core3.amsl.com>; Tue, 25 Mar 2008 09:23:27 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 1F6933A6838 for <6lowpan@ietf.org>; Tue, 25 Mar 2008 09:23:26 -0700 (PDT) Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 17:21:07 +0100 Received: from PTPTMP101BA020.idc.cww.telecomitalia.it ([156.54.240.116]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 17:21:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Mar 2008 17:18:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "cry out loud" vs. "white board" Thread-Index: AciKvGe63imzEwrSQzSF16DBKf2mDQD121sL References: From: "Porcu Giorgio" To: <6lowpan@ietf.org>, <6lowpan@ietf.org> X-OriginalArrivalTime: 25 Mar 2008 16:21:07.0024 (UTC) FILETIME=[3AA4C500:01C88E94] Subject: Re: [6lowpan] "cry out loud" vs. "white board" 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 Carsten, thanks a lot for your fast answer. You get the point exactly! Carsten Bormann wrote: >>I'd say: The "backbone router" as a SPOF is a problem *if* the network >>can do anything useful without the "backbone router". For me it's important that nodes could communicate even without the "backbone router" up and running. Not only for the SPOF problem but also for interoperability reason. The main idea is that we can have many PANs that we can see like a single and wide PAN (at the L3). In my opinion it's important to have a mechanism (at the L3, depending on routing strategy) that many nodes could use to switch from a PAN into another one, as result of a backbone router crash or some other event. A backup coordinator could be a naive strategy but, I think, the best is to converge into a single-standard solution (or one for routing strategy). Maybe this aspect is a little out of scope for the draft in discussion but I think that some input and feedback we can get from ROLL WG. What do you think? Regards Giorgio ________________________________ Da: 6lowpan-bounces@ietf.org per conto di 6lowpan-request@ietf.org Inviato: gio 20/03/2008 20.00 A: 6lowpan@ietf.org Oggetto: 6lowpan Digest, Vol 38, Issue 27 Send 6lowpan mailing list submissions to 6lowpan@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/6lowpan or, via email, send a message with subject or body 'help' to 6lowpan-request@ietf.org You can reach the person managing the list at 6lowpan-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of 6lowpan digest..." Today's Topics: 1. Re: "cry out loud" vs. "white board" (Carsten Bormann) 2. Re: "cry out loud" vs. "white board" (Jonathan Hui) ---------------------------------------------------------------------- Message: 1 Date: Thu, 20 Mar 2008 13:43:53 +0100 From: Carsten Bormann Subject: Re: [6lowpan] "cry out loud" vs. "white board" To: "Porcu Giorgio" Cc: Carsten Bormann , 6lowpan@ietf.org Message-ID: <1615FCFF-03F7-442F-A563-843129465918@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On Mar 20 2008, at 13:21, Porcu Giorgio wrote: > But what happens within a PAN when a backbone router crashes? How > can a = > node get routing info about other nodes belonging to its same PAN if > it = > can't access the white board residing on the crashed backbone > router? = I'd say: The "backbone router" as a SPOF is a problem *if* the network can do anything useful without the "backbone router". If it can't (e.g., the whole point is connecting the sensors to some other node on the Internet), then the network can just fall apart (of course, the failure still needs to be battery-efficient, and there needs to be an orderly re-bootstrap when the/a backbone router comes up again). If it can: you need to elect a new coordinator. That might work best if there is a backup coordinator in operation all the time. Multiple coordinator candidates do cause all the partition/merge problems that I won't go into right now. A coordinator is also a useful thing to have for key management, so I believe it is best to think of the address management and key management problems in combination. Gruesse, Carsten PS.: Giorgio: You need to fix your mail setup: you should never send ms-tnef towards the Internet; I'm not sure how many people could even read your message. ------------------------------ Message: 2 Date: Thu, 20 Mar 2008 08:18:27 -0700 From: Jonathan Hui Subject: Re: [6lowpan] "cry out loud" vs. "white board" To: "Pascal Thubert (pthubert)" Cc: 6lowpan <6lowpan@ietf.org>, "Benoit Lourdelet \(blourdel\)" Message-ID: <47E28043.30004@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Pascal, Pascal Thubert (pthubert) wrote: > IID derived from the EUI-64 and Optimistic DAD can save some ND flows. > But then again this is only dampening the shouting and in any case less > efficient than white board approach. Yes, IID from EUI-64 isn't the best solution for many cases. I was only suggesting a quick-and-dirty possibility for those cases where a centralized solution is not favorable. > About implementing white board, my initial draft extends ND but I seems > clear now that this will create confusion. I'd rather follow Jonathan's > view that DHCP is the protocol of choice to perform the registration. > I'll have that in mind for version 01 and probably migrate to DHCP, and > sollicit help of DHCP specialists. I plan to address both SAA and DHCPv6 in a route-over autoconfiguration for 6LoWPAN draft. We should coordinate our efforts to see if there's some commonality. While I expect mesh-under and route-over to utilize different mechanisms, it would still be good to make them similar in areas that they do overlap. On a side note, I'm not sure we want to use the formats as specified in RFC3315. I was thinking of scoping RFC3315 and making it less general to compress the DHCPv6 options formats. For Carsten: DHCP does use link-local multicast, but such a restriction hasn't stopped us from optimizing protocols in 6LoWPAN networks to utilize unicast communication. -- Jonathan Hui > I'm not claiming that we get rid of ND, I'm saying that we propose a > solution where NS and NAs are fully replaced by DHCP requests over the > LoWPAN. We do not MUST or SHOULD the support of NS/NA and propose a > clear DHCP based alternative. Whether we do mesh under or route over, it > seems clear that DHCP will be supported, so the model will still work. > > The following tools already exist: > > RFC3315 (DHCPv6) that we can use to obtain a DADless address > > RFC5007 : (Lease query for Ipv6) that we can use to sollicit another > node's address. > > For Carsten: > > http://www.ietf.org/internet-drafts/draft-van-beijnum-cga-dhcp-interacti > on-00.txt > > explains that we do not need the dhcp server to generate the CGA > address, a point that I certainly disagree with :) > > Pascal >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: jeudi 20 mars 2008 02:41 >> To: Philip Levis >> Cc: Pascal Thubert (pthubert); 6lowpan >> Subject: Re: [6lowpan] "cry out loud" vs. "white board" >> >> >> Hi Phil, >> >> Philip Levis wrote: >>> I think the idea of a whiteboard is powerful. It definitely makes > more >>> sense than "shout out." >> Yes. DHCP has proven itself useful, and for many reasons other than > just >> avoiding "shout out". >> >>> single coordinating node, however. Your text puts it precisely: >>> "consider that LowPANs *usually* have a sink of some sort" (emphasis >>> mine). Forcing this to be centralized requires such a node exist and >>> therefore precludes certain kinds of LowPANs. >> A solution may simply be to configure your IP addresses using an IID >> derived from the EUI-64, which must be unique within a PAN. If you >> really want automatic assignment of short addresses, then that's a >> different beast. But it might not be worth the overhead. >> >>> That being said, this approach seems to implicitly assume mesh under? >>> Nodes "use Neighbor Discovery to determine the link-layer addresses > for >>> neighbors known to reside on attached links and to quickly purge > cached >>> values that become invalid." ND could operate on a single hop basis. >> Let's be clear on what kind of hop. I'm sure you meant a single 15.4 >> radio hop, not an IP hop. >> >>> This simplifies everything. The place where the whiteboard approach > is >>> necessary is for DAD. But given that the goal is eventual consistency > on >>> address assignment, it may be possible to distribute the table in an >>> effective way. >> While I agree it does simplify many things, it doesn't simplify >> everything :-). RFC 4861 explicitly assumes multicast-capable links > with >> reflexive and transitive reachability. DAD is only one example. ND is >> also used for redirect and to propagate network parameters. In a >> route-over configuration, the mechanisms currently defined aren't very >> useful in a route-over 15.4 PAN. I'm currently signed up to work on an >> I-D that addresses this case, as it is an interesting case to consider. >> >> -- >> Jonathan Hui > ------------------------------ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan End of 6lowpan Digest, Vol 38, Issue 27 *************************************** _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Mar 26 10:23:48 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: ietfarch-6lowpan-archive@core3.amsl.com Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2553A6F29; Wed, 26 Mar 2008 10:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.904 X-Spam-Level: X-Spam-Status: No, score=-100.904 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 44jnPcrjGZqN; Wed, 26 Mar 2008 10:23:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD51028C34C; Wed, 26 Mar 2008 10:23: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 7471428C2BA for <6lowpan@core3.amsl.com>; Wed, 26 Mar 2008 10:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 qHGkcYKhfK2n for <6lowpan@core3.amsl.com>; Wed, 26 Mar 2008 10:23:37 -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 936413A6BA7 for <6lowpan@ietf.org>; Wed, 26 Mar 2008 10:23:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,559,1199660400"; d="scan'208";a="4527775" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Mar 2008 18:21:10 +0100 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 m2QHLAbf010991 for <6lowpan@ietf.org>; Wed, 26 Mar 2008 18:21:10 +0100 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 m2QHL9fn028835 for <6lowpan@ietf.org>; Wed, 26 Mar 2008 17:21:10 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); Wed, 26 Mar 2008 18:21:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 18:20:37 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC056EE338@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "cry out loud" vs. "white board" thread-index: AciJKijwTfPK75pRRemHT2IgvFuzMwBWcVnzAThr0MA= From: "Pascal Thubert (pthubert)" To: "Porcu Giorgio" , <6lowpan@ietf.org> X-OriginalArrivalTime: 26 Mar 2008 17:21:09.0971 (UTC) FILETIME=[C8949A30:01C88F65] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2072; t=1206552070; x=1207416070; 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=22cry=20out=20loud=22=20vs.=20=22white =20board=22=20 |Sender:=20; bh=WyEkvqdcxG+oRTlpnQ3gLJvGSb0qV+iFHO5qUGjdc/w=; b=nBJrGzWSTeQ46qgaMmldSzUbKoq/hNy0k78LJncTjEJnByMSIkNtFOk2HP Qj6g1glWy03buSDWuvLIloUjRnnbkL8BpDG17BZjWWZ8pd91V/grw4P9Xqdt iG/XyDa+I/; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [6lowpan] "cry out loud" vs. "white board" 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 Giorgio: Please see inline >>>http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. ... >>>So, what do you think? >In my opinion it's a very good draft and I agree it would be a good >idea to try to reduce broadcast traffic for ND. > >For this reason, the "white board" approach is very appealing, but I have some questions about it... >Tell me if I'm wrong: the main idea is that there is a logical >centralized "white board" that includes all the IP addresses from multiple PANs. [Pascal] Right; but there can and should be multiple backbone routers interconnected by a backbone, thus the name. Because the second half of the BbR feature is ND-proxy so that any node on the backbone is virtually on the same link as any device behind a BbR. > >But what happens within a PAN when a backbone router crashes? How can a >node get routing info about other nodes belonging to its same PAN if it >can't access the white board residing on the crashed backbone router? >The nodes may keep their own routing cache, but this is not a completely reliable approach. > [Pascal] When the BbR crashes, that's mostly the same as if you are a mobile node and your MIP6 Home Agent crashes. Active (similar to MIP6 route optimized) connections with the PAN are maintained, conections to the outside (similar to via the HA) are dropped. New connections with unresolved MAC addresses can not be started, and new nodes can not be inserted. That was acceptable for RFC 3775, I guess that is still. There's ample space for HSRP/proprietary hot standby solution for backup when needed. >Is that point interesting for the WG? (maybe is out of scope of this >specific draft) Let me know if you have any thoughts about this (or if >this problem it's been yet analized by the WG :p) > [Pascal] Well, we are supposed to consider how to implement ND in a LoWPAN. BbR is a ND solution that adds the concept of backbone to the picture. That concept comes from real users feedback and we should not ignore it... Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan