From 6lowpan-bounces@ietf.org Sun Aug 10 17:14:09 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAAFA3A6A60; Sun, 10 Aug 2008 17:14:09 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEAA13A6A17 for <6lowpan@core3.amsl.com>; Sun, 10 Aug 2008 17:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao3O6bATxJR5 for <6lowpan@core3.amsl.com>; Sun, 10 Aug 2008 17:14:07 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id DB7053A6A79 for <6lowpan@ietf.org>; Sun, 10 Aug 2008 17:14:07 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1652629wfd.31 for <6lowpan@ietf.org>; Sun, 10 Aug 2008 17:14:09 -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:content-transfer-encoding :content-disposition; bh=WS0RjKZGQQYb9fDACDO8Fd0oQFwbjHEhf+LhVfs5Reg=; b=lIP5KK4A1znmleuiKkWqAHPDcwr9xp23e88f0UT0ZIweu6qhMPXJR4mQ6LF2cTsyzH zgJGOM8JX60apH6v307yZ6Wd5qPGSbF++3uiY8xtOWqoFfZNWPbRGEfXtYtRWDP0sdcB GDmDXSJaHJGEDzS5HHp3xmY5hnJ4SMMF1HZg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=tX0ue53gnmcedFfhsnAxoY+9Cx/NnvOtXbgJkwNQNTJ56+6G60Hls4NV2gV3tCeHyT tUPeKnOJAfS/7cHKT0R8GNvQno/ncXzRPeov1SML81m/xVvcMpyuFjzXgRY3OWZwErOe dQMJ6k3aA5cyJkDh1kD4IVV+T6CPxlYKTACIo= Received: by 10.142.242.11 with SMTP id p11mr1878276wfh.198.1218413649600; Sun, 10 Aug 2008 17:14:09 -0700 (PDT) Received: by 10.142.78.9 with HTTP; Sun, 10 Aug 2008 17:14:09 -0700 (PDT) Message-ID: <43b91d370808101714h386ebc58j1142a4e15d0c2a6@mail.gmail.com> Date: Sun, 10 Aug 2008 17:14:09 -0700 From: "Samita Chakrabarti" To: "Zach Shelby" , "Erik Nordmark" , "Pascal Thubert (pthubert)" , jhui@archrock.com, "cabo@tzi.org" , "Geoff Mulligan" MIME-Version: 1.0 Content-Disposition: inline Cc: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] 6lowpan ND joint-work goals 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 All: Since we are starting to work on the combined ND solution for 6lowpan, as one of the members of the ad-hoc ND team, I thought it would be very useful to verify our solution guidelines with the working group. I am starting with a few bullet points, please check if that meets our (6lowpan wg) requirements. Please feel free to suggest modification when it makes sense. ND Design goals: * Neighbor discovery using IPv6 ND protocol or its variant * The solution will use unicast/anycast messages to reduce mulitcast * The solution should look into minimizing number of total ND messages * Initial boot-strapping information and fault-tolerance should be addressed if possible * This solution must provide methods for IPv6 address allocation in 6lowpan nodes * Define a link that serves 6lowpan common deployment * The design should work with mesh-under(L2) and route-over(L3) routing * The design should be scalable for adding new nodes into the network * The solution should also keep in mind that 6lowpan is a low bW network * The ND design may not necessarily address mobility in boot-strapping and address assignment, but it may be extendable to address mobility in future. * The design will use IPv6 auto-configuration as the main method for address assignment; however stateful address configuration will also be considered Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Aug 11 01:39:26 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D00F3A6C38; Mon, 11 Aug 2008 01:39: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 A9E603A6C06 for <6lowpan@core3.amsl.com>; Mon, 11 Aug 2008 01:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.108 X-Spam-Level: X-Spam-Status: No, score=-5.108 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIreyqKiJdpO for <6lowpan@core3.amsl.com>; Mon, 11 Aug 2008 01:39:24 -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 AB2E83A69DF for <6lowpan@ietf.org>; Mon, 11 Aug 2008 01:39:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,341,1215388800"; d="scan'208,217";a="16773659" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Aug 2008 08:39:17 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7B8dHYs008907 for <6lowpan@ietf.org>; Mon, 11 Aug 2008 10:39:17 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7B8dGfv003046 for <6lowpan@ietf.org>; Mon, 11 Aug 2008 08:39:17 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Aug 2008 10:39:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Aug 2008 10:40:29 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A8601CE530D@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: fragmentation and HC2 Thread-Index: Acj7jeiU7QTFOLE1QGCD3z1KCR8Ggg== From: "Julien Abeille (jabeille)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 11 Aug 2008 08:39:16.0812 (UTC) FILETIME=[BD7D38C0:01C8FB8D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5339; t=1218443957; x=1219307957; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20fragmentation=20and=20HC2 |Sender:=20; bh=PkkJS4HT14AJC14BMgS4UnYUX1Uq4HgIYwBN8YsOotc=; b=k3vMxKFB/Rxz9TvBXwCM/pKF82VOiMEtY0QP6IHRmVe7tDJFDWalUflVXn WDYLDhVPwZPF6YhNhY+yRC1d5atSXEcpMprJGt4p5bUKc0nuF3ZYYzpzwvLX c9hdrNMWyK; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [6lowpan] fragmentation and HC2 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="===============0345047699==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0345047699== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8FB8D.BD7E187A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FB8D.BD7E187A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a question regarding the use of HC2 together with fragmentation in RFC4944: When sending a large fully compressable UDP packet, must all fragments contain HC_UDP encoding, or only the first one? =20 i.e., if the IP packet has flow label and traffic class =3D 0, payload length inferred from L2, next header =3D UDP, source and destination addresses link local with interface identifier inferred from L2 addresses, UDP length inferred from IP length field , and I need 2 fragments: =20 In all cases, fragment 1 should look like : FRAG1 dispatch, datagram size and tag | HC1 dispatch | HC1 encoding =3D 0xFB | HC2encoding | IPv6 hop limit | compressed source and dest UDP ports | UDP checksum | beginning of UDP payload =20 Does fragment 2 look like: FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 encoding =3D 0xFB | HC2encoding | IPv6 hop limit | compressed source and dest UDP port | UDP checksum | rest of UDP payload or=20 FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 encoding =3D0x FA | IPv6 hop limit | rest of UDP payload =20 Thank you, Julien ------_=_NextPart_001_01C8FB8D.BD7E187A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have a=20 question regarding the use of HC2 together with fragmentation in=20 RFC4944:
When = sending a large=20 fully compressable UDP packet, must all fragments contain HC_UDP = encoding, or=20 only the first one?
 
i.e.,  if the IP packet has flow = label and=20 traffic class =3D 0, payload length inferred from L2, next header =3D = UDP, source=20 and destination addresses link local with interface = identifier inferred=20 from L2 addresses, UDP length inferred from IP length field , and  I need=20 2 fragments:
 
In all cases,=20 fragment 1 should look like :
FRAG1 = dispatch, datagram size and tag | HC1 dispatch | HC1 = encoding =3D 0xFB=20 | HC2encoding | IPv6 hop limit | compressed source and dest = UDP ports=20 | UDP checksum | beginning of UDP payload
 
Does fragment 2 look=20 like:
FRAGN dispatch,=20 datagram size, tag and offset | HC1 dispatch | HC1 = encoding =3D 0xFB |=20 HC2encoding | IPv6 hop limit | compressed source and dest UDP = port |=20 UDP checksum | rest of UDP payload
or=20
FRAGN = dispatch, datagram size, tag and offset=20 | HC1 dispatch | HC1 encoding =3D0x FA | = IPv6 hop=20 limit | rest of UDP payload
 
