From 6lowpan-bounces@ietf.org Tue Apr 1 19:17:31 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D09123A6DAC; Tue, 1 Apr 2008 19:17:31 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026ED3A6DB6 for <6lowpan@core3.amsl.com>; Tue, 1 Apr 2008 19:17:31 -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 q8k0NyuoLXZi for <6lowpan@core3.amsl.com>; Tue, 1 Apr 2008 19:17:30 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 27E383A6DAC for <6lowpan@ietf.org>; Tue, 1 Apr 2008 19:17:30 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k40so3359655wah.25 for <6lowpan@ietf.org>; Tue, 01 Apr 2008 19:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=HdSawKzX0tbJ4zJZ+r44C3YEpcyZbmt6LPjC9bBrXXc=; b=Vrv/Zr516oDavWfhBdIW9rYlengjG59QIYzdQJXncInqV9b+AOcltV93pdNTQCb+ziGRQRY7THiIaZhTfT0Ve4m4Gf7g6Hy19oRvQYTb7J0B24cRL3c5UMZfpRpR1yiZkoLwnqU8aVVeTD9t23Ajq7LsoBLRFGDezePZvxx/EUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=D2s9JPXM1bWNcq9GGmHzPixZ5sNcIe+K1nZC9j2Ggomir0YshA8ddZiyxDHb4U2S0iyD2ZKeB9Q7jFXLSWj4MuOUST/IdZnKaEjqxweKckL421ZHFIlVxpKrjbh6ZpoCEarUO5dbO4MEcdpFStnK1xUM4HNfG8TpJOOIWzK9/Yg= Received: by 10.114.158.1 with SMTP id g1mr13740134wae.111.1207102649757; Tue, 01 Apr 2008 19:17:29 -0700 (PDT) Received: by 10.115.108.7 with HTTP; Tue, 1 Apr 2008 19:17:29 -0700 (PDT) Message-ID: <77f1dba80804011917s20f9dc5egc509624db3d8ae0a@mail.gmail.com> Date: Wed, 2 Apr 2008 11:17:29 +0900 From: "Eunsook \"Eunah\" Kim" To: 6lowpan <6lowpan@ietf.org> In-Reply-To: <20080402015850.52CD93A6D04@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080402015850.52CD93A6D04@core3.amsl.com> Subject: [6lowpan] Fwd: New Version Notification for draft-dokaspar-6lowpan-routreq-05 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Dear 6LoWPANners '6LoWPAN routing requirements' draft has been revised as the following email. We've tried to update the draft more 6lowpan-specific, considering the comments from the floor in the IETF 71 meeting. We, the co-authors, discussed intensively to meet the 6LoWPAN's need, considering the relationship with ROLL. Hope you take a look at the revision, and give your thought. I wish we can make a useful draft for 6LoWPAN. Thanks, ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Apr 2, 2008 10:58 AM Subject: New Version Notification for draft-dokaspar-6lowpan-routreq-05 To: eunah.ietf@gmail.com Cc: dokaspar.ietf@gmail.com, carlesgo@entel.upc.edu, cabo@tzi.org A new version of I-D, draft-dokaspar-6lowpan-routreq-05.txt has been successfuly submitted by Eunsook Kim and posted to the IETF repository. Filename: draft-dokaspar-6lowpan-routreq Revision: 05 Title: Problem Statement and Requirements for 6LoWPAN Mesh Routing Creation_date: 2008-04-02 WG ID: Independent Submission Number_of_pages: 24 Abstract: This document provides the problem statement for 6LoWPAN mesh routing. It also defines the requirements for 6LoWPAN mesh routing considering the low-power characteristics of the network and its devices. The IETF Secretariat. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Apr 2 04:32: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 core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AE693A6EFE; Wed, 2 Apr 2008 04:32: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 BC9693A6E77 for <6lowpan@core3.amsl.com>; Wed, 2 Apr 2008 04:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.007 X-Spam-Level: X-Spam-Status: No, score=-5.007 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292, 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 C9yOnFMKDkSP for <6lowpan@core3.amsl.com>; Wed, 2 Apr 2008 04:32:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 447923A6BDB for <6lowpan@ietf.org>; Wed, 2 Apr 2008 04:30:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,593,1199660400"; d="scan'208";a="5149461" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2008 13:30:19 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m32BUJn4015052 for <6lowpan@ietf.org>; Wed, 2 Apr 2008 13:30:19 +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 m32BUJp2005894 for <6lowpan@ietf.org>; Wed, 2 Apr 2008 11:30:19 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 13:30:19 +0200 Received: from [144.254.20.210] ([144.254.20.210]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 13:30:19 +0200 Message-ID: <47F36EB1.7070009@cisco.com> Date: Wed, 02 Apr 2008 13:32:01 +0200 From: =?ISO-8859-1?Q?Julien_Abeill=E9?= User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 CC: 6lowpan <6lowpan@ietf.org> References: <20080402015850.52CD93A6D04@core3.amsl.com> <77f1dba80804011917s20f9dc5egc509624db3d8ae0a@mail.gmail.com> In-Reply-To: <77f1dba80804011917s20f9dc5egc509624db3d8ae0a@mail.gmail.com> X-OriginalArrivalTime: 02 Apr 2008 11:30:19.0216 (UTC) FILETIME=[EE3E8D00:01C894B4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=271; t=1207135819; x=1207999819; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Julien_Abeill=3DE9?=3D=20 |Subject:=20ipv6=20extension=20header=20in=20RFC4944 |Sender:=20; bh=D3FA5SCPq3/p9sz05Ob0I5O+LH2SIgCcxOo7guU36M8=; b=v2QR+7bQhhkUSwTsRmRWLem5L/anZ+LAfBdg7xlpDNLNPyb4DS+ZRz/S/u lLUB7degGMpRwTa/g9g/e0EAMrDQwJrPc9ubISwIL5p54EuqqfheVOquXbt0 /2HVKSnnUp; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [6lowpan] ipv6 extension header in RFC4944 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, sorry if this was already discussed. In section 5 of RFC4944, the list of ordered 6lowpan and ipv6 extension headers does not mention the IPv6 routing header, destination option header and IPv6 fragment header. Is it a mistake? Best regards, Julien _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Apr 8 01:03:38 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 core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F8628C32B; Tue, 8 Apr 2008 01:03:38 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E779928C32B; Tue, 8 Apr 2008 01:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 0aHz15TXchGW; Tue, 8 Apr 2008 01:03:35 -0700 (PDT) Received: from gw-eur4.philips.com (gw-eur4.philips.com [161.85.125.10]) by core3.amsl.com (Postfix) with ESMTP id A4AA328C2EC; Tue, 8 Apr 2008 01:03:35 -0700 (PDT) Received: from smtpscan-eur5.philips.com (smtpscan-eur5.mail.philips.com [130.144.57.168]) by gw-eur4.philips.com (Postfix) with ESMTP id 88B9A19F7; Tue, 8 Apr 2008 08:03:37 +0000 (GMT) Received: from smtpscan-eur5.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id EE52D1630; Tue, 8 Apr 2008 08:03:48 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur5.philips.com (Postfix) with ESMTP id C955FB30; Tue, 8 Apr 2008 08:03:48 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id AD598DD; Tue, 8 Apr 2008 08:03:48 +0000 (GMT) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC056EE338@xmb-ams-337.emea.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Anthony Schoofs Date: Tue, 8 Apr 2008 10:05:10 +0200 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.6FP2HF30 | November 25, 2007) at 08/04/2008 10:05:10 MIME-Version: 1.0 Cc: 6lowpan-bounces@ietf.org, 6lowpan@ietf.org Subject: [6lowpan] Lowpan Backbone Router draft 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="===============1082572216==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1082572216== Content-type: multipart/alternative; Boundary="0__=4EBBFEB6DFBF9CAD8f9e8a93df938690918c4EBBFEB6DFBF9CAD" Content-Disposition: inline --0__=4EBBFEB6DFBF9CAD8f9e8a93df938690918c4EBBFEB6DFBF9CAD Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Hi Pascal, I went through your draft about the concept of a Backbone Router to hel= p large-scale networks deployments. I have a few comments about the draft= , I put them below: In Figure 1 you drew one single gateway that connects the backbone rout= er to the plant network. You do not refer to it later in the document. Is = it something application specific, a requirement for the backbone router approach or a consequence to it? For any case, I would mention it or re= move it from the figure. In Section 6.1, you wrote that Bacbone Routers announce themselves usin= g RAs that are broadcasted. Maybe you could see whether the solution prop= osed in draft-chakrabarti-6lowpan-ipv6-nd-04.txt section 6.2 can help avoid sending many broadcast messages. As a resume, they suggest: " .. the PAN co-ordinator aka IPv6 router sends periodic RA to the co-ordinators in its PAN by sending unicast messages to each of them...= Each co-ordinator can act as proxy IPv6 router advertiser and they can broadcast the RA on behalf of the IPv6-router in their own domain periodically.." In Section 6.4, you mention that the target link-layer address is that = of the destination if a shorcut is possible over the Lowpan. Do you plan t= o specify the mechanism that will tell the nodes if they have to go throu= gh the Backbone Router or not for a communication? Shortly, how do the nod= es know if a shorcut is possible and better than the backbone route? Is it= out of scope of this document? There are various benefits of the Backbone router approach that may be mentionned in the document. If you let backbone routers take care of th= e routing for the nodes for instance, it may result in only unicast packe= ts within the different lowpans (towards and from the backbone router), wh= ich will have as consequences 1) less interferences (less packets in the air due to routes that are k= nown from the backbone router to the destination node and due to the shorcut= that the backbone may offer compared to long multihop communications) 2) less broadcast packets 3) reduced memory requisite for routing tables on the nodes 4) longer battery life for the sensor nodes. This could be made more visible in the document. Best regards, Anthony -- Anthony Schoofs Research Scientist, Flexnod project, CCS Group Philips Research WY 7-038 High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands Tel: (+31) 40 27 49 654 Email: anthony.schoofs@philips.com= --0__=4EBBFEB6DFBF9CAD8f9e8a93df938690918c4EBBFEB6DFBF9CAD Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi Pascal,