Thank=20 you,
Julien
------_=_NextPart_001_01C8FB8D.BD7E187A-- --===============0345047699== 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 --===============0345047699==-- From 6lowpan-bounces@ietf.org Mon Aug 11 09:39:26 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7BE83A6942; Mon, 11 Aug 2008 09:39: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 C47E83A6942 for <6lowpan@core3.amsl.com>; Mon, 11 Aug 2008 09:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xS-UYOBgWg2r for <6lowpan@core3.amsl.com>; Mon, 11 Aug 2008 09:39:25 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 29EF43A6801 for <6lowpan@ietf.org>; Mon, 11 Aug 2008 09:39:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id CC6C6AF8BB; Mon, 11 Aug 2008 09:39:27 -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 BB-Pa7jmLLdx; Mon, 11 Aug 2008 09:39:27 -0700 (PDT) Received: from [192.168.7.78] (unknown [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 4DFAAAF85E; Mon, 11 Aug 2008 09:39:27 -0700 (PDT) Message-Id: <2A04A3C6-88B1-4204-8F91-6EEF55492E0F@archrock.com> From: Jonathan Hui To: Julien Abeille (jabeille) In-Reply-To: <38F26F36EAA981478A49D1F37F474A8601CE530D@xmb-ams-33d.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 11 Aug 2008 09:39:16 -0700 References: <38F26F36EAA981478A49D1F37F474A8601CE530D@xmb-ams-33d.emea.cisco.com> X-Mailer: Apple Mail (2.926) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] fragmentation and HC2 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="===============0641489090==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============0641489090== Content-Type: multipart/alternative; boundary=Apple-Mail-20--352611751 --Apple-Mail-20--352611751 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote: > Does fragment 2 look like: > FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 > encoding = 0xFB | HC2encoding | IPv6 hop limit | compressed source > and dest UDP port | UDP checksum | rest of UDP payload > or > FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 > encoding =0x FA | IPv6 hop limit | rest of UDP payload Neither. Everything after the frag header is considered part of the fragmented payload. -- Jonathan Hui --Apple-Mail-20--352611751 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

On Aug = 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote:
Does fragment 2 look = like:
=
FRAGN dispatch, datagram size, tag and offset = | HC1 dispatch | HC1 encoding =3D 0xFB | HC2encoding | = IPv6 hop limit | compressed source and dest UDP port | UDP = checksum | rest of UDP payload
=
or=
=
FRAGN dispatch, datagram size, tag and offset = | HC1 dispatch | HC1 encoding =3D0x FA | = IPv6 hop limit | rest of UDP = payload

Neither. Everything after the frag header is = considered part of the fragmented = payload.

--
Jonathan = Hui

= --Apple-Mail-20--352611751-- --===============0641489090== 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 --===============0641489090==-- From 6lowpan-bounces@ietf.org Sat Aug 16 04:48:10 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D803A6B74; Sat, 16 Aug 2008 04:48:10 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD413A68F6 for <6lowpan@core3.amsl.com>; Sat, 16 Aug 2008 04:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POiYGYZKOm+2 for <6lowpan@core3.amsl.com>; Sat, 16 Aug 2008 04:48:07 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8D2623A6AF7 for <6lowpan@ietf.org>; Sat, 16 Aug 2008 04:48:07 -0700 (PDT) Received: from h008115.gprs.dnafinland.fi (h008115.gprs.dnafinland.fi [87.93.8.115]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m7GBlpeG001676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Aug 2008 14:47:53 +0300 Message-ID: <48A56D7F.4020700@sensinode.com> Date: Fri, 15 Aug 2008 14:50:23 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Geoff Mulligan References: <43b91d370808101714h386ebc58j1142a4e15d0c2a6@mail.gmail.com> <1218836878.5949.16.camel@dellx1> In-Reply-To: <1218836878.5949.16.camel@dellx1> Cc: "cabo@tzi.org" , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan ND joint-work goals X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Geoff, At least in my opinion that covers it well, but I think we are fishing for others from the WG to comment. Sorry Geoff, you weren't CCd on my earlier e-mail to the ND team with the first draft and request for comments to proceed. I will forward it to you now. I am now collecting comments on the assumptions and outline of the draft, and then we have some action points to continue with the work. Also split up the work initially, Samita has the goals section e.g. - Zach Geoff Mulligan wrote: > So is this correct? Did Samita summarize the guidelines correctly. > > What is the plan for the design team. > > geoff > > On Sun, 2008-08-10 at 17:14 -0700, Samita Chakrabarti wrote: >> Hi All: >> >> Since we are starting to work on the combined ND solution for 6lowpan, >> as one of the members of the ad-hoc ND team, I thought it would be >> very useful to verify our solution guidelines with the working group. >> I am starting with a few bullet points, please check if that meets our >> (6lowpan wg) requirements. Please feel free to suggest modification >> when it makes sense. >> >> ND Design goals: >> >> >> * Neighbor discovery using IPv6 ND protocol or its variant >> * The solution will use unicast/anycast messages to reduce mulitcast >> * The solution should look into minimizing number of total ND messages >> * Initial boot-strapping information and fault-tolerance should be >> addressed if possible >> * This solution must provide methods for IPv6 address allocation in >> 6lowpan nodes >> * Define a link that serves 6lowpan common deployment >> * The design should work with mesh-under(L2) and route-over(L3) routing >> * The design should be scalable for adding new nodes into the network >> * The solution should also keep in mind that 6lowpan is a low bW network >> * The ND design may not necessarily address mobility in boot-strapping >> and address assignment, but it may be extendable to address >> mobility in future. >> * The design will use IPv6 auto-configuration as the main method for >> address assignment; however stateful address configuration will also >> be considered >> >> >> Thanks, >> -Samita >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Aug 16 14:32:13 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973163A6A01; Sat, 16 Aug 2008 14:32:13 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF1C3A6A5E for <6lowpan@core3.amsl.com>; Sat, 16 Aug 2008 00:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvsNaVwMOBsn for <6lowpan@core3.amsl.com>; Sat, 16 Aug 2008 00:20:28 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 3F8B43A6938 for <6lowpan@ietf.org>; Sat, 16 Aug 2008 00:20:27 -0700 (PDT) Received: from [10.100.24.35] (fbext.rkmc.com [206.169.242.254]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id m7FLm3gL013985; Fri, 15 Aug 2008 15:48:04 -0600 (MDT) From: Geoff Mulligan To: Samita Chakrabarti In-Reply-To: <43b91d370808101714h386ebc58j1142a4e15d0c2a6@mail.gmail.com> References: <43b91d370808101714h386ebc58j1142a4e15d0c2a6@mail.gmail.com> Date: Fri, 15 Aug 2008 15:47:58 -0600 Message-Id: <1218836878.5949.16.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-Mailman-Approved-At: Sat, 16 Aug 2008 14:32:12 -0700 Cc: "cabo@tzi.org" , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan ND joint-work goals 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 So is this correct? Did Samita summarize the guidelines correctly. What is the plan for the design team. geoff On Sun, 2008-08-10 at 17:14 -0700, Samita Chakrabarti wrote: > Hi All: > > Since we are starting to work on the combined ND solution for 6lowpan, > as one of the members of the ad-hoc ND team, I thought it would be > very useful to verify our solution guidelines with the working group. > I am starting with a few bullet points, please check if that meets our > (6lowpan wg) requirements. Please feel free to suggest modification > when it makes sense. > > ND Design goals: > > > * Neighbor discovery using IPv6 ND protocol or its variant > * The solution will use unicast/anycast messages to reduce mulitcast > * The solution should look into minimizing number of total ND messages > * Initial boot-strapping information and fault-tolerance should be > addressed if possible > * This solution must provide methods for IPv6 address allocation in > 6lowpan nodes > * Define a link that serves 6lowpan common deployment > * The design should work with mesh-under(L2) and route-over(L3) routing > * The design should be scalable for adding new nodes into the network > * The solution should also keep in mind that 6lowpan is a low bW network > * The ND design may not necessarily address mobility in boot-strapping > and address assignment, but it may be extendable to address > mobility in future. > * The design will use IPv6 auto-configuration as the main method for > address assignment; however stateful address configuration will also > be considered > > > Thanks, > -Samita > _______________________________________________ > 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 Aug 18 10:19:41 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473FD3A698D; Mon, 18 Aug 2008 10:19: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 40A8C3A6B3B for <6lowpan@core3.amsl.com>; Mon, 18 Aug 2008 10:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.879 X-Spam-Level: X-Spam-Status: No, score=0.879 tagged_above=-999 required=5 tests=[AWL=-1.206, BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172, IP_NOT_FRIENDLY=0.334] 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 wWKfVQA4UWsP for <6lowpan@core3.amsl.com>; Mon, 18 Aug 2008 10:19:38 -0700 (PDT) Received: from mail.dustnetworks.com (cust-67-203-88-34.static.o1.com [67.203.88.34]) by core3.amsl.com (Postfix) with ESMTP id 7909E3A6932 for <6lowpan@ietf.org>; Mon, 18 Aug 2008 10:19:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Aug 2008 10:17:57 -0700 Message-ID: <16745BFFDEC5F64BBB094C931862B4951FE0B4@dust-exch-01.dusthq.dust-inc.com> In-Reply-To: <1218836878.5949.16.camel@dellx1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] 6lowpan ND joint-work goals Thread-Index: Acj/55Fj3ipbTr7IQi6Me5AOF8TQnABbQT/Q From: "Chol Su Kang" To: "Samita Chakrabarti" Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan ND joint-work goals 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 Samita, I have questions on > * Define a link that serves 6lowpan common deployment Has there been any discussion on this 6lowpan common deployment link? Chol Su Kang -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Geoff Mulligan Sent: Friday, August 15, 2008 2:48 PM To: Samita Chakrabarti Cc: cabo@tzi.org; 6lowpan Subject: Re: [6lowpan] 6lowpan ND joint-work goals So is this correct? Did Samita summarize the guidelines correctly. What is the plan for the design team. geoff On Sun, 2008-08-10 at 17:14 -0700, Samita Chakrabarti wrote: > Hi All: > > Since we are starting to work on the combined ND solution for 6lowpan, > as one of the members of the ad-hoc ND team, I thought it would be > very useful to verify our solution guidelines with the working group. > I am starting with a few bullet points, please check if that meets our > (6lowpan wg) requirements. Please feel free to suggest modification > when it makes sense. > > ND Design goals: > > > * Neighbor discovery using IPv6 ND protocol or its variant > * The solution will use unicast/anycast messages to reduce mulitcast > * The solution should look into minimizing number of total ND messages > * Initial boot-strapping information and fault-tolerance should be > addressed if possible > * This solution must provide methods for IPv6 address allocation in > 6lowpan nodes > * Define a link that serves 6lowpan common deployment > * The design should work with mesh-under(L2) and route-over(L3) routing > * The design should be scalable for adding new nodes into the network > * The solution should also keep in mind that 6lowpan is a low bW network > * The ND design may not necessarily address mobility in boot-strapping > and address assignment, but it may be extendable to address > mobility in future. > * The design will use IPv6 auto-configuration as the main method for > address assignment; however stateful address configuration will also > be considered > > > Thanks, > -Samita > _______________________________________________ > 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 Aug 18 10:36:12 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0DEA3A694A; Mon, 18 Aug 2008 10:36: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 B536E3A6A63 for <6lowpan@core3.amsl.com>; Mon, 18 Aug 2008 10:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9ArfH4BRCjR for <6lowpan@core3.amsl.com>; Mon, 18 Aug 2008 10:36:07 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 794083A67A8 for <6lowpan@ietf.org>; Mon, 18 Aug 2008 10:36:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,229,1217808000"; d="scan'208,217";a="17916269" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2008 17:35:42 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7IHZgC1016772; Mon, 18 Aug 2008 13:35:42 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7IHZg0M019959; Mon, 18 Aug 2008 17:35:42 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Aug 2008 13:35:42 -0400 Received: from 10.61.65.79 ([10.61.65.79]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Aug 2008 17:35:41 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 18 Aug 2008 19:35:41 +0200 From: JP Vasseur To: Jonathan Hui , "Julien Abeille (jabeille)" Message-ID: Thread-Topic: [6lowpan] fragmentation and HC2 Thread-Index: AckBWNWmUKfevQ6GrkapOFz3N4CmQA== In-Reply-To: <2A04A3C6-88B1-4204-8F91-6EEF55492E0F@archrock.com> Mime-version: 1.0 X-OriginalArrivalTime: 18 Aug 2008 17:35:42.0393 (UTC) FILETIME=[D67B6290:01C90158] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3351; t=1219080942; x=1219944942; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20fragmentation=20and=20HC2 |Sender:=20 |To:=20Jonathan=20Hui=20,=0A=20=20=20=20 =20=20=20=20=22Julien=20Abeille=20=20=20(jabeille)=22=20; bh=3K2RH4LsZhtyublnqp7oMT6IQnw3VaLrzvF4kKNM+RI=; b=kQIsBkhygxqjI1FIu7Fwd8Y/5rn+aRtAUCIkPuetZPlAOV8igVVlvi8u2h CV72Kd8f83m5lRebr0DxIt5NKPDt+3gk6Oxcg+8TdLblD/83a+bQfaVPVQMy epWsAsHs2o; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] fragmentation and HC2 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="===============1982798092==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1982798092== Content-type: multipart/alternative; boundary="B_3301932941_27145888" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3301932941_27145888 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Which requires a mesh under solution and does not work with route over .... Thanks. JP. On 8/11/08 6:39 PM, "Jonathan Hui" wrote: > > On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote: >> Does fragment 2 look like: >> >> >> FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 encoding = >> 0xFB | HC2encoding | IPv6 hop limit | compressed source and dest UDP port | >> UDP checksum | rest of UDP payload >> >> or >> >> >> FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 encoding >> =0x FA | IPv6 hop limit | rest of UDP payload > > Neither. Everything after the frag header is considered part of the fragmented > payload. > > -- > Jonathan Hui > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --B_3301932941_27145888 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [6lowpan] fragmentation and HC2 Which requires a mesh under solution and does not work with route over ...= .

Thanks.

JP.


On 8/11/08 6:39 PM, "Jonathan Hui" <jhui@archrock.com> wrote:

<= SPAN STYLE=3D'font-size:13pt'>
On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote:
D= oes fragment 2 look like:
 
FRAGN dispatch, datagram size, tag and offset | H= C1 dispatch | HC1 encoding =3D 0xFB | HC2encoding | IPv6 hop limit | compresse= d source and dest UDP port | UDP checksum | rest of UDP payload
or

 
FRAGN dispatch, datagram size, tag and offset | H= C1 dispatch | HC1 encoding =3D0x FA | IPv6 hop limit | rest of UDP payload

Neither. Everything after the frag header is considered part of the fragmen= ted payload.

--
Jonathan Hui


___________= ____________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.or= g/mailman/listinfo/6lowpan
--B_3301932941_27145888-- --===============1982798092== 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 --===============1982798092==-- From 6lowpan-bounces@ietf.org Mon Aug 18 10:46:00 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E013A6D57; Mon, 18 Aug 2008 10:45:59 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C353A6D5F for <6lowpan@core3.amsl.com>; Mon, 18 Aug 2008 10:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW413mLUFo3M for <6lowpan@core3.amsl.com>; Mon, 18 Aug 2008 10:45:41 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 2115F3A6D49 for <6lowpan@ietf.org>; Mon, 18 Aug 2008 10:45:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id ACEDEAF87A; Mon, 18 Aug 2008 10:45:45 -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 6vU1aAAyXXqq; Mon, 18 Aug 2008 10:45:45 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 1D3FEAF859; Mon, 18 Aug 2008 10:45:45 -0700 (PDT) Message-Id: From: Jonathan Hui To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 18 Aug 2008 10:45:44 -0700 References: X-Mailer: Apple Mail (2.926) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] fragmentation and HC2 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="===============0356787954==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============0356787954== Content-Type: multipart/alternative; boundary=Apple-Mail-5-256175709 --Apple-Mail-5-256175709 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit There are multiple implementations (route-over and mesh-under) that successfully utilize the current format today. If you want addressing information in each L2 fragment, then forward at L2. If you want to forward everything at L3, then fragment hop-by-hop. L3 routing is agnostic to the specific layer that forwarding occurs. -- Jonathan Hui On Aug 18, 2008, at 10:35 AM, JP Vasseur wrote: > Which requires a mesh under solution and does not work with route > over .... > > Thanks. > > JP. > > > On 8/11/08 6:39 PM, "Jonathan Hui" wrote: > >> >> On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote: >>> Does fragment 2 look like: >>> >>> >>> FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 >>> encoding = 0xFB | HC2encoding | IPv6 hop limit | compressed source >>> and dest UDP port | UDP checksum | rest of UDP payload >>> >>> or >>> >>> >>> FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 >>> encoding =0x FA | IPv6 hop limit | rest of UDP payload >> >> Neither. Everything after the frag header is considered part of the >> fragmented payload. >> >> -- >> Jonathan Hui >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan --Apple-Mail-5-256175709 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

There are = multiple implementations (route-over and mesh-under) that successfully = utilize the current format today. If you want addressing information in = each L2 fragment, then forward at L2. If you want to forward everything = at L3, then fragment hop-by-hop. L3 routing is agnostic to the specific = layer that forwarding occurs.

--
Jonathan = Hui



On Aug 18, = 2008, at 10:35 AM, JP Vasseur wrote:

= Which requires a mesh under solution and does = not work with route over ....

Thanks.

JP.

=
On 8/11/08 6:39 PM, "Jonathan Hui" <jhui@archrock.com> wrote:

=

On Aug 11, 2008, = at 1:40 AM, Julien Abeille (jabeille) wrote:
=
Does fragment 2 look = like:
=  
FRAGN dispatch, datagram size, = tag and offset | HC1 dispatch | HC1 encoding =3D 0xFB | HC2encoding | = IPv6 hop limit | compressed source and dest UDP port | UDP checksum | = rest of UDP payload
or

 
= FRAGN dispatch, datagram size, tag and = offset | HC1 dispatch | HC1 encoding =3D0x FA | IPv6 hop limit | rest of = UDP payload

Neither. Everything after the frag header is considered part = of the fragmented payload.

--
Jonathan Hui


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

= --Apple-Mail-5-256175709-- --===============0356787954== 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 --===============0356787954==-- From 6lowpan-bounces@ietf.org Mon Aug 18 10:53:01 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40DA83A6A63; Mon, 18 Aug 2008 10:53:01 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B0A3A6A63 for <6lowpan@core3.amsl.com>; Mon, 18 Aug 2008 10:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ll9g-EDHAPvy for <6lowpan@core3.amsl.com>; Mon, 18 Aug 2008 10:52:58 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 7F6C13A6783 for <6lowpan@ietf.org>; Mon, 18 Aug 2008 10:52:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A36FDAF87A; Mon, 18 Aug 2008 10:53:05 -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 N1oIG25eoU+d; Mon, 18 Aug 2008 10:53:05 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id EBA5DAF859; Mon, 18 Aug 2008 10:53:04 -0700 (PDT) Message-Id: <9C418A70-8B6A-4631-A5EF-60FE831222BE@archrock.com> From: Jonathan Hui To: Chol Su Kang In-Reply-To: <16745BFFDEC5F64BBB094C931862B4951FE0B4@dust-exch-01.dusthq.dust-inc.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 18 Aug 2008 10:53:04 -0700 References: <16745BFFDEC5F64BBB094C931862B4951FE0B4@dust-exch-01.dusthq.dust-inc.com> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan ND joint-work goals X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org We did have a lengthy discussion on this topic of an IP link. The issue we focused on was more about whether an IP link spans a single radio hop or multiple radio hops. We've come to a conclusion that it is useful to support both scenarios in the ND solution, and we think there's a way to do it using a unified solution that makes minimal assumptions of the mechanisms provided by layer 2. The key when supporting an IP link that covers multiple radio hops is to avoid multicast. -- Jonathan Hui On Aug 18, 2008, at 10:17 AM, Chol Su Kang wrote: > Hi Samita, > > I have questions on >> * Define a link that serves 6lowpan common deployment > > Has there been any discussion on this 6lowpan common deployment link? > > Chol Su Kang > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Geoff Mulligan > Sent: Friday, August 15, 2008 2:48 PM > To: Samita Chakrabarti > Cc: cabo@tzi.org; 6lowpan > Subject: Re: [6lowpan] 6lowpan ND joint-work goals > > So is this correct? Did Samita summarize the guidelines correctly. > > What is the plan for the design team. > > geoff > > On Sun, 2008-08-10 at 17:14 -0700, Samita Chakrabarti wrote: >> Hi All: >> >> Since we are starting to work on the combined ND solution for >> 6lowpan, >> as one of the members of the ad-hoc ND team, I thought it would be >> very useful to verify our solution guidelines with the working group. >> I am starting with a few bullet points, please check if that meets >> our >> (6lowpan wg) requirements. Please feel free to suggest modification >> when it makes sense. >> >> ND Design goals: >> >> >> * Neighbor discovery using IPv6 ND protocol or its variant >> * The solution will use unicast/anycast messages to reduce mulitcast >> * The solution should look into minimizing number of total ND >> messages >> * Initial boot-strapping information and fault-tolerance should be >> addressed if possible >> * This solution must provide methods for IPv6 address allocation in >> 6lowpan nodes >> * Define a link that serves 6lowpan common deployment >> * The design should work with mesh-under(L2) and route-over(L3) > routing >> * The design should be scalable for adding new nodes into the network >> * The solution should also keep in mind that 6lowpan is a low bW > network >> * The ND design may not necessarily address mobility in > boot-strapping >> and address assignment, but it may be extendable to address >> mobility in future. >> * The design will use IPv6 auto-configuration as the main method for >> address assignment; however stateful address configuration will also >> be considered >> >> >> Thanks, >> -Samita >> _______________________________________________ >> 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 Aug 18 12:10:09 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39E113A6D59; Mon, 18 Aug 2008 12:10:09 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 638D728C1C1 for <6lowpan@core3.amsl.com>; Mon, 18 Aug 2008 12:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUjL9tvKh5Zt for <6lowpan@core3.amsl.com>; Mon, 18 Aug 2008 12:10:02 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 80E823A6CD5 for <6lowpan@ietf.org>; Mon, 18 Aug 2008 12:10:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,229,1217808000"; d="scan'208,217";a="17936441" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2008 19:10:08 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7IJA8w6007486; Mon, 18 Aug 2008 15:10:08 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7IJA8h5009533; Mon, 18 Aug 2008 19:10:08 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Aug 2008 15:10:08 -0400 Received: from 10.61.65.79 ([10.61.65.79]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Aug 2008 19:10:07 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 18 Aug 2008 21:10:03 +0200 From: JP Vasseur To: Jonathan Hui Message-ID: Thread-Topic: [6lowpan] fragmentation and HC2 Thread-Index: AckBZgR3493QAEpfW0S75osj8xZqbg== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 18 Aug 2008 19:10:08.0238 (UTC) FILETIME=[0796B8E0:01C90166] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6274; t=1219086608; x=1219950608; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20fragmentation=20and=20HC2 |Sender:=20 |To:=20Jonathan=20Hui=20; bh=khxRFyvGLWEax1AYdZD74T21nCQvOALqvmudr/ZRN+U=; b=MLXA7z0T86+e1M5hRvsODRayPzlcdmdmfD74XDF3/Z0PouOwTQZ8CZnC02 KXeccL7PcijZUiRD1UReEL/mfUUj8sOYrefzU9UVEJB3GrgCc7lO6IAtFp9l MVZW6ZF794; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] fragmentation and HC2 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="===============1475764103==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1475764103== Content-type: multipart/alternative; boundary="B_3301938604_27508170" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3301938604_27508170 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, On 8/18/08 7:45 PM, "Jonathan Hui" wrote: >=20 > There are multiple implementations (route-over and mesh-under) that > successfully utilize the current format today. If you want addressing > information in each L2 fragment, then forward at L2. If you want to forwa= rd > everything at L3, then fragment hop-by-hop. L3 routing is agnostic to the > specific layer that forwarding occurs. >=20 > JP> this was not Julien=B9s point: depending on how you fragment you may or= you > may not (in this case) be able to route at each hop of course. Without > addressing info in each fragment, this implies L2 forwarding and thus a > mesh-under solution. >=20 > Thanks. >=20 > JP. >=20 > =20 > -- > Jonathan Hui >=20 >=20 > =20 >=20 > On Aug 18, 2008, at 10:35 AM, JP Vasseur wrote: >=20 >> Which requires a mesh under solution and does not work with route over = .... >> =20 >> Thanks. >> =20 >> JP. >> =20 >> =20 >> On 8/11/08 6:39 PM, "Jonathan Hui" wrote: >> =20 >> =20 >>>=20 >>> On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote: >>> =20 >>>> Does fragment 2 look like: >>>> =20 >>>> =20 >>>> FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 >>>> encoding =3D 0xFB | HC2encoding | IPv6 hop limit | compressed source and= dest >>>> UDP port | UDP checksum | rest of UDP payload >>>> =20 >>>> or=20 >>>> =20 >>>> =20 >>>> FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 >>>> encoding =3D0x FA | IPv6 hop limit | rest of UDP payload >>>> =20 >>>=20 >>> Neither. Everything after the frag header is considered part of the >>> fragmented payload. >>> =20 >>> -- >>> Jonathan Hui >>> =20 >>> =20 >>> =20 >>>=20 >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> =20 >> =20 >> =20 >=20 >=20 --B_3301938604_27508170 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [6lowpan] fragmentation and HC2 Hi,


On 8/18/08 7:45 PM, "Jonathan Hui" <jhui@archrock.com> wrote:

<= SPAN STYLE=3D'font-size:13pt'>
There are multiple implementations (route-over and mesh-under) that success= fully utilize the current format today. If you want addressing information i= n each L2 fragment, then forward at L2. If you want to forward everything at= L3, then fragment hop-by-hop. L3 routing is agnostic to the specific layer = that forwarding occurs.

JP> this was not Julien’s point: depending on how you fragment you= may or you may not (in this case) be able to route at each hop of course. W= ithout addressing info in each fragment, this implies L2 forwarding and thus= a mesh-under solution.

Thanks.

JP.

 
--
Jonathan Hui


 

On Aug 18, 2008, at 10:35 AM, JP Vasseur wrote:

<= SPAN STYLE=3D'font-size:13pt'> Which requires a mesh under solution and does n= ot work with route over ....
 
 Thanks.
 
 JP.
 
 
 On 8/11/08 6:39 PM, "Jonathan Hui" <jhui@archrock.com> wrote:
 
 
<= SPAN STYLE=3D'font-size:13pt'>
 On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote:
 
D= oes fragment 2 look like:
 
  
 FRAGN dispatch, datagram size, tag and offs= et | HC1 dispatch | HC1 encoding =3D 0xFB | HC2encoding | IPv6 hop limit | com= pressed source and dest UDP port | UDP checksum | rest of UDP payload
 
 or
 
  
 FRAGN dispatch, datagram size, tag and offs= et | HC1 dispatch | HC1 encoding =3D0x FA | IPv6 hop limit | rest of UDP paylo= ad
 

 Neither. Everything after the frag header is considered part of the f= ragmented payload.
 
 --
 Jonathan Hui
 
 
 
___________= ____________________________________
 6lowpan mailing list
 6lowpan@ietf.org
 https://www.i= etf.org/mailman/listinfo/6lowpan
 

  
=

--B_3301938604_27508170-- --===============1475764103== 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 --===============1475764103==-- From 6lowpan-bounces@ietf.org Mon Aug 18 12:37:33 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC83728C152; Mon, 18 Aug 2008 12:37: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 7B66728C174 for <6lowpan@core3.amsl.com>; Mon, 18 Aug 2008 12:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4a57pnx0JUJR for <6lowpan@core3.amsl.com>; Mon, 18 Aug 2008 12:37:31 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 3CFCC3A6BEB for <6lowpan@ietf.org>; Mon, 18 Aug 2008 12:37:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id BE5A8AF85C; Mon, 18 Aug 2008 12:37: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 u2ZS2WwpVPZ8; Mon, 18 Aug 2008 12:37:37 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id B4AD6AF859; Mon, 18 Aug 2008 12:37:37 -0700 (PDT) Message-Id: <231285CB-9CA0-443B-8302-2187D43734A4@archrock.com> From: Jonathan Hui To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 18 Aug 2008 12:37:36 -0700 References: X-Mailer: Apple Mail (2.926) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] fragmentation and HC2 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="===============1102790608==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1102790608== Content-Type: multipart/alternative; boundary=Apple-Mail-6-262888465 --Apple-Mail-6-262888465 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi JP, I don't think your statement is entirely true. L3 forwarding at each =20 radio hop only requires fragmentation/reassembly at each radio hop. I =20= guess you could argue this is 1-hop mesh under (subsequent fragments =20 know the next-hop destination based on forwarding information from the =20= first fragment), but if you're doing L2 fragmentation, I don't see any =20= way around it. Maybe I'm not understanding your model, so let me try to reiterate it =20= and you can tell me where I'm wrong - you have datagrams fragmented at =20= L2 and you want to forward those fragments at L2 using L3 information. That model seems a bit strange to me and I'm not sure how it would =20 work if you have an IPv6 HBH Options header to process. It would seem =20= cleaner just to say that we're fragmenting at L3. At that point I'd =20 rather just stick a fragmentation header after the L3 addressing =20 information, but then that's starting to look awfully like an IPv6 + =20 fragment header. I know you're trying to find a middle ground so that =20= we can forward fragments using L3 information so that we can avoid hop-=20= by-hop fragmentation/reassembly and not violate the IPv6 min MTU =20 requirement. I'd like to see that too. Is it okay to say that, yes, we =20= are doing L3 fragmentation but that those fragments must be =20 reassembled before exiting the 6lowpan network? -- Jonathan Hui On Aug 18, 2008, at 12:10 PM, JP Vasseur wrote: > Hi, > > > On 8/18/08 7:45 PM, "Jonathan Hui" wrote: > >> >> There are multiple implementations (route-over and mesh-under) that =20= >> successfully utilize the current format today. If you want =20 >> addressing information in each L2 fragment, then forward at L2. If =20= >> you want to forward everything at L3, then fragment hop-by-hop. L3 =20= >> routing is agnostic to the specific layer that forwarding occurs. >> >> JP> this was not Julien=92s point: depending on how you fragment you =20= >> may or you may not (in this case) be able to route at each hop of =20 >> course. Without addressing info in each fragment, this implies L2 =20 >> forwarding and thus a mesh-under solution. >> >> Thanks. >> >> JP. >> >> >> -- >> Jonathan Hui >> >> >> >> >> On Aug 18, 2008, at 10:35 AM, JP Vasseur wrote: >> >>> Which requires a mesh under solution and does not work with route =20= >>> over .... >>> >>> Thanks. >>> >>> JP. >>> >>> >>> On 8/11/08 6:39 PM, "Jonathan Hui" wrote: >>> >>> >>>> >>>> On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote: >>>> >>>>> Does fragment 2 look like: >>>>> >>>>> >>>>> FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | =20= >>>>> HC1 encoding =3D 0xFB | HC2encoding | IPv6 hop limit | compressed =20= >>>>> source and dest UDP port | UDP checksum | rest of UDP payload >>>>> >>>>> or >>>>> >>>>> >>>>> FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | =20= >>>>> HC1 encoding =3D0x FA | IPv6 hop limit | rest of UDP payload >>>>> >>>> >>>> Neither. Everything after the frag header is considered part of =20= >>>> the fragmented payload. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>> >>> >> >> --Apple-Mail-6-262888465 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi = JP,

I don't think your statement is entirely = true. L3 forwarding at each radio hop only requires = fragmentation/reassembly at each radio hop. I guess you could argue this = is 1-hop mesh under (subsequent fragments know the next-hop destination = based on forwarding information from the first fragment), but if you're = doing L2 fragmentation, I don't see any way around = it.

Maybe I'm not understanding your model, so = let me try to reiterate it and you can tell me where I'm wrong - you = have datagrams fragmented at L2 and you want to forward those fragments = at L2 using L3 information.

That model seems a = bit strange to me and I'm not sure how it would work if you have an IPv6 = HBH Options header to process. It would seem cleaner just to say that = we're fragmenting at L3. At that point I'd rather just stick a = fragmentation header after the L3 addressing information, but then = that's starting to look awfully like an IPv6 + fragment = header. I know you're trying to find a middle ground so that we can = forward fragments using L3 information so that we can avoid hop-by-hop = fragmentation/reassembly and not violate the IPv6 min MTU requirement. = I'd like to see that too. Is it okay to say that, yes, we are doing L3 = fragmentation but that those fragments must be reassembled before = exiting the 6lowpan network?

--
Jonathan = Hui



On Aug 18, = 2008, at 12:10 PM, JP Vasseur wrote:

= Hi,


On 8/18/08 7:45 PM, "Jonathan = Hui" <jhui@archrock.com> wrote:
=

There are = multiple implementations (route-over and mesh-under) that successfully = utilize the current format today. If you want addressing information in = each L2 fragment, then forward at L2. If you want to forward everything = at L3, then fragment hop-by-hop. L3 routing is agnostic to the specific = layer that forwarding occurs.

JP> this was not Julien=92s = point: depending on how you fragment you may or you may not (in this = case) be able to route at each hop of course. Without addressing info in = each fragment, this implies L2 forwarding and thus a mesh-under = solution.

Thanks.

JP.

 
= --
Jonathan Hui

=
 

On Aug 18, = 2008, at 10:35 AM, JP Vasseur wrote:

Which requires a mesh under solution and does = not work with route over ....
 
 Thanks.
=  
 JP.
 
 
 On 8/11/08 6:39 PM, = "Jonathan Hui" <jhui@archrock.com> = wrote:
 
 

 On Aug 11, 2008, at 1:40 AM, Julien = Abeille (jabeille) wrote:
 
Does = fragment 2 look like:
 
  
 FRAGN dispatch, datagram size, tag and offset | HC1 = dispatch | HC1 encoding =3D 0xFB | HC2encoding | IPv6 hop limit | = compressed source and dest UDP port | UDP checksum | rest of UDP = payload
 
 or
=  
=   
 FRAGN dispatch, = datagram size, tag and offset | HC1 dispatch | HC1 encoding =3D0x FA | = IPv6 hop limit | rest of UDP payload
 
=

 Neither. = Everything after the frag header is considered part of the fragmented = payload.
 
 --
 Jonathan Hui
 
=  
 
_______________________________________________  6lowpan mailing list
 6lowpan@ietf.org
 https://www.ietf.or= g/mailman/listinfo/6lowpan
 
=

  
=


=
=

= --Apple-Mail-6-262888465-- --===============1102790608== 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 --===============1102790608==-- From 6lowpan-bounces@ietf.org Tue Aug 19 00:57:06 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9C3628B797; Tue, 19 Aug 2008 00:57:06 -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 4C7DE3A69D7 for <6lowpan@core3.amsl.com>; Tue, 19 Aug 2008 00:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYoeoCQ+uu+3 for <6lowpan@core3.amsl.com>; Tue, 19 Aug 2008 00:57:03 -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 1CCD03A69D1 for <6lowpan@ietf.org>; Tue, 19 Aug 2008 00:57:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,234,1217808000"; d="scan'208,217";a="17543298" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Aug 2008 07:56:58 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7J7uwVR015136; Tue, 19 Aug 2008 09:56:58 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7J7uwFK017065; Tue, 19 Aug 2008 07:56:58 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 09:56:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 09:57:59 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A8601D4232D@xmb-ams-33d.emea.cisco.com> In-Reply-To: <231285CB-9CA0-443B-8302-2187D43734A4@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] fragmentation and HC2 Thread-Index: AckBafFyeKD8l85fRGGeb5Wiuq17HAAZtP7g References: <231285CB-9CA0-443B-8302-2187D43734A4@archrock.com> From: "Julien Abeille (jabeille)" To: "Jonathan Hui" , "Jean Philippe Vasseur (jvasseur)" X-OriginalArrivalTime: 19 Aug 2008 07:56:58.0090 (UTC) FILETIME=[2798FCA0:01C901D1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13808; t=1219132618; x=1219996618; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[6lowpan]=20fragmentation=20and=20HC2 |Sender:=20; bh=ZeQgoRnDaKUBtV8Hobjn1CEzAb+EXJ1uAdWZkALZEEQ=; b=SWym/ZVv6tdCKjQTA1YA1ssO5prbEe93pocDTz8uyF/hXXax5t31P+wrQs CnF3xGZ+eCcJ++0sUB2/MwbJ+LVVhAtp8iPWENkUC1sI32WdDUdu+Y2M1JFN FMKtzFDCuU; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] fragmentation and HC2 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="===============0100800797==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0100800797== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C901D1.2774A173" This is a multi-part message in MIME format. ------_=_NextPart_001_01C901D1.2774A173 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jonathan, JP, =20 from a layer perspective, I agree it makes sense in a route over = topology to reassemble at every hop. It also makes sense to use the same = L3 next hop for all fragments, as IP layer will select the next hop, = then ask 6lowpan layer to send, and 6lowpan layer only knows wether = fragmentation is needed, and even that fragmentation exists. =20 However, reassembly at every hop in a route over topology is really bad. = We should think about a solution to the issue, or at least document it = somewhere if we cannot find a way around it.=20 =20 Best, Julien ________________________________ From: Jonathan Hui [mailto:jhui@archrock.com]=20 Sent: lundi 18 ao=FBt 2008 21:38 To: Jean Philippe Vasseur (jvasseur) Cc: Julien Abeille (jabeille); 6lowpan@ietf.org Subject: Re: [6lowpan] fragmentation and HC2 Hi JP, I don't think your statement is entirely true. L3 forwarding at each = radio hop only requires fragmentation/reassembly at each radio hop. I = guess you could argue this is 1-hop mesh under (subsequent fragments = know the next-hop destination based on forwarding information from the = first fragment), but if you're doing L2 fragmentation, I don't see any = way around it. Maybe I'm not understanding your model, so let me try to reiterate it = and you can tell me where I'm wrong - you have datagrams fragmented at = L2 and you want to forward those fragments at L2 using L3 information. That model seems a bit strange to me and I'm not sure how it would work = if you have an IPv6 HBH Options header to process. It would seem cleaner = just to say that we're fragmenting at L3. At that point I'd rather just = stick a fragmentation header after the L3 addressing information, but = then that's starting to look awfully like an IPv6 + fragment header. I = know you're trying to find a middle ground so that we can forward = fragments using L3 information so that we can avoid hop-by-hop = fragmentation/reassembly and not violate the IPv6 min MTU requirement. = I'd like to see that too. Is it okay to say that, yes, we are doing L3 = fragmentation but that those fragments must be reassembled before = exiting the 6lowpan network? -- Jonathan Hui On Aug 18, 2008, at 12:10 PM, JP Vasseur wrote: Hi, =09 =09 On 8/18/08 7:45 PM, "Jonathan Hui" wrote: =09 =09 =09 There are multiple implementations (route-over and mesh-under) that = successfully utilize the current format today. If you want addressing = information in each L2 fragment, then forward at L2. If you want to = forward everything at L3, then fragment hop-by-hop. L3 routing is = agnostic to the specific layer that forwarding occurs. =09 JP> this was not Julien's point: depending on how you fragment you may = or you may not (in this case) be able to route at each hop of course. = Without addressing info in each fragment, this implies L2 forwarding and = thus a mesh-under solution. =09 Thanks. =09 JP. =09 =20 -- Jonathan Hui =09 =09 =20 =09 On Aug 18, 2008, at 10:35 AM, JP Vasseur wrote: =09 =09 Which requires a mesh under solution and does not work with route = over .... =20 Thanks. =20 JP. =20 =20 On 8/11/08 6:39 PM, "Jonathan Hui" wrote: =20 =20 =09 =09 On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote: =20 =09 Does fragment 2 look like: =20 =20 FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 = encoding =3D 0xFB | HC2encoding | IPv6 hop limit | compressed source and = dest UDP port | UDP checksum | rest of UDP payload =20 or=20 =20 =20 FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 = encoding =3D0x FA | IPv6 hop limit | rest of UDP payload =20 =09 =09 Neither. Everything after the frag header is considered part of the = fragmented payload. =20 -- Jonathan Hui =20 =20 =20 =09 ________________________________ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan =20 =09 =09 =20 =09 =09 =09 =09 ------_=_NextPart_001_01C901D1.2774A173 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Jonathan, JP,
 
from a layer perspective, I agree it makes = sense in a route=20 over topology to reassemble at every hop. It also makes sense to use the = same L3=20 next hop for all fragments, as IP layer will select the next hop, then = ask=20 6lowpan layer to send, and 6lowpan layer only knows = wether fragmentation is=20 needed, and even that fragmentation exists.
 
However, reassembly at every hop in a route = over topology=20 is really bad. We should think about a solution to the issue, or at = least=20 document it somewhere if we cannot find a way around=20 it. 
 
Best,
Julien
From: Jonathan Hui = [mailto:jhui@archrock.com]=20
Sent: lundi 18 ao=FBt 2008 21:38
To: Jean Philippe = Vasseur=20 (jvasseur)
Cc: Julien Abeille (jabeille);=20 6lowpan@ietf.org
Subject: Re: [6lowpan] fragmentation and=20 HC2


Hi JP,

I don't think your statement is entirely true. L3 forwarding at = each radio=20 hop only requires fragmentation/reassembly at each radio hop. I guess = you could=20 argue this is 1-hop mesh under (subsequent fragments know the next-hop=20 destination based on forwarding information from the first fragment), = but if=20 you're doing L2 fragmentation, I don't see any way around it.

Maybe I'm not understanding your model, so let me try to reiterate = it and=20 you can tell me where I'm wrong - you have datagrams fragmented at L2 = and you=20 want to forward those fragments at L2 using L3 information.

That model seems a bit strange to me and I'm not sure how it would = work if=20 you have an IPv6 HBH Options header to process. It would seem cleaner = just to=20 say that we're fragmenting at L3. At that point I'd rather just stick a=20 fragmentation header after the L3 addressing information, but then = that's=20 starting to look awfully like an IPv6 + fragment = header. I know=20 you're trying to find a middle ground so that we can forward fragments = using L3=20 information so that we can avoid hop-by-hop fragmentation/reassembly and = not=20 violate the IPv6 min MTU requirement. I'd like to see that too. Is it = okay to=20 say that, yes, we are doing L3 fragmentation but that those fragments = must be=20 reassembled before exiting the 6lowpan network?

--
Jonathan Hui



On Aug 18, 2008, at 12:10 PM, JP Vasseur wrote:
Hi,


On 8/18/08 7:45 PM, "Jonathan = Hui"=20 <jhui@archrock.com>=20 wrote:

There are multiple implementations = (route-over=20 and mesh-under) that successfully utilize the current format today. = If you=20 want addressing information in each L2 fragment, then forward at L2. = If you=20 want to forward everything at L3, then fragment hop-by-hop. L3 = routing is=20 agnostic to the specific layer that forwarding occurs.

JP> = this=20 was not Julien=92s point: depending on how you fragment you may or = you may not=20 (in this case) be able to route at each hop of course. Without = addressing=20 info in each fragment, this implies L2 forwarding and thus a = mesh-under=20 = solution.

Thanks.

JP.

 
--
Jonathan = Hui


 

On Aug 18, 2008, at = 10:35 AM, JP=20 Vasseur wrote:

Which requires a mesh under solution and = does not=20 work with route over=20 = ....
 
 Thanks.
 
 JP.
 
 = ;
 On=20 8/11/08 6:39 PM, "Jonathan Hui" <jhui@archrock.com>=20 wrote:
 
 

 On Aug 11, 2008, at 1:40 AM, = Julien=20 Abeille (jabeille) wrote:
 
Does fragment 2 look like:
 =20
  
 FRAGN = dispatch,=20 datagram size, tag and offset | HC1 dispatch | HC1 encoding = =3D 0xFB |=20 HC2encoding | IPv6 hop limit | compressed source and dest UDP = port |=20 UDP checksum | rest of UDP payload
  =
 or
 =20
  
 FRAGN = dispatch,=20 datagram size, tag and offset | HC1 dispatch | HC1 encoding = =3D0x FA |=20 IPv6 hop limit | rest of UDP=20 payload
 

 Neither. = Everything=20 after the frag header is considered part of the fragmented=20 payload.
 
 --
 Jonathan=20 Hui
 
 
 
_______________________________________________
 6lowpan=20 mailing list
 6lowpan@ietf.org
 https://www.ietf.o= rg/mailman/listinfo/6lowpan
 

  