I went through your draft about the concept of a Backbone Router to hel= p large-scale networks deployments. I have a few comments about the dra= ft, I put them below:

In Figure 1 you drew one single gateway that connects the backbone rout= er to the plant network. You do not refer to it later in the document. = Is it something application specific, a requirement for the backbone ro= uter approach or a consequence to it? For any case, I would mention it = or remove it from the figure.

In Section 6.1, you wrote that Bacbone Routers announce themselves usin= g RAs that are broadcasted. Maybe you could see whether the solution pr= oposed in draft-chakrabarti-6lowpan-ipv6-nd-04.txt section 6.2 can help= avoid sending many broadcast messages. As a resume, they suggest:
" .. the PAN co-ordinator aka IPv6 router sends periodic RA to the= co-ordinators in its PAN by sending unicast messages to each of them..= . Each co-ordinator can act as proxy IPv6 router advertiser and they ca= n broadcast the RA on behalf of the IPv6-router in their own domain per= iodically.."

In Section 6.4, you mention that the target link-layer address is that = of the destination if a shorcut is possible over the Lowpan. Do you pla= n to specify the mechanism that will tell the nodes if they have to go = through the Backbone Router or not for a communication? Shortly, how do= the nodes know if a shorcut is possible and better than the backbone r= oute? Is it out of scope of this document?