------_=_NextPart_001_01C901D1.2774A173-- --===============0100800797== 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 --===============0100800797==-- From 6lowpan-bounces@ietf.org Tue Aug 19 08:49:20 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448983A68B1; Tue, 19 Aug 2008 08:49:20 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F307228C0E7 for <6lowpan@core3.amsl.com>; Tue, 19 Aug 2008 07:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP7ryHwKT8vi for <6lowpan@core3.amsl.com>; Tue, 19 Aug 2008 07:03:34 -0700 (PDT) Received: from mailhost.jennic.co.uk (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id 7729128C0E6 for <6lowpan@ietf.org>; Tue, 19 Aug 2008 07:03:33 -0700 (PDT) Received: from [213.143.5.74] (helo=JENLP74) by jendns02.jennic.com with esmtpa (Exim 4.60) (envelope-from ) id 1KUybl-0002hF-Hb; Mon, 18 Aug 2008 07:52:55 +0100 From: "Paul Chilton" To: Date: Mon, 18 Aug 2008 07:52:53 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Importance: Normal Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan ND joint-work goals X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paul.chilton@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Samita This set of design goals looks like it will meet the WG requirements. However, I am not sure I understand the bullet point "Define a link that serves 6lowpan common deployment" Could you expand on what you mean by this? Thanks Paul On Sun, 2008-08-10 at 17:14 -0700, Samita Chakrabarti wrote: > Hi All: > > Since we are starting to work on the combined ND solution for 6lowpan, > as one of the members of the ad-hoc ND team, I thought it would be > very useful to verify our solution guidelines with the working group. > I am starting with a few bullet points, please check if that meets our > (6lowpan wg) requirements. Please feel free to suggest modification > when it makes sense. > > ND Design goals: > > > * Neighbor discovery using IPv6 ND protocol or its variant > * The solution will use unicast/anycast messages to reduce mulitcast > * The solution should look into minimizing number of total ND messages > * Initial boot-strapping information and fault-tolerance should be > addressed if possible > * This solution must provide methods for IPv6 address allocation in > 6lowpan nodes > * Define a link that serves 6lowpan common deployment > * The design should work with mesh-under(L2) and route-over(L3) routing > * The design should be scalable for adding new nodes into the network > * The solution should also keep in mind that 6lowpan is a low bW network > * The ND design may not necessarily address mobility in boot-strapping > and address assignment, but it may be extendable to address > mobility in future. > * The design will use IPv6 auto-configuration as the main method for > address assignment; however stateful address configuration will also > be considered > > > Thanks, > -Samita > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan Paul Chilton Jennic Ltd Furnival Street Sheffield, UK S10 3DX _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Aug 19 22:56:44 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A43B3A69B6; Tue, 19 Aug 2008 22:56: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 DB8A63A6969 for <6lowpan@core3.amsl.com>; Tue, 19 Aug 2008 22:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.136 X-Spam-Level: * X-Spam-Status: No, score=1.136 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QE0vstclBBYu for <6lowpan@core3.amsl.com>; Tue, 19 Aug 2008 22:56:41 -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 3DFBC3A68C0 for <6lowpan@ietf.org>; Tue, 19 Aug 2008 22:56:40 -0700 (PDT) Received: from [10.21.129.119] (cp.64translator.com [202.214.123.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id 9155E16B0C for <6lowpan@ietf.org>; Wed, 20 Aug 2008 14:50:19 +0900 (JST) Message-ID: <48ABB246.70208@tanu.org> Date: Wed, 20 Aug 2008 14:57:26 +0900 From: Shoichi Sakane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] review of the draft of 6lowpan security analysis 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 have read draft-daniel-6lowpan-security-analysis-02.txt carefully. IMHO, the assumptions should be improved, and the goal of this document should be described explicitly at least. After that, we have to list up the items to be analyzed. And, then a few inaccurate descriptions should be corrected. I attached details below. Regards, Shoichi Sakane ==== o the goal of this draft. I haven't understood the goal of this document after I read this draft. It is just analysis of 6lowpan, listing problems, or suggesting a base model to solve 6lowpan security problems, or proposing solutions for specific problem. I felt that any things were included when I read this draft. For example, the description of ND in section 7.2 is a solution. SEND is needed to the wired network similarly, not unique solution for 6lowpan. Here should be described what problem is and what will happen in 6lowpan specific instead of solution. In my personal opinion, this document should just describe the analysis in perspective of 6lowpan. It is better to keep it by describing problem statement even if it is described more. If you want to describe a basic security model or solutions, you need to define the security requirement for 6lowpan. Defining requirements will raise up issues and problems to be defined consequently, otherwise it is not meaning. Aside from volume of the analysis description and accuracy, this draft should cover whole part where a problem may happen as possible. Currently, Gateway/BBR issue is not included. ND issue, there is a description actually, should be into a sole section and should be discussed separately. o the assumptions of this document. The assumptions should be located to the former part of the document in order to clear the scope of this draft. The relationship with the section of the security considerations of the other documents should be described explicitly. I think that the analysis depends on the assumption. For example, the following is related to the result of analysis. - availability of the 802.15.4-2003, or the 802.15.4-2006. - unmanaged network or well-managed network, - the communication range is either within a LoWPAN or interconnection with other networks. - symmetric cryptography, or ECC, or RSA as the constraint of the 6lowpan device. The assumption should be described these condition clearly. Or, the document should analyze 6lowpan according to each condition. o Security Threats I think that this threat description needs improvement. Generic threats of the wireless networks should be removed, leaving some examples, and be referred to some appropriate documents. For example, the following paper describes well. "Secure Routing in Wireless Sensor Networks: Attacks and Countermeasures", C.Karlof and D.Wagner, Sep, 2003. There is a summary of this paper at http://www.tcs.hut.fi/Studies/T-79.194/papers/hietalahti_050427.pdf Here, it is important to describe 6lowpan specific threat. o 6lowpan security analysis I feel that IPsec is inappropriate for 6lowpan after I read the section "IP Security analysis". I never advocate using IPsec. But, the description should be accurate and fair. Asymmetric cryptography is not used in both ESP and AH themselves. So the impact to processing power is not so big. The impact by SSL is similar to IPsec processing after the session key negotiation of SSL. The essence problem is within the key management protocol (KMP). Typical KMP for IPsec is IKE. It is required to use asymmetric cryptography. But, the impact to processing power is also similar to SSL. When ECC is accepted, the impact is not so problem. Furthermore, the impact is mitigated when symmetric cryptography based KMPs like KINK or MIKEY-PSK is used. (Total message size of KINK is typically bigger than IKE's though.) In fact, my team had an experience to implement IPsec with KINK into a embedded device which is on H8/3029 though the device did not support 6lowpan. The most severe issue is to influence into the bandwidth of 6lowpan. Total message size of both IKE and SSL is not so different. Note that the number of exchanging messages of SSL is more than IKE. This draft recommends to use "cluster based dynamic key management scheme". I think that this topic should be separated into another document like key management protocol for 6lowpan. However, the ability to exchange messages between a 6lowpan device and a device of the outside of LoWPAN is probably required in some scenario. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Aug 20 07:09:18 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E0B28C146; Wed, 20 Aug 2008 07:09: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 6FDE128C146 for <6lowpan@core3.amsl.com>; Wed, 20 Aug 2008 07:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.755 X-Spam-Level: X-Spam-Status: No, score=0.755 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWmGyHiseVZk for <6lowpan@core3.amsl.com>; Wed, 20 Aug 2008 07:09:16 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 99C0F3A6B92 for <6lowpan@ietf.org>; Wed, 20 Aug 2008 07:09:16 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so382057rvf.49 for <6lowpan@ietf.org>; Wed, 20 Aug 2008 07:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:x-google-sender-auth; bh=q1SuGK/Qz23LPbifeno9qk/dUa2l7nOu6UQZb4u+scQ=; b=s9DtZpGkDAikPfjeA4oWQQufEQLkPm1zkByUvzybK8hYoL7Q1b40JFUftsGjx8eSzx 0u03Vx+8B6/cyJbJNzEdOPwzj1eewmb2Nta6MOy9KgGJeITZ+tdBHjdWVka72etvcq4H BxRZosyJmV7HtxBJHDe9LeR2p0APL6Eq+gn9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :x-google-sender-auth; b=AAcXFJIyfw2TWNVjY9XVbEKvXgjMWZigYtHSaRDld0A3H2P/KjnRmSMJzfzJlS8HeW 6x4LgkkgvSZ3oXmCufeYJCEpYIVn3JfrV1fSSXgfvoyX4c6Hj6mHYmz4DUeqFcf8Ddqi pQ+EJiERrnJNbXWwll3Mxo5vf5VCFgXYCOL8E= Received: by 10.141.128.19 with SMTP id f19mr54914rvn.257.1219241315090; Wed, 20 Aug 2008 07:08:35 -0700 (PDT) Received: by 10.141.212.9 with HTTP; Wed, 20 Aug 2008 07:08:35 -0700 (PDT) Message-ID: <147a29c80808200708x2c3e37c3nf6fd42e885ab9f6c@mail.gmail.com> Date: Wed, 20 Aug 2008 16:08:35 +0200 From: "Laurent Toutain" To: 6lowpan <6lowpan@ietf.org> MIME-Version: 1.0 X-Google-Sender-Auth: af2652255036ed2c Subject: [6lowpan] RA suppression 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="===============0097726284==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============0097726284== Content-Type: multipart/alternative; boundary="----=_Part_25710_23025533.1219241315078" ------=_Part_25710_23025533.1219241315078 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I've just submitted a draft which defines a way to avoid prefix allocation to the sensor. 6LoWPAN compression avoid to transmit prefix on the link and PAN Coordinator reconstruct IPv6 header and add the prefix. This way RS/RA can be avoided. I would like to have the feeling of the working group on that behavior. The draft can be found at http://www.ietf.org/internet-drafts/draft-toutain-6lowpan-ra-suppression-00.txt Laurent ------=_Part_25710_23025533.1219241315078 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,

I've just submitted a draft which defines a way to avoid prefix allocation to the sensor. 6LoWPAN compression avoid to transmit prefix on the link and PAN Coordinator reconstruct IPv6 header and add the prefix. This way RS/RA can be avoided. I would like to have the feeling of the working group on that behavior.

The draft can be found at http://www.ietf.org/internet-drafts/draft-toutain-6lowpan-ra-suppression-00.txt

Laurent
------=_Part_25710_23025533.1219241315078-- --===============0097726284== 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 --===============0097726284==-- From 6lowpan-bounces@ietf.org Wed Aug 20 08:03:03 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE593A6C10; Wed, 20 Aug 2008 08:03: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 F20EE3A6B5A for <6lowpan@core3.amsl.com>; Wed, 20 Aug 2008 08:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLokJlRrRcoZ for <6lowpan@core3.amsl.com>; Wed, 20 Aug 2008 08:02:56 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id C84253A6BCA for <6lowpan@ietf.org>; Wed, 20 Aug 2008 08:02:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 274E4AF883; Wed, 20 Aug 2008 08:02:25 -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 yD1-kt5Jo1nX; Wed, 20 Aug 2008 08:02:24 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 09986AF85B; Wed, 20 Aug 2008 08:02:24 -0700 (PDT) Message-Id: From: Jonathan Hui To: Julien Abeille (jabeille) In-Reply-To: <38F26F36EAA981478A49D1F37F474A8601D4232D@xmb-ams-33d.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 20 Aug 2008 08:02:23 -0700 References: <231285CB-9CA0-443B-8302-2187D43734A4@archrock.com> <38F26F36EAA981478A49D1F37F474A8601D4232D@xmb-ams-33d.emea.cisco.com> X-Mailer: Apple Mail (2.926) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] fragmentation and HC2 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="===============0876012345==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============0876012345== Content-Type: multipart/alternative; boundary=Apple-Mail-3-419174831 --Apple-Mail-3-419174831 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Julien, On Aug 19, 2008, at 12:57 AM, Julien Abeille (jabeille) wrote: > However, reassembly at every hop in a route over topology is really =20= > bad. Is it? =46rom a network-layer perspective, yes. But from a whole system =20= perspective, it is much less clear. Sending fragments for a datagram =20 along a single path can be advantageous for many reasons. There are a =20= number of dynamic link-layer optimizations that reduce transmit costs, =20= increase throughput, and decrease latency, but, those mechanisms often =20= assume that they can amortize the initial setup costs over multiple =20 subsequent frames. You get to take advantage of the temporal =20 properties of a link. It is feasible to perform hop-by-hop fragment =20 recovery. Fragments arrive in order, making reassembly simpler at the =20= receiver. > We should think about a solution to the issue, or at least document =20= > it somewhere if we cannot find a way around it. Agreed. -- Jonathan Hui > Best, > Julien > From: Jonathan Hui [mailto:jhui@archrock.com] > Sent: lundi 18 ao=FBt 2008 21:38 > To: Jean Philippe Vasseur (jvasseur) > Cc: Julien Abeille (jabeille); 6lowpan@ietf.org > Subject: Re: [6lowpan] fragmentation and HC2 > > > Hi JP, > > I don't think your statement is entirely true. L3 forwarding at each =20= > radio hop only requires fragmentation/reassembly at each radio hop. =20= > I guess you could argue this is 1-hop mesh under (subsequent =20 > fragments know the next-hop destination based on forwarding =20 > information from the first fragment), but if you're doing L2 =20 > fragmentation, I don't see any way around it. > > Maybe I'm not understanding your model, so let me try to reiterate =20 > it and you can tell me where I'm wrong - you have datagrams =20 > fragmented at L2 and you want to forward those fragments at L2 using =20= > L3 information. > > That model seems a bit strange to me and I'm not sure how it would =20 > work if you have an IPv6 HBH Options header to process. It would =20 > seem cleaner just to say that we're fragmenting at L3. At that point =20= > I'd rather just stick a fragmentation header after the L3 addressing =20= > information, but then that's starting to look awfully like an IPv6 + =20= > fragment header. I know you're trying to find a middle ground so =20 > that we can forward fragments using L3 information so that we can =20 > avoid hop-by-hop fragmentation/reassembly and not violate the IPv6 =20 > min MTU requirement. I'd like to see that too. Is it okay to say =20 > that, yes, we are doing L3 fragmentation but that those fragments =20 > must be reassembled before exiting the 6lowpan network? > > -- > Jonathan Hui > > > > On Aug 18, 2008, at 12:10 PM, JP Vasseur wrote: > >> Hi, >> >> >> On 8/18/08 7:45 PM, "Jonathan Hui" wrote: >> >>> >>> There are multiple implementations (route-over and mesh-under) =20 >>> that successfully utilize the current format today. If you want =20 >>> addressing information in each L2 fragment, then forward at L2. If =20= >>> you want to forward everything at L3, then fragment hop-by-hop. L3 =20= >>> routing is agnostic to the specific layer that forwarding occurs. >>> >>> JP> this was not Julien=92s point: depending on how you fragment you = =20 >>> may or you may not (in this case) be able to route at each hop of =20= >>> course. Without addressing info in each fragment, this implies L2 =20= >>> forwarding and thus a mesh-under solution. >>> >>> Thanks. >>> >>> JP. >>> >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> >>> On Aug 18, 2008, at 10:35 AM, JP Vasseur wrote: >>> >>>> Which requires a mesh under solution and does not work with route =20= >>>> over .... >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> >>>> On 8/11/08 6:39 PM, "Jonathan Hui" wrote: >>>> >>>> >>>>> >>>>> On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote: >>>>> >>>>>> Does fragment 2 look like: >>>>>> >>>>>> >>>>>> FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | =20= >>>>>> HC1 encoding =3D 0xFB | HC2encoding | IPv6 hop limit | compressed = =20 >>>>>> source and dest UDP port | UDP checksum | rest of UDP payload >>>>>> >>>>>> or >>>>>> >>>>>> >>>>>> FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | =20= >>>>>> HC1 encoding =3D0x FA | IPv6 hop limit | rest of UDP payload >>>>>> >>>>> >>>>> Neither. Everything after the frag header is considered part of =20= >>>>> the fragmented payload. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>> >>>> >>>> >>> >>> > --Apple-Mail-3-419174831 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi = Julien,

On Aug 19, = 2008, at 12:57 AM, Julien Abeille (jabeille) wrote:
However, reassembly at every hop in a route = over topology is really bad. =

Is it? =46rom = a network-layer perspective, yes. But from a whole system perspective, = it is much less clear. Sending fragments for a datagram along a single = path can be advantageous for many reasons. There are a number of dynamic = link-layer optimizations that reduce transmit costs, increase = throughput, and decrease latency, but, those mechanisms often assume = that they can amortize the initial setup costs over multiple subsequent = frames. You get to take advantage of the temporal properties of a link. = It is feasible to perform hop-by-hop fragment recovery. Fragments arrive = in order, making reassembly simpler at the = receiver.

We should think about a solution to the issue, or at = least document it somewhere if we cannot find a way around = it. 

Agreed= .

--
Jonathan = Hui

Best,
Julien
=
From: Jonathan Hui [mailto:jhui@archrock.com] =
Sent: lundi 18 ao=FBt 2008 21:38
To: Jean Philippe = Vasseur (jvasseur)
Cc: Julien Abeille (jabeille); 6lowpan@ietf.org
Subject: = Re: [6lowpan] fragmentation and HC2

=

Hi JP,

I don't think = your statement is entirely true. L3 forwarding at each radio hop only = requires fragmentation/reassembly at each radio hop. I guess you could = argue this is 1-hop mesh under (subsequent fragments know the next-hop = destination based on forwarding information from the first fragment), = but if you're doing L2 fragmentation, I don't see any way around = it.

Maybe I'm not understanding your model, = so let me try to reiterate it and you can tell me where I'm wrong - you = have datagrams fragmented at L2 and you want to forward those fragments = at L2 using L3 information.

That model seems = a bit strange to me and I'm not sure how it would work if you have an = IPv6 HBH Options header to process. It would seem cleaner just to say = that we're fragmenting at L3. At that point I'd rather just stick a = fragmentation header after the L3 addressing information, but then = that's starting to look awfully like an IPv6 + fragment = header. I know you're trying to find a middle ground so that we can = forward fragments using L3 information so that we can avoid hop-by-hop = fragmentation/reassembly and not violate the IPv6 min MTU requirement. = I'd like to see that too. Is it okay to say that, yes, we are doing L3 = fragmentation but that those fragments must be reassembled before = exiting the 6lowpan network?

--
Jonathan = Hui



On Aug 18, = 2008, at 12:10 PM, JP Vasseur wrote:

=
Hi,


On 8/18/08 7:45 PM, "Jonathan = Hui" <jhui@archrock.com> = wrote:

There are multiple implementations (route-over and = mesh-under) that successfully utilize the current format today. If you = want addressing information in each L2 fragment, then forward at L2. = If you want to forward everything at L3, then fragment hop-by-hop. = L3 routing is agnostic to the specific layer that forwarding = occurs.

JP> this was not Julien=92s point: depending on how = you fragment you may or you may not (in this case) be able to route = at each hop of course. Without addressing info in each fragment, = this implies L2 forwarding and thus a mesh-under = solution.

Thanks.

JP.

 
--
Jonathan = Hui


 

On = Aug 18, 2008, at 10:35 AM, JP Vasseur wrote:

 =
Which requires a mesh under = solution and does not work with route over = ....
 
 Thanks.
 
 JP.
 
 =
 On 8/11/08 6:39 PM, "Jonathan Hui" <jhui@archrock.com> = wrote:
 
 

 On Aug 11, 2008, at 1:40 AM, Julien = Abeille (jabeille) wrote:
 
 =
Does fragment 2 look like:
  =
  
 FRAGN dispatch, = datagram size, tag and offset | HC1 dispatch | HC1 encoding =3D = 0xFB | HC2encoding | IPv6 hop limit | compressed source and = dest UDP port | UDP checksum | rest of UDP = payload
 
 or
  =
  
 FRAGN dispatch, = datagram size, tag and offset | HC1 dispatch | HC1 encoding =3D0x = FA | IPv6 hop limit | rest of UDP = payload
 

 Neither. Everything after the frag header is = considered part of the fragmented = payload.
 
 --
 Jonathan = Hui
 
 
 
_______________________________________________
 6lowpan = mailing list
 6lowpan@ietf.org
 https://www.ietf.or= g/mailman/listinfo/6lowpan
 

  




= --Apple-Mail-3-419174831-- --===============0876012345== 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 --===============0876012345==-- From 6lowpan-bounces@ietf.org Mon Aug 25 09:44:54 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3313A6956; Mon, 25 Aug 2008 09: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 E5F543A6823 for <6lowpan@core3.amsl.com>; Mon, 25 Aug 2008 09:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbrF5ENyaqP1 for <6lowpan@core3.amsl.com>; Mon, 25 Aug 2008 09:44:44 -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 4E4E13A67FC for <6lowpan@ietf.org>; Mon, 25 Aug 2008 09:44:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,265,1217808000"; d="scan'208,217";a="18171723" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Aug 2008 16:44:22 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7PGiMw3016260; Mon, 25 Aug 2008 18:44:22 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7PGiMtc028346; Mon, 25 Aug 2008 16:44:22 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, 25 Aug 2008 18:44:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 18:43:48 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC061F2530@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] fragmentation and HC2 Thread-Index: AckC1g0vK2YNApdsS1yBxhDHnvZ1IgD+sOEA References: <231285CB-9CA0-443B-8302-2187D43734A4@archrock.com><38F26F36EAA981478A49D1F37F474A8601D4232D@xmb-ams-33d.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Julien Abeille (jabeille)" X-OriginalArrivalTime: 25 Aug 2008 16:44:22.0323 (UTC) FILETIME=[D3824030:01C906D1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=26556; t=1219682662; x=1220546662; 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]=20fragmentation=20and=20HC2 |Sender:=20; bh=QSLL2LxDlMPbjPNa/Wsg7ylf4ha98SgqOyIYc4kSCYI=; b=Xkwq0uzvlSWlK09g6m403Smpi+LjhVPDiUmEKVeQj/XpYeHMxJUd7hDnvW R2ZS50kiZIEX6fuZHiVRN/CL1wDLO3JzEfXlDbTFkVQ7jmDNsif8uiLnv9Hi vnNFH4KzhW; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] fragmentation and HC2 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="===============0637902334==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0637902334== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C906D1.D36E5C44" This is a multi-part message in MIME format. ------_=_NextPart_001_01C906D1.D36E5C44 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi: =20 I'm just back fro vacations so I jump in late in this discussion. We = discussed this already in the "[6lowpan] Mesh-header, do we need it = anymore?" thread.=20 Please review what was discussed there. My understanding Is that today, = we need to expand the packets at each L3 hop, which includes recomposing = when there are fragments but is costly even when the packet is not = fragmented. I'd wish to actually work on forwarding the compressed form when we can, = fragmented or not. This is not possible today but could be done if we = had a (compressed) routing header and/or could use 16bit addresses as = labels. =20 Pascal ________________________________ From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Jonathan Hui Sent: mercredi 20 ao=FBt 2008 17:02 To: Julien Abeille (jabeille) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] fragmentation and HC2 =20 =20 Hi Julien, =20 On Aug 19, 2008, at 12:57 AM, Julien Abeille (jabeille) wrote: However, reassembly at every hop in a route over topology is really = bad.=20 =20 Is it? From a network-layer perspective, yes. But from a whole system = perspective, it is much less clear. Sending fragments for a datagram = along a single path can be advantageous for many reasons. There are a = number of dynamic link-layer optimizations that reduce transmit costs, = increase throughput, and decrease latency, but, those mechanisms often = assume that they can amortize the initial setup costs over multiple = subsequent frames. You get to take advantage of the temporal properties = of a link. It is feasible to perform hop-by-hop fragment recovery. = Fragments arrive in order, making reassembly simpler at the receiver. We should think about a solution to the issue, or at least document it = somewhere if we cannot find a way around it.=20 =20 Agreed. =20 -- Jonathan Hui =20 =09 Best, Julien =09 ________________________________ From: Jonathan Hui [mailto:jhui@archrock.com]=20 Sent: lundi 18 ao=FBt 2008 21:38 To: Jean Philippe Vasseur (jvasseur) Cc: Julien Abeille (jabeille); 6lowpan@ietf.org Subject: Re: [6lowpan] fragmentation and HC2 =20 Hi JP, =20 I don't think your statement is entirely true. L3 forwarding at each = radio hop only requires fragmentation/reassembly at each radio hop. I = guess you could argue this is 1-hop mesh under (subsequent fragments = know the next-hop destination based on forwarding information from the = first fragment), but if you're doing L2 fragmentation, I don't see any = way around it. =20 Maybe I'm not understanding your model, so let me try to reiterate it = and you can tell me where I'm wrong - you have datagrams fragmented at = L2 and you want to forward those fragments at L2 using L3 information. =20 That model seems a bit strange to me and I'm not sure how it would work = if you have an IPv6 HBH Options header to process. It would seem cleaner = just to say that we're fragmenting at L3. At that point I'd rather just = stick a fragmentation header after the L3 addressing information, but = then that's starting to look awfully like an IPv6 + fragment header. I = know you're trying to find a middle ground so that we can forward = fragments using L3 information so that we can avoid hop-by-hop = fragmentation/reassembly and not violate the IPv6 min MTU requirement. = I'd like to see that too. Is it okay to say that, yes, we are doing L3 = fragmentation but that those fragments must be reassembled before = exiting the 6lowpan network? =20 =09 -- Jonathan Hui =20 =20 =20 On Aug 18, 2008, at 12:10 PM, JP Vasseur wrote: =09 =09 =09 Hi, =09 =09 On 8/18/08 7:45 PM, "Jonathan Hui" wrote: =09 =09 =09 =09 There are multiple implementations (route-over and mesh-under) that = successfully utilize the current format today. If you want addressing = information in each L2 fragment, then forward at L2. If you want to = forward everything at L3, then fragment hop-by-hop. L3 routing is = agnostic to the specific layer that forwarding occurs. =09 JP> this was not Julien's point: depending on how you fragment you may = or you may not (in this case) be able to route at each hop of course. = Without addressing info in each fragment, this implies L2 forwarding and = thus a mesh-under solution. =09 Thanks. =09 JP. =09 =20 -- Jonathan Hui =09 =09 =20 =09 On Aug 18, 2008, at 10:35 AM, JP Vasseur wrote: =09 =09 =09 Which requires a mesh under solution and does not work with route over = .... =20 Thanks. =20 JP. =20 =20 On 8/11/08 6:39 PM, "Jonathan Hui" wrote: =20 =20 =09 =09 =09 On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote: =20 =09 =09 Does fragment 2 look like: =20 =20 FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 = encoding =3D 0xFB | HC2encoding | IPv6 hop limit | compressed source and = dest UDP port | UDP checksum | rest of UDP payload =20 or=20 =20 =20 FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 = encoding =3D0x FA | IPv6 hop limit | rest of UDP payload =20 =09 Neither. Everything after the frag header is considered part of the = fragmented payload. =20 -- Jonathan Hui =20 =20 =20 =09 ________________________________ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan =20 =09 =20 =20 =20 =20 ------_=_NextPart_001_01C906D1.D36E5C44 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi:

 

I’m just back fro vacations = so I jump in late in this discussion. We discussed this already in the = “[6lowpan] Mesh-header, do we need it = anymore?” thread.

Please review what was discussed = there. My understanding Is that today, we need to expand the packets at each L3 = hop, which includes recomposing when there are fragments but is costly even = when the packet is not fragmented.

I’d wish to actually work on = forwarding the compressed form when we can, fragmented or not. This is not possible = today but could be done if we had a (compressed) routing header and/or could = use 16bit addresses as labels.

 

Pascal

From: = 6lowpan-bounces@ietf.org = [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui
Sent: mercredi 20 ao=FBt = 2008 17:02
To: Julien Abeille = (jabeille)
Cc: 6lowpan@ietf.org
Subject: Re: = [6lowpan] fragmentation and = HC2

 

 

Hi = Julien,

 

On Aug 19, 2008, at 12:57 AM, Julien Abeille (jabeille) = wrote:

However, reassembly at every hop in = a route over topology is really bad.

 

Is it? From a network-layer perspective, yes. But from a whole = system perspective, it is much less clear. Sending fragments for a datagram = along a single path can be advantageous for many reasons. There are a number of = dynamic link-layer optimizations that reduce transmit costs, increase = throughput, and decrease latency, but, those mechanisms often assume that they can = amortize the initial setup costs over multiple subsequent frames. You get to take = advantage of the temporal properties of a link. It is feasible to perform = hop-by-hop fragment recovery. Fragments arrive in order, making reassembly simpler = at the receiver.



We should think about = a solution to the issue, or at least document it somewhere if we cannot find a way = around it. 

 

Agreed.

 

--

Jonathan Hui

 

Best,

Julien

From: Jonathan Hui [mailto:jhui@archrock.com] =
Sent: lundi 18 ao=FBt = 2008 21:38
To: Jean Philippe Vasseur (jvasseur)
Cc: Julien Abeille = (jabeille); 6lowpan@ietf.org
Subject: Re: = [6lowpan] fragmentation and = HC2

 

Hi JP,

 

I don't think your statement is entirely true. L3 forwarding at = each radio hop only requires fragmentation/reassembly at each radio hop. I = guess you could argue this is 1-hop mesh under (subsequent fragments know the = next-hop destination based on forwarding information from the first fragment), = but if you're doing L2 fragmentation, I don't see any way around = it.

 

Maybe I'm not understanding your model, so let me try to = reiterate it and you can tell me where I'm wrong - you have datagrams fragmented at = L2 and you want to forward those fragments at L2 using L3 = information.

 

That model seems a bit strange to me and I'm not sure how it = would work if you have an IPv6 HBH Options header to process. It would seem cleaner = just to say that we're fragmenting at L3. At that point I'd rather just stick = a fragmentation header after the L3 addressing information, but then = that's starting to look awfully like an IPv6 + fragment = header. I know you're trying to find a middle ground so that we can forward fragments = using L3 information so that we can avoid hop-by-hop fragmentation/reassembly and = not violate the IPv6 min MTU requirement. I'd like to see that too. Is it = okay to say that, yes, we are doing L3 fragmentation but that those fragments = must be reassembled before exiting the 6lowpan network?

 

--=

Jonathan = Hui

 

 

 

On Aug 18, 2008, at 12:10 PM, JP Vasseur = wrote:



Hi,


On 8/18/08 7:45 PM, "Jonathan Hui" <jhui@archrock.com> wrote:



There are multiple implementations (route-over and mesh-under) that successfully utilize the current format today. If you want addressing information in each L2 fragment, then forward at L2. If you want to = forward everything at L3, then fragment hop-by-hop. L3 routing is agnostic to = the specific layer that forwarding occurs.

JP> this was not Julien’s point: depending on how you fragment = you may or you may not (in this case) be able to route at each hop of course. = Without addressing info in each fragment, this implies L2 forwarding and thus a mesh-under solution.

Thanks.

JP.

 
--
Jonathan Hui


 

On Aug 18, 2008, at 10:35 AM, JP Vasseur wrote:


Which requires a mesh under solution and does not = work with route over ....
 
 Thanks.
 
 JP.
 
 
 On 8/11/08 6:39 PM, "Jonathan Hui" <jhui@archrock.com> wrote:
 
 


 On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote:
 

Does fragment 2 look like:
 
  
 FRAGN dispatch, datagram size, tag and offset | HC1 = dispatch | HC1 encoding =3D 0xFB | HC2encoding | IPv6 hop limit | compressed = source and dest UDP port | UDP checksum | rest of UDP payload
 
 or
 
  
 FRAGN dispatch, datagram size, tag and offset | HC1 = dispatch | HC1 encoding =3D0x FA | IPv6 hop limit | rest of UDP payload
 


 Neither. Everything after the frag header is considered part of = the fragmented payload.
 
 --
 Jonathan Hui
 
 
 

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


  

 

 

 

------_=_NextPart_001_01C906D1.D36E5C44-- --===============0637902334== 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 --===============0637902334==-- From 6lowpan-bounces@ietf.org Tue Aug 26 03:30:13 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063923A6A86; Tue, 26 Aug 2008 03:30:13 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB9A3A6A86 for <6lowpan@core3.amsl.com>; Tue, 26 Aug 2008 03:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sYBPeO32cXo for <6lowpan@core3.amsl.com>; Tue, 26 Aug 2008 03:30:11 -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 2A27C3A6A2B for <6lowpan@ietf.org>; Tue, 26 Aug 2008 03:30:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,270,1217808000"; d="scan'208";a="18238403" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Aug 2008 10:30:11 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7QAUBXZ003753; Tue, 26 Aug 2008 12:30:11 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7QAUBYM026788; Tue, 26 Aug 2008 10:30:11 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, 26 Aug 2008 12:30:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Aug 2008 12:29:37 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0625E93D@xmb-ams-337.emea.cisco.com> In-Reply-To: <804EEBA5-44A0-4421-B47F-430094A81EDC@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] HC-01 ready to advance to WG document? Thread-Index: AcjzLowi+0W+3Re8Tuq3ecNsa0EQEgUN2iMg References: <804EEBA5-44A0-4421-B47F-430094A81EDC@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 26 Aug 2008 10:30:11.0522 (UTC) FILETIME=[B833A220:01C90766] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1651; t=1219746611; x=1220610611; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20HC-01=20ready=20to=20advanc e=20to=20WG=20document? |Sender:=20; bh=0GG+HRih77ZICKcQHJ6ReylIxSlko/oR3jZ45UMG3IQ=; b=GtrjnKxtfh7tLbDC8jtofH5FdUARslmofaM79P7zSLUk1hIAxOk5656ngi Rad0LCb7qyu+CsLJz2NDHqpSodZ7OMOg/hn8vfY6nSuO3/O2ouRgUwJ08/yH tE4+J995Gy; 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] HC-01 ready to advance to WG document? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten: Resending your call. There were a number of votes in favor, so I suggest that those against should speak now or forever hold their peace. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann >Sent: jeudi 31 juillet 2008 18:56 >To: 6lowpan >Cc: Carsten Bormann >Subject: [6lowpan] HC-01 ready to advance to WG document? > >Lowpanners, > >we were so pressed for time at the WG meeting that the chairs forgot >to ask "the question": > >Do we believe that draft-hui-6lowpan-hc-01.txt is now ready to become >the WG document for charter item 2, "6LoWPAN Improved Header >Compression"? > >Note that moving the document to WG document status does not mean we >have to agree with every detail in there. >We just need to agree that it is a good basis for the remaining work. >(Moving to WG document status also means that all further changes >should be the result of work in the WG, so it also removes a little >flexibility that the authors of an individual draft have.) >I believe there was tacit agreement in the room in Dublin, and I now >want to make the agreement explicit on the mailing list. > >As the document has been pretty non-contentious, I'm looking forward >to comments until Monday 1800 UTC. >If there are no objections by this time, I'll ask Jonathan to resubmit >the draft as a WG document (possibly with the changes resulting from >this meeting). > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Aug 27 10:24:15 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F33D3A681F; Wed, 27 Aug 2008 10:24:15 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4AB3A681D for <6lowpan@core3.amsl.com>; Wed, 27 Aug 2008 10:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.086 X-Spam-Level: ** X-Spam-Status: No, score=2.086 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172, IP_NOT_FRIENDLY=0.334] 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 yRljBS+dnK4m for <6lowpan@core3.amsl.com>; Wed, 27 Aug 2008 10:24:14 -0700 (PDT) Received: from mail.dustnetworks.com (cust-67-203-88-34.static.o1.com [67.203.88.34]) by core3.amsl.com (Postfix) with ESMTP id 0F55D3A635F for <6lowpan@ietf.org>; Wed, 27 Aug 2008 10:24:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 10:22:31 -0700 Message-ID: <16745BFFDEC5F64BBB094C931862B4951FE89D@dust-exch-01.dusthq.dust-inc.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0625E93D@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] HC-01 ready to advance to WG document? Thread-Index: AcjzLowi+0W+3Re8Tuq3ecNsa0EQEgUN2iMgAEAHMYA= From: "Chol Su Kang" To: "Pascal Thubert (pthubert)" , "Carsten Bormann" Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] HC-01 ready to advance to WG document? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Here are my comments on draft-hui-6lowpan-hc-01.txt. Figure 1. LOWPAN_IPHC is shown as 1 octet. But the text describes it is a two-octets field. Figure 1. It shows "Uncompressed fields follow" after LOWPAN_IPHC. But, Figure 5 shows differently. Sec 2.1 pg 5 "Next Hop" for NH bit? Next Hop and Next Header usages are confusing. Sec 2.1 pg 5 SAC(?) for Source Address Mode Sec 2.2 pg 6 Is this ID requiring upper-layer integrity checks? Are such checks used to detect out of sync, or prevent out of sync? Can you provide a reference for pseudo-header checksum? What is the reason for limiting the uni-cast address range to 15-bit range? Sec 2.3 pg 8 What is "well-known mapping"? Is it referring well-known multicast addresses? Sec 2.4 Is this intended Range order, i.e. Range 0, 2, 1, 3, 4? Sec 3 Figure 5: "In-line IP Fields"? Is this "In-line IPv6 header fields"? Sec 4 It states that another short address range is reserved in this document. However, Sec 2.4 shows the reservation/usage of three additional ranges. -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Tuesday, August 26, 2008 3:30 AM To: Carsten Bormann Cc: 6lowpan Subject: Re: [6lowpan] HC-01 ready to advance to WG document? Hi Carsten: Resending your call. There were a number of votes in favor, so I suggest that those against should speak now or forever hold their peace. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann >Sent: jeudi 31 juillet 2008 18:56 >To: 6lowpan >Cc: Carsten Bormann >Subject: [6lowpan] HC-01 ready to advance to WG document? > >Lowpanners, > >we were so pressed for time at the WG meeting that the chairs forgot >to ask "the question": > >Do we believe that draft-hui-6lowpan-hc-01.txt is now ready to become >the WG document for charter item 2, "6LoWPAN Improved Header >Compression"? > >Note that moving the document to WG document status does not mean we >have to agree with every detail in there. >We just need to agree that it is a good basis for the remaining work. >(Moving to WG document status also means that all further changes >should be the result of work in the WG, so it also removes a little >flexibility that the authors of an individual draft have.) >I believe there was tacit agreement in the room in Dublin, and I now >want to make the agreement explicit on the mailing list. > >As the document has been pretty non-contentious, I'm looking forward >to comments until Monday 1800 UTC. >If there are no objections by this time, I'll ask Jonathan to resubmit >the draft as a WG document (possibly with the changes resulting from >this meeting). > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Aug 27 10:37:33 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6866528C1FC; Wed, 27 Aug 2008 10:37: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 78B3028C1F3 for <6lowpan@core3.amsl.com>; Wed, 27 Aug 2008 10:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 EB+QdrIldALh for <6lowpan@core3.amsl.com>; Wed, 27 Aug 2008 10:37:28 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 36DE23A6C12 for <6lowpan@ietf.org>; Wed, 27 Aug 2008 10:37:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 3FA05AF896; Wed, 27 Aug 2008 10:36:40 -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 g9TET8Kg488J; Wed, 27 Aug 2008 10:36:39 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id CFC00AF881; Wed, 27 Aug 2008 10:36:38 -0700 (PDT) Message-Id: From: Jonathan Hui To: Chol Su Kang In-Reply-To: <16745BFFDEC5F64BBB094C931862B4951FE89D@dust-exch-01.dusthq.dust-inc.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 27 Aug 2008 10:36:37 -0700 References: <16745BFFDEC5F64BBB094C931862B4951FE89D@dust-exch-01.dusthq.dust-inc.com> X-Mailer: Apple Mail (2.926) Cc: 6lowpan <6lowpan@ietf.org>, Carsten Bormann Subject: Re: [6lowpan] HC-01 ready to advance to WG document? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Thanks for the comments. See below: On Aug 27, 2008, at 10:22 AM, Chol Su Kang wrote: > Here are my comments on draft-hui-6lowpan-hc-01.txt. > > Figure 1. LOWPAN_IPHC is shown as 1 octet. > But the text describes it is a two-octets field. That is a mistake in the document. I didn't have a chance to carefully update everything, as you have pointed out in the following comments. > Figure 1. It shows "Uncompressed fields follow" after LOWPAN_IPHC. > But, Figure 5 shows differently. Figures 1 and 5 agree with each other. Uncompressed fields refer to those IP fields that are carried inline. > Sec 2.1 pg 5 > "Next Hop" for NH bit? > Next Hop and Next Header usages are confusing. Yes, this is a mistake and was already pointed out a few times on the list. > Sec 2.1 pg 5 > SAC(?) for Source Address Mode Another typo. > Sec 2.2 pg 6 > Is this ID requiring upper-layer integrity checks? > Are such checks used to detect out of sync, or prevent out of sync? > Can you provide a reference for pseudo-header checksum? From RFC 2460: "when UDP packets are originated by an IPv6 node, the UDP checksum is not optional" > What is the reason for limiting the uni-cast address range > to 15-bit range? See RFC 4944. > Sec 2.3 pg 8 > What is "well-known mapping"? Is it referring well-known multicast > addresses? Refers to the table labeled as "9-bit to 112-bit Group ID Mapping" > Sec 2.4 > Is this intended Range order, i.e. Range 0, 2, 1, 3, 4? Typo again. > Sec 3 > Figure 5: > "In-line IP Fields"? Is this "In-line IPv6 header fields"? Yes. I'm not sure I understand the difference. > Sec 4 > It states that another short address range is reserved in this > document. > However, Sec 2.4 shows the reservation/usage of three additional > ranges. They are already reserved. See RFC 4944. -- Jonathan Hui > > > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Pascal Thubert (pthubert) > Sent: Tuesday, August 26, 2008 3:30 AM > To: Carsten Bormann > Cc: 6lowpan > Subject: Re: [6lowpan] HC-01 ready to advance to WG document? > > Hi Carsten: > > Resending your call. There were a number of votes in favor, so I > suggest > that those against should speak now or forever hold their peace. > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Carsten Bormann >> Sent: jeudi 31 juillet 2008 18:56 >> To: 6lowpan >> Cc: Carsten Bormann >> Subject: [6lowpan] HC-01 ready to advance to WG document? >> >> Lowpanners, >> >> we were so pressed for time at the WG meeting that the chairs forgot >> to ask "the question": >> >> Do we believe that draft-hui-6lowpan-hc-01.txt is now ready to become >> the WG document for charter item 2, "6LoWPAN Improved Header >> Compression"? >> >> Note that moving the document to WG document status does not mean we >> have to agree with every detail in there. >> We just need to agree that it is a good basis for the remaining work. >> (Moving to WG document status also means that all further changes >> should be the result of work in the WG, so it also removes a little >> flexibility that the authors of an individual draft have.) >> I believe there was tacit agreement in the room in Dublin, and I now >> want to make the agreement explicit on the mailing list. >> >> As the document has been pretty non-contentious, I'm looking forward >> to comments until Monday 1800 UTC. >> If there are no objections by this time, I'll ask Jonathan to >> resubmit >> the draft as a WG document (possibly with the changes resulting from >> this meeting). >> >> Gruesse, Carsten >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Aug 29 01:24:40 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14AE3A6802; Fri, 29 Aug 2008 01:24:40 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099A73A6802 for <6lowpan@core3.amsl.com>; Fri, 29 Aug 2008 01:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBdbI+X1ssOu for <6lowpan@core3.amsl.com>; Fri, 29 Aug 2008 01:24:38 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id B39463A67F6 for <6lowpan@ietf.org>; Fri, 29 Aug 2008 01:24:38 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so688173rvf.49 for <6lowpan@ietf.org>; Fri, 29 Aug 2008 01:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=JSSFheombwPnsrb7qUikAiB3HezZbM6OiKNJiRP9+EY=; b=g4QrDHVIr5xOxOXpKn9mQwlfmuGiaIoGappHMV9vCyuulT2a+Ae8jnCATQDkBlw0NC /F5YWcirTHz/VO4lo3xuNi4FgSjgK8JOxxwbH9epJR0efjLK48RXNOj5kIxPqAVwL2pZ KGOMgNvx+gpgGSkTT15sNmxReRYEPdo1zPon8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=XzcF5Xa0g2fqwNj1PI/JUNjXVrE4nOj+f1gPiksBFktcJ08vMlruABLJs0mohn/USk xKDh1cDwX6Ti9/EGjeG7jc1DvOMBatXJ5XvIwBZ7hYq1df78x1g68c6PCiBANCJXgmX7 9bnjJFB5Mm3hmlVyb/eCvfd3K2VaD5bvgCXBI= Received: by 10.140.125.1 with SMTP id x1mr1310596rvc.287.1219998281758; Fri, 29 Aug 2008 01:24:41 -0700 (PDT) Received: by 10.141.169.21 with HTTP; Fri, 29 Aug 2008 01:24:41 -0700 (PDT) Message-ID: <147a29c80808290124t2f95fc64g97c5fc36ef606ccb@mail.gmail.com> Date: Fri, 29 Aug 2008 10:24:41 +0200 From: "Laurent Toutain" To: "Jonathan Hui" In-Reply-To: MIME-Version: 1.0 References: <16745BFFDEC5F64BBB094C931862B4951FE89D@dust-exch-01.dusthq.dust-inc.com> X-Google-Sender-Auth: 24b26c3a2cf4af9d Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] HC-01 ready to advance to WG document? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0777887117==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============0777887117== Content-Type: multipart/alternative; boundary="----=_Part_14302_32151581.1219998281751" ------=_Part_14302_32151581.1219998281751 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm also in favor of working on that document, but some details are not clear to me. - Does this compression scheme is suppose to replace RFC 4944 ? or does it mean that sensors will have to implement both ? - SAC/DAC usage is not clear for me. draft does not specify it, but does it mean that RA will carry the prefix and the context number and the sensor will just put the DAC/SAC bits are reference ? -> For DAC, does it take into account outside prefixes ? Laurent On Wed, Aug 27, 2008 at 19:36, Jonathan Hui wrote: > > Thanks for the comments. See below: > > On Aug 27, 2008, at 10:22 AM, Chol Su Kang wrote: > > Here are my comments on draft-hui-6lowpan-hc-01.txt. > > > > Figure 1. LOWPAN_IPHC is shown as 1 octet. > > But the text describes it is a two-octets field. > > That is a mistake in the document. I didn't have a chance to carefully > update everything, as you have pointed out in the following comments. > > > Figure 1. It shows "Uncompressed fields follow" after LOWPAN_IPHC. > > But, Figure 5 shows differently. > > Figures 1 and 5 agree with each other. Uncompressed fields refer to > those IP fields that are carried inline. > > > Sec 2.1 pg 5 > > "Next Hop" for NH bit? > > Next Hop and Next Header usages are confusing. > > Yes, this is a mistake and was already pointed out a few times on the > list. > > > Sec 2.1 pg 5 > > SAC(?) for Source Address Mode > > Another typo. > > > Sec 2.2 pg 6 > > Is this ID requiring upper-layer integrity checks? > > Are such checks used to detect out of sync, or prevent out of sync? > > Can you provide a reference for pseudo-header checksum? > > From RFC 2460: "when UDP packets are originated by an IPv6 node, the > UDP checksum is not optional" > > > What is the reason for limiting the uni-cast address range > > to 15-bit range? > > See RFC 4944. > > > Sec 2.3 pg 8 > > What is "well-known mapping"? Is it referring well-known multicast > > addresses? > > Refers to the table labeled as "9-bit to 112-bit Group ID Mapping" > > > Sec 2.4 > > Is this intended Range order, i.e. Range 0, 2, 1, 3, 4? > > Typo again. > > > Sec 3 > > Figure 5: > > "In-line IP Fields"? Is this "In-line IPv6 header fields"? > > Yes. I'm not sure I understand the difference. > > > Sec 4 > > It states that another short address range is reserved in this > > document. > > However, Sec 2.4 shows the reservation/usage of three additional > > ranges. > > They are already reserved. See RFC 4944. > > -- > Jonathan Hui > > > > > > > > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Pascal Thubert (pthubert) > > Sent: Tuesday, August 26, 2008 3:30 AM > > To: Carsten Bormann > > Cc: 6lowpan > > Subject: Re: [6lowpan] HC-01 ready to advance to WG document? > > > > Hi Carsten: > > > > Resending your call. There were a number of votes in favor, so I > > suggest > > that those against should speak now or forever hold their peace. > > > > Pascal > > > >> -----Original Message----- > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Carsten Bormann > >> Sent: jeudi 31 juillet 2008 18:56 > >> To: 6lowpan > >> Cc: Carsten Bormann > >> Subject: [6lowpan] HC-01 ready to advance to WG document? > >> > >> Lowpanners, > >> > >> we were so pressed for time at the WG meeting that the chairs forgot > >> to ask "the question": > >> > >> Do we believe that draft-hui-6lowpan-hc-01.txt is now ready to become > >> the WG document for charter item 2, "6LoWPAN Improved Header > >> Compression"? > >> > >> Note that moving the document to WG document status does not mean we > >> have to agree with every detail in there. > >> We just need to agree that it is a good basis for the remaining work. > >> (Moving to WG document status also means that all further changes > >> should be the result of work in the WG, so it also removes a little > >> flexibility that the authors of an individual draft have.) > >> I believe there was tacit agreement in the room in Dublin, and I now > >> want to make the agreement explicit on the mailing list. > >> > >> As the document has been pretty non-contentious, I'm looking forward > >> to comments until Monday 1800 UTC. > >> If there are no objections by this time, I'll ask Jonathan to > >> resubmit > >> the draft as a WG document (possibly with the changes resulting from > >> this meeting). > >> > >> Gruesse, Carsten > >> > >> _______________________________________________ > >> 6lowpan mailing list > >> 6lowpan@ietf.org > >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > ------=_Part_14302_32151581.1219998281751 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,

I'm also in favor of working on that document, but some details are not clear to me.

- Does this compression scheme is suppose to replace RFC 4944 ? or does it mean that sensors will have to implement both ?
- SAC/DAC usage is not clear for me. draft does not specify it, but does it mean that RA will carry the prefix and the context
number and the sensor will just put the DAC/SAC bits are reference ?
  -> For DAC, does it take into account outside prefixes ?

Laurent

On Wed, Aug 27, 2008 at 19:36, Jonathan Hui <jhui@archrock.com> wrote:

Thanks for the comments. See below:

On Aug 27, 2008, at 10:22 AM, Chol Su Kang wrote:
> Here are my comments on draft-hui-6lowpan-hc-01.txt.
>
>   Figure 1. LOWPAN_IPHC is shown as 1 octet.
>             But the text describes it is a two-octets field.

That is a mistake in the document. I didn't have a chance to carefully
update everything, as you have pointed out in the following comments.

>   Figure 1. It shows "Uncompressed fields follow" after LOWPAN_IPHC.
>             But, Figure 5 shows differently.

Figures 1 and 5 agree with each other. Uncompressed fields refer to
those IP fields that are carried inline.

> Sec 2.1 pg 5
>    "Next Hop" for NH bit?
>    Next Hop and Next Header usages are confusing.

Yes, this is a mistake and was already pointed out a few times on the
list.

> Sec 2.1 pg 5
>    SAC(?) for Source Address Mode

Another typo.

> Sec 2.2 pg 6
>    Is this ID requiring upper-layer integrity checks?
>    Are such checks used to detect out of sync, or prevent out of sync?
>    Can you provide a reference for pseudo-header checksum?

 From RFC 2460: "when UDP packets are originated by an IPv6 node, the
UDP checksum is not optional"

>    What is the reason for limiting the uni-cast address range
>     to 15-bit range?

See RFC 4944.

> Sec 2.3 pg 8
>    What is "well-known mapping"? Is it referring well-known multicast
>     addresses?

Refers to the table labeled as "9-bit to 112-bit Group ID Mapping"

> Sec 2.4
>    Is this intended Range order, i.e. Range 0, 2, 1, 3, 4?

Typo again.

> Sec 3
>    Figure 5:
>       "In-line IP Fields"? Is this "In-line IPv6 header fields"?

Yes. I'm not sure I understand the difference.

> Sec 4
>    It states that another short address range is reserved in this
> document.
>    However, Sec 2.4 shows the reservation/usage of three additional
> ranges.

They are already reserved. See RFC 4944.

--
Jonathan Hui

>
>
>
> -----Original Message-----
> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On
> Behalf Of Pascal Thubert (pthubert)
> Sent: Tuesday, August 26, 2008 3:30 AM
> To: Carsten Bormann
> Cc: 6lowpan
> Subject: Re: [6lowpan] HC-01 ready to advance to WG document?
>
> Hi Carsten:
>
> Resending your call. There were a number of votes in favor, so I
> suggest
> that those against should speak now or forever hold their peace.
>
> Pascal
>
>> -----Original Message-----
>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On
> Behalf Of Carsten Bormann
>> Sent: jeudi 31 juillet 2008 18:56
>> To: 6lowpan
>> Cc: Carsten Bormann
>> Subject: [6lowpan] HC-01 ready to advance to WG document?
>>
>> Lowpanners,
>>
>> we were so pressed for time at the WG meeting that the chairs forgot
>> to ask "the question":
>>
>> Do we believe that draft-hui-6lowpan-hc-01.txt is now ready to become
>> the WG document for charter item 2, "6LoWPAN Improved Header
>> Compression"?
>>
>> Note that moving the document to WG document status does not mean we
>> have to agree with every detail in there.
>> We just need to agree that it is a good basis for the remaining work.
>> (Moving to WG document status also means that all further changes
>> should be the result of work in the WG, so it also removes a little
>> flexibility that the authors of an individual draft have.)
>> I believe there was tacit agreement in the room in Dublin, and I now
>> want to make the agreement explicit on the mailing list.
>>
>> As the document has been pretty non-contentious, I'm looking forward
>> to comments until Monday 1800 UTC.
>> If there are no objections by this time, I'll ask Jonathan to
>> resubmit
>> the draft as a WG document (possibly with the changes resulting from
>> this meeting).
>>
>> Gruesse, Carsten
>>
>> _______________________________________________
>> 6lowpan mailing list
>> 6lowpan@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lowpan
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan

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


------=_Part_14302_32151581.1219998281751-- --===============0777887117== 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 --===============0777887117==--