There are various benefits of the Backbone router approach that may be = mentionned in the document. If you let backbone routers take care of th= e routing for the nodes for instance, it may result in only unicast pac= kets within the different lowpans (towards and from the backbone router= ), which will have as consequences
1) less interferences (less packets in the air due to routes that are k= nown from the backbone router to the destination node and due to the sh= orcut that the backbone may offer compared to long multihop communicati= ons)
2) less broadcast packets
3) reduced memory requisite for routing tables on the nodes
4) longer battery life for the sensor nodes.
This could be made more visible in the document.

Best regards,
Anthony

--
Anthony Schoofs
Research Scientist, Flexnod project, CCS Group
Philips Research WY 7-038
High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands
Tel: (+31) 40 27 49 654
Email: anthony.schoofs@philips.com
= --0__=4EBBFEB6DFBF9CAD8f9e8a93df938690918c4EBBFEB6DFBF9CAD-- --===============1082572216== 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 --===============1082572216==-- From 6lowpan-bounces@ietf.org Tue Apr 8 02:06:05 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9163A6ADF; Tue, 8 Apr 2008 02:06:05 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FA4628C2DC for <6lowpan@core3.amsl.com>; Tue, 8 Apr 2008 02:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[AWL=2.396, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igcnHLPgNhtE for <6lowpan@core3.amsl.com>; Tue, 8 Apr 2008 02:05:36 -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 7E34D3A6D54 for <6lowpan@ietf.org>; Tue, 8 Apr 2008 02:05:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,622,1199660400"; d="scan'208";a="5650354" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Apr 2008 11:05:47 +0200 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 m3895lih024180; Tue, 8 Apr 2008 11:05:47 +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 m3895la2004899; Tue, 8 Apr 2008 09:05:47 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, 8 Apr 2008 11:05:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Apr 2008 11:05:15 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0580870C@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lowpan Backbone Router draft thread-index: AciZTyKvEXAp2aQqRXOumGtJuQBe5QAAC2ZA From: "Pascal Thubert (pthubert)" To: "Anthony Schoofs" X-OriginalArrivalTime: 08 Apr 2008 09:05:47.0155 (UTC) FILETIME=[BBC58E30:01C89957] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6166; t=1207645547; x=1208509547; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20Lowpan=20Backbone=20Router=20draft |Sender:=20; bh=vudDiXbFlAag9GxHoaWYYGpYOalyydNRI4gExf45nKs=; b=oA26tA8CYNfGm7oeQhy9IGrteSP0DyB3UcYJ9XYmmVzGFsaMGhd4726ciK mKiDk+pLqLk1lvLBN5c1+LG6fu90dNByjF9Pwsvmpe9T9LUWYG6n10lZ3xDU dEV6sy7nAl; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org, "Benoit Lourdelet \(blourdel\)" Subject: Re: [6lowpan] Lowpan Backbone Router draft 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 Anthony: Thanks a whole bunch for this review. Let me please respond inline [Anthony] I went through your draft about the concept of a Backbone Router to help large-scale networks deployments. I have a few comments about the draft, I put them below: In Figure 1 you drew one single gateway that connects the backbone router to the plant network. You do not refer to it later in the document. Is it something application specific, a requirement for the backbone router approach or a consequence to it? For any case, I would mention it or remove it from the figure. [Pascal] The figure depicts the current ISA100.11a reference model. I need to add words that this model applies to many situations in industrial, home and building automation, but certainly not all and that the gateway could become a firewall or a simple router depending on the use case. In the same fashion, the plant network can be the building control network, the Service Provider network or even the Internet. [Anthony] In Section 6.1, you wrote that Bacbone Routers announce themselves using RAs that are broadcasted. Maybe you could see whether the solution proposed in draft-chakrabarti-6lowpan-ipv6-nd-04.txt section 6.2 can help avoid sending many broadcast messages. As a resume, they suggest: " .. the PAN co-ordinator aka IPv6 router sends periodic RA to the co-ordinators in its PAN by sending unicast messages to each of them... Each co-ordinator can act as proxy IPv6 router advertiser and they can broadcast the RA on behalf of the IPv6-router in their own domain periodically.." [Pascal] Very right. The focus of this doc is to illustrate the white board approach and the use of proxy ND over the backbone to scale up the LoWPAN. If the group agrees that this is the direction then we can dig further and merging with draft-chakrabarti would be an excellent idea. It is clear to me that my Draft 00 falls short in a number of occasions which were not the focus at the time. - registration mechanism. DHCP formats make more sense than NS/NA that I used. I asked Benoit Lourdelet to join as a coauthor to rework that. I also got comments that a totally new format could be welcome, along the lines of RFC 3775 Binding Update (though the BU as it stands is not fit for the job) but for the time being I'd rather stick to DHCPv6 and see the feedback from the group. - NS lookup. There can be 2 ways, proactive and reactive. My draft reflects proactive using unicast NS/NA with the white board (and it will be based on DHCP RFC 5007 in the next release). It's good because it woorks for any type of address, link local, unique local and global. draft-chakrabarti proposes a reactive version where the backbone router does the lookup for you with an implicit request that comes with the packet to be forwarded. This saves the NS/NA flow but causes all packets to flow via the BbR. The route optimization with the PAN can still happen under the BbR control using redirects. I think we need both approaches make sense and are needed; that's a good reason to merge the drafts. - RA (as you point out), and that includes for me advertising the DHCP relay and white board capabilities so we skip the SOLLICIT flow that is normally multicast but makes little sense here. I had nothing much to add to the excellent work that is already there in draft-chakrabarti; that's another good reason to merge the drafts. [Anthony] In Section 6.4, you mention that the target link-layer address is that of the destination if a shorcut is possible over the Lowpan. Do you plan to specify the mechanism that will tell the nodes if they have to go through the Backbone Router or not for a communication? Shortly, how do the nodes know if a shorcut is possible and better than the backbone route? Is it out of scope of this document? [Pascal] My draft does not say haw the routing is done (mesh under or route over) and I do not think there is an assumption about it. What it does is a proactive unicast NS/NA that results in the 16 or 64bit address of the next hop. If the next hop is outside of the PAN then you get something that leads to the BbR. If the nect hop is inside the PAN (the destination) then you should get the address of that destination and you packet will get there directly. There is a complexity involved in the case where multiple BbRs serve the same PAN. They have to figure that the route inside the PAN exists and is shorter than the route outside via the BbRs and the backbone. I think that there's a point where we'll be needing ROLL to sort out these issues. My draft does not cover that and expects a single BbR, hot standby BbRs, or a default policy for inside routes vs. outside routes. [Anthony] There are various benefits of the Backbone router approach that may be mentionned in the document. If you let backbone routers take care of the routing for the nodes for instance, it may result in only unicast packets within the different lowpans (towards and from the backbone router), which will have as consequences 1) less interferences (less packets in the air due to routes that are known from the backbone router to the destination node and due to the shorcut that the backbone may offer compared to long multihop communications) 2) less broadcast packets 3) reduced memory requisite for routing tables on the nodes 4) longer battery life for the sensor nodes. This could be made more visible in the document. [Pascal] This should be made more visible in the document, and though the document does not specify how offline routing can be done there is a common spirit between the two and the benefits are similar. Note that both ISA100.11a and WiHART assume offline routing and that it will certainly be an option to consider for ROLL. I trust that most readers figured that those benefits apply to this draft already but it certainly does not hurt to add a small section about benefits that we expect from avoiding multicast and using the backbone as we do. Thanks a bunch Anthony, Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Apr 8 14:26:05 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B1E28C2A4; Tue, 8 Apr 2008 14:26:05 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC27628C2A4 for <6lowpan@core3.amsl.com>; Tue, 8 Apr 2008 14:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.823 X-Spam-Level: X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 D457R5AfGl3h for <6lowpan@core3.amsl.com>; Tue, 8 Apr 2008 14:26:03 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id D712128C161 for <6lowpan@ietf.org>; Tue, 8 Apr 2008 14:26:03 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.108.31]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m38LQKWN020281; Tue, 8 Apr 2008 21:26:20 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m38LPT5b565725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2008 14:25:29 -0700 (PDT) Message-ID: <47FBE2C9.90405@sun.com> Date: Tue, 08 Apr 2008 14:25:29 -0700 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.4 (X11/20070723) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC0580870C@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0580870C@xmb-ams-337.emea.cisco.com> Cc: 6lowpan@ietf.org, "Benoit Lourdelet \(blourdel\)" Subject: Re: [6lowpan] Lowpan Backbone Router draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Pascal Thubert (pthubert) wrote: > The focus of this doc is to illustrate the white board approach and the > use of proxy ND over the backbone to scale up the LoWPAN. Pascal, can you explain how using proxy ND makes things more efficient and/or more robust? Mapping the IPv6-all routers multicast address to a functional/anycast Lowpan address combined with VRRP seems to be sufficient to handle finding the routers including failover. Thus to me ND proxy seems like nothing but a distraction here. > If the group > agrees that this is the direction then we can dig further and merging > with draft-chakrabarti would be an excellent idea. It is clear to me > that my Draft 00 falls short in a number of occasions which were not the > focus at the time. > > - registration mechanism. DHCP formats make more sense than NS/NA that I > used. I asked Benoit Lourdelet to join as a coauthor to rework that. I > also got comments that a totally new format could be welcome, along the > lines of RFC 3775 Binding Update (though the BU as it stands is not fit > for the job) but for the time being I'd rather stick to DHCPv6 and see > the feedback from the group. But you'd also need to handle a distributed whiteboard so you whiteboard doesn't become a SPoF. And if you use (unicast) NS as the way to do lookups from the whiteboard, then there is a strong reason to co-locate the whiteboard with the entity handling the NS; it might make sense to have a common protocol for registrations and lookups. Neither current ND nor current DHCP is a good fit for a combined registration and lookup protocol. Furthermore, if we want to add key distribution to the fix, then the requirements on the registration and lookup protocol (or protocols) changes. > - NS lookup. There can be 2 ways, proactive and reactive. My draft > reflects proactive using unicast NS/NA with the white board (and it will > be based on DHCP RFC 5007 in the next release). It's good because it > woorks for any type of address, link local, unique local and global. > draft-chakrabarti proposes a reactive version where the backbone router > does the lookup for you with an implicit request that comes with the > packet to be forwarded. This saves the NS/NA flow but causes all packets > to flow via the BbR. Not necessarily. The router can unicast a redirect which tells host A which L2 address to use to reach host B directly. Whether or not to do that might depend on the stability of the L2 topology. If it is more stable to always go to and from the router than that might make more sense than finding a direct path that might be less stable. Erik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Apr 9 02:19:37 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0AF3A6AFB; Wed, 9 Apr 2008 02:19:37 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7116B3A694D for <6lowpan@core3.amsl.com>; Wed, 9 Apr 2008 02:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[AWL=2.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxMFFErD4fCK for <6lowpan@core3.amsl.com>; Wed, 9 Apr 2008 02:19:35 -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 D7E693A6C26 for <6lowpan@ietf.org>; Wed, 9 Apr 2008 02:19:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,628,1199660400"; d="scan'208";a="5773845" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Apr 2008 11:19:51 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m399Jp2P016892; Wed, 9 Apr 2008 11:19:51 +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 m399JpEh022374; Wed, 9 Apr 2008 09:19:51 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 11:19:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 11:19:18 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05808C2E@xmb-ams-337.emea.cisco.com> In-Reply-To: <47FBE2C9.90405@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] LoWPAN Backbone Router draft thread-index: AciZvzRsfivdDhSwTveE7G1HtCjRxQAWPVXw From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" X-OriginalArrivalTime: 09 Apr 2008 09:19:51.0520 (UTC) FILETIME=[DD772E00:01C89A22] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4675; t=1207732791; x=1208596791; 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]=20LoWPAN=20Backbone=20Router= 20draft |Sender:=20; bh=OQc7Rv593K71IG9NmoQFh5RzbhlLBFarLXCA6ur6AWA=; b=YzYVKdIO7Q6feFARnViIGvcccWFwJ4difbndWeLfgPJF9UgfdmzcFJ37oR vepZACfWahcHAH21cvN6fW5mzYNhAvkW6DyXVPuS9iL7EEW/Nj/2H6UTgzNp 0wtr7P4d0L; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org, "Benoit Lourdelet \(blourdel\)" Subject: Re: [6lowpan] LoWPAN Backbone Router draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org >Pascal Thubert (pthubert) wrote: > >> The focus of this doc is to illustrate the white board approach and the >> use of proxy ND over the backbone to scale up the LoWPAN. > >Pascal, > >can you explain how using proxy ND makes things more efficient and/or >more robust? Mapping the IPv6-all routers multicast address to a >functional/anycast LoWPAN address combined with VRRP seems to be >sufficient to handle finding the routers including failover. Thus to me >ND proxy seems like nothing but a distraction here. [Pascal] Hi Erik: Thanks a bunch for helping here. The main requirement that the draft is addressing is scaling the LowPAN by merging multiple PANs over a backbone. This requirement comes from the industrial space but the topology appears in multiple other use cases, in building and home automation for instance. One specific aspect of this requirement is that a node can move from a LoWPAN to another LoWPAN attached to the same backbone link and keep its (set of) address(es). In particular it should be possible to own a link local address, connect to any LoWPAN or to the backbone with that address, and ping any other link local address connected to any LoWPAN or to the backbone with that address. This is where the proxy ND comes from. Very close to RFC 3775 (MIPv6) using the backbone link similarly to a home link, but a different flavor of registration because there is no CoA and no need for tunnel. ND on the backbone enables the cohabitation of MIP and BbR protocols so that a LoWPAN node can move locally or far far away. Once you have a registry you can use it for the purpose of DAD and NS lookup. Thus the discussion on proactive white board. This does not prevent the use of reactive white boarding through the registry or any other Backbone router so forwarding could be maintained upon registry failure if we make the necessary efforts in the protocol. As you see, the proxy ND function is the core of the draft, and the white board is a benefit. Yes, we do need to handle RAs efficiently and we do need a redundancy technique for the BbRs. >> If the group >> agrees that this is the direction then we can dig further and merging >> with draft-chakrabarti would be an excellent idea. It is clear to me >> that my Draft 00 falls short in a number of occasions which were not the >> focus at the time. >> >> - registration mechanism. DHCP formats make more sense than NS/NA that I >> used. I asked Benoit Lourdelet to join as a coauthor to rework that. I >> also got comments that a totally new format could be welcome, along the >> lines of RFC 3775 Binding Update (though the BU as it stands is not fit >> for the job) but for the time being I'd rather stick to DHCPv6 and see >> the feedback from the group. > >But you'd also need to handle a distributed whiteboard so you whiteboard >doesn't become a SPoF. And if you use (unicast) NS as the way to do >lookups from the whiteboard, then there is a strong reason to co-locate >the whiteboard with the entity handling the NS; it might make sense to >have a common protocol for registrations and lookups. Neither current ND >nor current DHCP is a good fit for a combined registration and lookup >protocol. Furthermore, if we want to add key distribution to the fix, >then the requirements on the registration and lookup protocol (or >protocols) changes. > [Pascal] I agree (almost) all the way through. I'd add that: - WRT SPoF: Distributing the white board is similar to distributing the HAs in MIP. They collectively own the table of all the registered addresses on the "home" backbone link. If one dies, there is an interruption of service for the nodes it serves till they register somewhere else. I've been trying to introduce a secondary registration to enable hot stand by, bicasting and uninterrupted service but I'm not sure it's a such a good idea. Maybe it's better to leave the redundancy up to the vendors as we do with MIP. - WRT DHCP relevancy: I talked to DHCP specialists in cisco and they felt that DHCP could do stateful registrations and lookups nicely using RFC 5007 for the lookup. I plan to publish a draft 01 with text from Benoit that proposes just that as a base for the discussion. Certainly I'm completely open to a new protocol if your approach prevails within the group. I just found that DHCP was way closer than MIP to the registration solution that we need and a good starting point. DHCP also enables the BbR to compute a SeND CGA address on behalf of the mote that might not want to spend half its battery in the process. Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Apr 15 03:00:46 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 core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 556EA3A6A11; Tue, 15 Apr 2008 03:00:46 -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 59C1E3A692E for <6lowpan@core3.amsl.com>; Tue, 15 Apr 2008 03:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.24 X-Spam-Level: X-Spam-Status: No, score=-4.24 tagged_above=-999 required=5 tests=[AWL=1.759, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJf2K1VQnstT for <6lowpan@core3.amsl.com>; Tue, 15 Apr 2008 03:00:35 -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 BC9AF3A6A11 for <6lowpan@ietf.org>; Tue, 15 Apr 2008 03:00:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,660,1199660400"; d="scan'208";a="6304746" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2008 12:01:00 +0200 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 m3FA10W7013768; Tue, 15 Apr 2008 12:01:00 +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 m3FA0xgh013165; Tue, 15 Apr 2008 10:01:00 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 12:00:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 12:00:21 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0585A39F@xmb-ams-337.emea.cisco.com> In-Reply-To: <47D57813.10201@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New 6LoWPAN HC Draft Availble thread-index: AciC2Zs406q3hThiTUuwMSzVunpMkgcBP47w References: <47D57813.10201@archrock.com> From: "Pascal Thubert (pthubert)" To: "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 15 Apr 2008 10:00:53.0228 (UTC) FILETIME=[973C82C0:01C89EDF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1375; t=1208253660; x=1209117660; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20New=206LoWPAN=20HC=20Draft= 20Availble |Sender:=20; bh=HwjO4AejGgKHOXzd6ccF2euVHDGbbyShzE+GqwIQ4R8=; b=WZfyPpK04sZnSkruGICN4D/5t+UcyWmyiZGsoAM7MnRnxJ9kYHo6W8knsu 2nk7ScpWASVtHbfx9OR2SM/qNmWn28qRfiLrJSy1L8f5HdsHSVFYYKqFvbx3 JycHTG7Ln+; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [6lowpan] New 6LoWPAN HC Draft Availble X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Dear chairs: There is a strong and identified need for this draft out there; the new capabilities are required by ISA100.11a but seem to make sense in the general case. The alternate for ISA might very well be to use NALP for all its dispatch types, which would be very unfortunate for both groups. I've not seen strong opposition to the draft but if there is, then let's talk about it and resolve the issues. IMHO, the best way to move forward at this point is to launch the process to promote Jonathan's draft as a WG doc. What do you think? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: lundi 10 mars 2008 19:04 >To: 6lowpan >Subject: [6lowpan] New 6LoWPAN HC Draft Availble > > >6LoWPAN WG, > >There's a new draft available that specifies a new header compression >format for 6LoWPAN networks. It's a follow-on to the HC1g draft. It also >captures some of the discussion with Pascal last week. > >http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc-00.txt > >Read it over before the WG meeting if you get a chance. Provide comments >or suggestions on the list. > >Thanks. > >-- >Jonathan Hui >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Apr 15 13:24: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 core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8E63A67D4; Tue, 15 Apr 2008 13:24: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 710D23A67B6 for <6lowpan@core3.amsl.com>; Tue, 15 Apr 2008 13:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shsdfs6DArvK for <6lowpan@core3.amsl.com>; Tue, 15 Apr 2008 13:24:01 -0700 (PDT) Received: from mail.nivis.com (mail.nivis.com [65.205.163.229]) by core3.amsl.com (Postfix) with SMTP id 848F73A6BE9 for <6lowpan@ietf.org>; Tue, 15 Apr 2008 13:24:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 16:24:30 -0400 Message-ID: In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0585A39F@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New 6LoWPAN HC Draft Availble Thread-Index: AciC2Zs406q3hThiTUuwMSzVunpMkgcBP47wABXzo2A= References: <47D57813.10201@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC0585A39F@xmb-ams-337.emea.cisco.com> From: "Robert Assimiti" To: "Pascal Thubert (pthubert)" , "6lowpan" <6lowpan@ietf.org> Subject: Re: [6lowpan] New 6LoWPAN HC Draft Availble X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hello Pascal, I completely agree with you that promoting the draft to WG doc status would= be beneficial for the future of both ISA100.11a and 6loWPAN. = Rob "The nice thing about standards is that there are so many to choose from." = - Andrew S. Tanenbaum = Robert Assimiti Executive Staff=A0Engineer Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Pascal Thubert (pthubert) Sent: Tuesday, April 15, 2008 6:00 AM To: 6lowpan Subject: Re: [6lowpan] New 6LoWPAN HC Draft Availble Dear chairs: There is a strong and identified need for this draft out there; the new capabilities are required by ISA100.11a but seem to make sense in the general case. The alternate for ISA might very well be to use NALP for all its dispatch types, which would be very unfortunate for both groups. I've not seen strong opposition to the draft but if there is, then let's talk about it and resolve the issues. IMHO, the best way to move forward at this point is to launch the process to promote Jonathan's draft as a WG doc. What do you think? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: lundi 10 mars 2008 19:04 >To: 6lowpan >Subject: [6lowpan] New 6LoWPAN HC Draft Availble > > >6LoWPAN WG, > >There's a new draft available that specifies a new header compression >format for 6LoWPAN networks. It's a follow-on to the HC1g draft. It also >captures some of the discussion with Pascal last week. > >http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc-00.txt > >Read it over before the WG meeting if you get a chance. Provide comments >or suggestions on the list. > >Thanks. > >-- >Jonathan Hui >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan This e-mail (including any attachments to it) is confidential, proprietary,= legally privileged, subject to copyright and is sent for the personal atte= ntion of the intended recipient only. If you have received this e-mail in e= rror, please reply to advise us immediately, delete it and destroy any prin= ted copies of it. You are notified that reading, disclosing, copying, distr= ibuting or taking any action in reliance on the contents of this informatio= n is strictly prohibited. No employee is authorized to conclude any binding= agreement on behalf of NIVIS LLC with another party by e-mail without expr= ess written confirmation by an officer of the company. Although we have tak= en reasonable precautions to ensure no viruses are present in this e-mail, = we cannot accept responsibility for any loss or damage arising from the vir= uses in this e-mail or attachments. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan