From zach@sensinode.com Wed Apr 1 01:44:21 2009 Return-Path: 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 5D94D3A67A7 for <6lowpan@core3.amsl.com>; Wed, 1 Apr 2009 01:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-5kv+ltSvEY for <6lowpan@core3.amsl.com>; Wed, 1 Apr 2009 01:44:20 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 0D75E3A680C for <6lowpan@ietf.org>; Wed, 1 Apr 2009 01:44:19 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n318jFV5018838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Wed, 1 Apr 2009 11:45:15 +0300 Message-ID: <49D329A7.6080300@sensinode.com> Date: Wed, 01 Apr 2009 11:45:27 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowpan] ND for 6LoPWAN - tickets from SFO 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: , X-List-Received-Date: Wed, 01 Apr 2009 08:44:21 -0000 Hi, Thanks everyone from a great meetings at SFO. It was a productive IETF, and we collected lots of good feedback on draft-ietf-nd-02. We plan on releasing -03 of the draft within a couple weeks. I have opened up tickets for all the issues collected recently on the mailing list, in the WG meeting, and by the authors. See: http://trac.tools.ietf.org/wg/6lowpan/trac/report/1 We currently have 8 tickets there, mostly pretty minor. Please take a look that your issues are covered and throw a note to the list if there is something we are missing. - Regarding the naming of Router Registration (RR) we decided to make no change at this time. - Regarding the inclusion of a metric to the Multihop Information Option for determining the best router for hosts not participating in routing: Carsten will propose a solution to the list... http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/25 - After seeing how the terminology is developing in ROLL I have a suggestion. Should we synchronize our terminology and rename LoWPAN Edge Router to LoWPAN Border Router so as to minimize confusion? Zach -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From pthubert@cisco.com Thu Apr 2 09:13:16 2009 Return-Path: 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 52BD03A681D for <6lowpan@core3.amsl.com>; Thu, 2 Apr 2009 09:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.944 X-Spam-Level: X-Spam-Status: No, score=-7.944 tagged_above=-999 required=5 tests=[AWL=-1.345, 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 1PN9LmpE-Chr for <6lowpan@core3.amsl.com>; Thu, 2 Apr 2009 09:13:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4A8033A6998 for <6lowpan@ietf.org>; Thu, 2 Apr 2009 09:12:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,314,1235952000"; d="scan'208";a="165698787" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-1.cisco.com with ESMTP; 02 Apr 2009 15:47:52 +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 n32FlpeJ003276 for <6lowpan@ietf.org>; Thu, 2 Apr 2009 17:47: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 n32Flpie004148 for <6lowpan@ietf.org>; Thu, 2 Apr 2009 15:47: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); Thu, 2 Apr 2009 17:47:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 2 Apr 2009 17:47:46 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC073C3C63@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-thubert-6lowpan-simple-fragment-recovery-05 Thread-Index: AcmvTabtGma+eRu/RcS3d+P3fUbS8QEW2ZVA From: "Pascal Thubert (pthubert)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 02 Apr 2009 15:47:51.0296 (UTC) FILETIME=[612D9800:01C9B3AA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2506; t=1238687271; x=1239551271; 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:=20FW=3A=20New=20Version=20Notification=20for=20dr aft-thubert-6lowpan-simple-fragment-recovery-05=20 |Sender:=20; bh=7kNn0Iojf1xAWtxg01JlMfX9zAWYjIZ3IjxLlsFDenQ=; b=h/nwUqZFQ/0mXqX214ZRwozakbXMH6Ih3J/VXRElvleKH9FUwOvz+ZQ4uU efAkH4JvpF9jcJRU86E08ihHem83qnMvdw6zl6ZISTOKvRYCch6qWAH/+BYs 6MCUrNHe3C; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [6lowpan] FW: New Version Notification for draft-thubert-6lowpan-simple-fragment-recovery-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: , X-List-Received-Date: Thu, 02 Apr 2009 16:13:16 -0000 RGVhciA2TG9XUEFOZXJzLA0KDQpXZSBwdWJsaXNoZWQgYSBuZXcgdmVyc2lvbiBqdXN0IHRvIG1h a2UgaXQgY2xlYXIgdGhhdCB0aGUgYWNrIG1lc3NhZ2UgaXMgYSBzdGFuZGFsb25lIG9wdGlvbiBm b3IgdGhlIHRpbWUgYmVpbmcuDQpUaGUgbWVzc2FnZXMgZmxpZXMgYmFjayB0byB0aGUgc291cmNl IG1hYyBhZGRyZXNzLiAgTm90ZTogSWYgdGhhdCBpcyBub3Qgc3VmZmljaWVudCAobm8gbWFjIG9y IHRoZSBmcmFnbWVudHMgYXJlIGxhYmVsIHN3aXRjaGVkIGJhc2VkIG9uIHRoZSB0YWcpIHRoZW4g dGhlIGRhdGFncmFtX3RhZyBpcyB1c2VkIHRvIGhlbHAgZmluZHMgdGhlIHdheSBiYWNrIGFzIHdl bGwuDQoNCkRlYXIgY2hhaXJzIGFuZCBBLURzOiBjb25zaWRlcmluZyB0aGUgc3VwcG9ydCBieSB0 aGUgZ3JvdXAgZXhwcmVzc2VkIGluIFNGTywgaXMgdGhlcmUgYSB3YXkgdG8gYWNjb21tb2RhdGUg dGhpcyB3b3JrIGFzIGEgV0cgZG9jPw0KDQpQYXNjYWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlkc3VibWlzc2lv bkBpZXRmLm9yZ10gDQpTZW50OiBzYW1lZGkgMjggbWFycyAyMDA5IDAzOjMzDQpUbzogUGFzY2Fs IFRodWJlcnQgKHB0aHViZXJ0KQ0KQ2M6IGpodWlAYXJjaHJvY2suY29tDQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRodWJlcnQtNmxvd3Bhbi1zaW1wbGUtZnJh Z21lbnQtcmVjb3ZlcnktMDUgDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXRodWJl cnQtNmxvd3Bhbi1zaW1wbGUtZnJhZ21lbnQtcmVjb3ZlcnktMDUudHh0IGhhcyBiZWVuIHN1Y2Nl c3NmdWx5IHN1Ym1pdHRlZCBieSBQYXNjYWwgVGh1YmVydCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtdGh1YmVydC02bG93cGFuLXNpbXBsZS1m cmFnbWVudC1yZWNvdmVyeQ0KUmV2aXNpb246CSAwNQ0KVGl0bGU6CQkgTG9XUEFOIHNpbXBsZSBm cmFnbWVudCBSZWNvdmVyeQ0KQ3JlYXRpb25fZGF0ZToJIDIwMDktMDMtMjgNCldHIElEOgkJIElu ZGVwZW5kZW50IFN1Ym1pc3Npb24NCk51bWJlcl9vZl9wYWdlczogMTINCg0KQWJzdHJhY3Q6DQpD b25zaWRlcmluZyB0aGF0IDZMb1dQQU4gcGFja2V0cyBjYW4gYmUgYXMgbGFyZ2UgYXMgMksgYnl0 ZXMgYW5kIHRoYXQNCmFuIDgwMi4xNS40IGZyYW1lIHdpdGggc2VjdXJpdHkgd2lsbCBjYXJyeSBp biB0aGUgb3JkZXIgb2YgODAgYnl0ZXMNCm9mIGVmZmVjdGl2ZSBwYXlsb2FkLCBhIHBhY2tldCBt aWdodCBlbmQgdXAgZnJhZ21lbnRlZCBpbnRvIGFzIG1hbnkNCmFzIDI1IGZyYWdtZW50cyBhdCB0 aGUgNkxvV1BBTiBzaGltIGxheWVyLiAgSWYgYSBzaW5nbGUgb25lIG9mIHRob3NlDQpmcmFnbWVu dHMgaXMgbG9zdCBpbiB0cmFuc21pc3Npb24sIGFsbCBmcmFnbWVudHMgbXVzdCBiZSByZXNlbnQs DQpmdXJ0aGVyIGNvbnRyaWJ1dGluZyB0byB0aGUgY29uZ2VzdGlvbiB0aGF0IG1pZ2h0IGhhdmUg Y2F1c2VkIHRoZQ0KaW5pdGlhbCBwYWNrZXQgbG9zcy4gIFRoaXMgZHJhZnQgaW50cm9kdWNlcyBh IHNpbXBsZSBwcm90b2NvbCB0bw0KcmVjb3ZlciBpbmRpdmlkdWFsIGZyYWdtZW50cyB0aGF0IG1p Z2h0IGJlIGxvc3Qgb3ZlciBtdWx0aXBsZSBob3BzDQpiZXR3ZWVuIDZMb1dQQU4gZW5kcG9pbnRz Lg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0Lg0K DQoNCg== From hamid.mukhtar@gmail.com Thu Apr 2 18:54:29 2009 Return-Path: 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 F051A3A6B52 for <6lowpan@core3.amsl.com>; Thu, 2 Apr 2009 18:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[AWL=-0.919, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqJelPHAXxpY for <6lowpan@core3.amsl.com>; Thu, 2 Apr 2009 18:54:29 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 292EF3A6C30 for <6lowpan@ietf.org>; Thu, 2 Apr 2009 18:53:10 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so805267rvb.49 for <6lowpan@ietf.org>; Thu, 02 Apr 2009 18:54:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <33e401c9b3fc$3511cfa0$8310fe81@etri.info> References: <33e401c9b3fc$3511cfa0$8310fe81@etri.info> Date: Fri, 3 Apr 2009 10:53:57 +0900 Received: by 10.141.2.18 with SMTP id e18mr261536rvi.127.1238723652128; Thu, 02 Apr 2009 18:54:12 -0700 (PDT) Message-ID: From: Hamid Mukhtar To: 6lowpan@ietf.org Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Subject: [6lowpan] Fwd: New Version Notification for draft-hamid-6lowpan-snmp-optimizations-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 01:54:30 -0000 Dear 6LoWPANers, The draft for SNMPv3 optimizations for 6LoWPANs has been updated. The draft initially covers possible deployment models for SNMP and goals its optimization for 6LoWPAN. SNMPv3 functionality is critical for 6LoWPANs. I would like to ask the chairs to include 'Management' as a work item once the working group recharters. Is anyone from the group interested in working on this. ---------- Forwarded message ---------- From: =C7=CF=B9=CC=B5=E5 Date: 2009/4/3 Subject: FW: New Version Notification for draft-hamid-6lowpan-snmp-optimizations-01 To: hamid.mukhtar@gmail.com -----=BF=F8=BA=BB =B8=DE=BD=C3=C1=F6----- From: "IETF I-D Submission Tool" >From Date: 2009-04-03 =BF=C0=C0=FC 10:29:36 To: "hamid@etri.re.kr" Cc: "ssjoo@etri.re.kr" , "j.schoenwaelder@jacobs-university.de" Subject: New Version Notification for draft-hamid-6lowpan-snmp-optimization= s-01 A new version of I-D, draft-hamid-6lowpan-snmp-optimizations-01.txt has been successfuly submitted by Hamid Mukhtar and posted to the IETF repository. Filename: draft-hamid-6lowpan-snmp-optimizations Revision: 01 Title: SNMP optimizations for 6LoWPAN Creation_date: 2009-04-03 WG ID: Independent Submission Number_of_pages: 12 Abstract: This draft proposes SNMPv3 optimizations for its use in 6LoWPANs. The draft presents optimization goals, issues, and the optimization approaches to enable the use of SNMP under the given memory, processing, and message size constraints imposed by 6LoWPANs. The IETF Secretariat. Regards, Hamid From alexandru.petrescu@gmail.com Fri Apr 3 01:50:41 2009 Return-Path: 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 6209C3A69CF for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 01:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.525 X-Spam-Level: X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xH8bLceBk0zJ for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 01:50:40 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 2997A3A6979 for <6lowpan@ietf.org>; Fri, 3 Apr 2009 01:50:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n338peBf018307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <6lowpan@ietf.org>; Fri, 3 Apr 2009 10:51:40 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n338sJVD001570 for <6lowpan@ietf.org>; Fri, 3 Apr 2009 10:54:19 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n338peXO004448 for <6lowpan@ietf.org>; Fri, 3 Apr 2009 10:51:40 +0200 Message-ID: <49D5CE1C.9080902@gmail.com> Date: Fri, 03 Apr 2009 10:51:40 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 CC: 6lowpan <6lowpan@ietf.org> References: <49D329A7.6080300@sensinode.com> In-Reply-To: <49D329A7.6080300@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [6lowpan] multihop information option metric (was: ND for 6LoPWAN - tickets from SFO) 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: , X-List-Received-Date: Fri, 03 Apr 2009 08:50:41 -0000 Zach Shelby a écrit : [...] > - Regarding the inclusion of a metric to the Multihop Information Option > for determining the best router for hosts not participating in > routing: Carsten will propose a solution to the list... > http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/25 Issue 25: > The issues is that some scalar metric representing the cost to the > best ER through a Router should be advertised in RAs. What goes in > the metric is determined by some routing algorithm but should be an > easily comparable scalar for nodes to use simply to determine which > router to use as a default without knowing anything about routing. Let me ask clarification about 'best router', in this example topology: ------ RA1 ------- RA3 ------- |Host |---+--|Router1|-----|Router3|\ ------ | ------- ------- \_______Internet | ------- / +--|Router2|--------------/ RA2 ------- -what do you assume Host should choose as 'best router' - Router1, Router2 or Router3? -did I assume correctly the subnet structure above? Alex > > - After seeing how the terminology is developing in ROLL I have a > suggestion. Should we synchronize our terminology and rename LoWPAN Edge > Router to LoWPAN Border Router so as to minimize confusion? > > Zach > From Peter.Siklosi@tritech.se Fri Apr 3 04:50:19 2009 Return-Path: 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 580623A6BFA for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 04:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.414 X-Spam-Level: X-Spam-Status: No, score=-1.414 tagged_above=-999 required=5 tests=[AWL=0.835, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJiN2miidnOM for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 04:50:18 -0700 (PDT) Received: from tritech.se (tritech.se [91.191.137.61]) by core3.amsl.com (Postfix) with ESMTP id A3B5F28C287 for <6lowpan@ietf.org>; Fri, 3 Apr 2009 04:49:26 -0700 (PDT) Received: from srvsund01.tritech.se (srvsund01.tritech.se [10.75.60.4]) by tritech.se (8.13.5/8.13.5) with ESMTP id n33Bo67A028960 for <6lowpan@ietf.org>; Fri, 3 Apr 2009 11:50:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 13:50:04 +0200 Message-ID: In-Reply-To: <49D5CE1C.9080902@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] multihop information option metric (was: ND for 6LoPWAN - tickets from SFO) Thread-Index: Acm0OX8hikh87EzkRPefiDqraf3WfQABJopg References: <49D329A7.6080300@sensinode.com> <49D5CE1C.9080902@gmail.com> From: "Peter Siklosi" To: <6lowpan@ietf.org> X-CT-RefID: str=0001.0A0B0209.49D5F7EE.00EE,ss=1,fgs=0 Subject: Re: [6lowpan] multihop information option metric (was: ND for 6LoPWAN - tickets from SFO) 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: , X-List-Received-Date: Fri, 03 Apr 2009 11:50:19 -0000 Alexandru Petrescu wrote: >Zach Shelby wrote: >> The issues is that some scalar metric representing the cost to the >> best ER through a Router should be advertised in RAs. What goes in >> the metric is determined by some routing algorithm but should be an >> easily comparable scalar for nodes to use simply to determine which >> router to use as a default without knowing anything about routing. >Let me ask clarification about 'best router', in this example topology: > > ------ RA1 ------- RA3 ------- > |Host |---+--|Router1|-----|Router3|\ > ------ | ------- ------- \_______Internet > | ------- / > +--|Router2|--------------/ > RA2 ------- > >-what do you assume Host should choose as 'best router' - Router1, > Router2 or Router3? >-did I assume correctly the subnet structure above? In the figure above, I assume that "Internet" would represent the edge router and that the lines are the possible links, so the host can communicate directly with Router1 and Router2, but cannot reach router3 directly. The question is then if router1 or router2 should be selected. In my mind, the simplest model would be to represent the cost as hop count and in this case router1 would advertise the cost 2, while router2 would advertise the cost 1. The host would then select router2 based on lowest cost, which would in this case be the shortest route to edge router. In practical cases, this would be infinitely better than selecting routers by random, but still not perfect. A better model would be to take link quality into account. In this case, the cost going through router1 is a function of the link quality of the link to router1 and the cost from router1 to the edge router. It would probably be best to define the cost as the sum of the cost to router1 and the cost from router1 to the edge router and we should require the link cost to be at least one. By this procedure, it would still be possible to use just hop count, but also possible to use something slightly more sophisticated. Peter From cabo@tzi.org Fri Apr 3 05:10:07 2009 Return-Path: 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 7B0473A6C1F for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 05:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 arQBu0gRaKrA for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 05:10:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id 0B81C3A682A for <6lowpan@ietf.org>; Fri, 3 Apr 2009 05:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id n33CAdtX012763; Fri, 3 Apr 2009 14:10:39 +0200 (CEST) Received: from [192.168.217.107] (p5489B611.dip.t-dialin.net [84.137.182.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 44BB61704D7; Fri, 3 Apr 2009 14:10:39 +0200 (CEST) From: Carsten Bormann To: "Peter Siklosi" In-Reply-To: References: <49D329A7.6080300@sensinode.com> <49D5CE1C.9080902@gmail.com> Message-Id: <2784F829-89FE-4666-BDA7-BD83F7F2CC56@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 14:10:38 +0200 X-Mailer: Apple Mail (2.930.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] multihop information option metric (was: ND for 6LoPWAN - tickets from SFO) 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: , X-List-Received-Date: Fri, 03 Apr 2009 12:10:07 -0000 On Apr 3, 2009, at 13:50, Peter Siklosi wrote: > In my mind, the simplest model would be to represent the cost as ND in 6lowpan is (mainly) about the host-router interface. Does the host even have to know about the way the router metric is computed? The host (if it wants to be just a host) should not need to know about the routing protocol and its metrics. I have therefore proposed the ND metric to simply be a 16-bit integer, with a mid-range default (i.e., 0x8000 if the number is unsigned). Routing protocols may want to define a way how to compute that integer at a router so that multiple routers present numbers that make sense when used together by a host. (And that may not exclude use of the value found via ND in bootstrapping a router. Still outside the scope of ND proper.) BTW, standard IPv6 ND does not have such a metric for the following stated reason: Unlike in IPv4 Router Discovery, the Router Advertisement messages do not contain a preference field. The preference field is not needed to handle routers of different "stability"; the Neighbor Unreachability Detection will detect dead routers and switch to a working one. [RFC 4861, p 16]. This thinking does not really seem to apply to 6lowpans very well. Gruesse, Carsten (No WG chair hats included in this message.) From zach@sensinode.com Fri Apr 3 07:00:53 2009 Return-Path: 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 716C93A6B92 for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 07:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tkccmjP4H3L for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 07:00:52 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 2BE413A657C for <6lowpan@ietf.org>; Fri, 3 Apr 2009 07:00:51 -0700 (PDT) Received: from pc-ab47.wlan.inet.fi (pc-ab47.wlan.inet.fi [193.211.2.47]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n33E1mcH003539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 17:01:49 +0300 Message-ID: <49D616CD.7050906@sensinode.com> Date: Fri, 03 Apr 2009 17:01:49 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Carsten Bormann References: <49D329A7.6080300@sensinode.com> <49D5CE1C.9080902@gmail.com> <2784F829-89FE-4666-BDA7-BD83F7F2CC56@tzi.org> In-Reply-To: <2784F829-89FE-4666-BDA7-BD83F7F2CC56@tzi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] multihop information option metric 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: , X-List-Received-Date: Fri, 03 Apr 2009 14:00:53 -0000 Hi, Carsten Bormann wrote: > On Apr 3, 2009, at 13:50, Peter Siklosi wrote: > >> In my mind, the simplest model would be to represent the cost as > > ND in 6lowpan is (mainly) about the host-router interface. > Does the host even have to know about the way the router metric is > computed? > The host (if it wants to be just a host) should not need to know about > the routing protocol and its metrics. > > I have therefore proposed the ND metric to simply be a 16-bit integer, > with a mid-range default (i.e., 0x8000 if the number is unsigned). > Routing protocols may want to define a way how to compute that integer > at a router so that multiple routers present numbers that make sense > when used together by a host. (And that may not exclude use of the value > found via ND in bootstrapping a router. Still outside the scope of ND > proper.) > > BTW, standard IPv6 ND does not have such a metric for the following > stated reason: > > Unlike in IPv4 Router Discovery, the Router Advertisement messages > do not contain a preference field. The preference field is not > needed to handle routers of different "stability"; the Neighbor > Unreachability Detection will detect dead routers and switch to a > working one. > > [RFC 4861, p 16]. This thinking does not really seem to apply to > 6lowpans very well. I support this proposal myself, and think it is a nice solution to the concern Peter brought up. The Multihop Information Option in draft-ietf-nd has plenty of reserved space for such a 16-bit option. This is also compatible with e.g. the work going on in ROLL as this information is meant for hosts that don't have knowledge of the routing algorithm. If a ROLL algorithm would produce such a metric - the router would simply copy that into this field for use by hosts. With regard to integrating this into -03 of the draft, we would need to see some more consensus support on the list. Who else finds this useful? - Zach > Gruesse, Carsten > > (No WG chair hats included in this message.) > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From bmarq@estv.ipv.pt Fri Apr 3 07:02:12 2009 Return-Path: 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 A59C928C0FB for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 07:02:12 -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 3QSQcH069nyZ for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 07:02:12 -0700 (PDT) Received: from vinfante.estv.ipv.pt (infante.estv.ipv.pt [193.137.7.3]) by core3.amsl.com (Postfix) with ESMTP id 544903A6DA5 for <6lowpan@ietf.org>; Fri, 3 Apr 2009 07:02:10 -0700 (PDT) Received: (qmail 19491 invoked by uid 89); 3 Apr 2009 14:03:16 -0000 Received: from unknown (HELO converter-x1.ipv.pt) (bmarq@estv.ipv.pt@172.16.30.108) by 0 with ESMTPA; 3 Apr 2009 14:03:16 -0000 Message-Id: From: Bruno Marques To: 6lowpan@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 15:03:13 +0100 X-Mailer: Apple Mail (2.930.3) Subject: [6lowpan] 6LoWPAN + LOAD NS-2 Implementation 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: , X-List-Received-Date: Fri, 03 Apr 2009 14:02:12 -0000 Hello I'm a portuguese PhD Student at the Engineering Faculty of the University of Porto (FEUP). I'm researching on low power routing protocols and p2p systems. In that context, somebody could distribute me the source code of 6LoWPAN Adaptation layer and LOAD routing protocol implementation in NS-2 ? Thanking you in advance, best wishes, ------------------------------------------------------------------ Bruno Filipe Marques, MsC in Electrical and Computer Engineering FCT PhD Schollarship (SFRH/BD/36221/2007) PhD Student @ DEEC/FEUP WiMobNet, UTM, INESC Porto, From pthubert@cisco.com Fri Apr 3 07:38:29 2009 Return-Path: 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 5E0F43A68CF for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 07:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.894 X-Spam-Level: X-Spam-Status: No, score=-7.894 tagged_above=-999 required=5 tests=[AWL=-1.295, 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 Q1VXKnVDOQ5D for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 07:38:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 24E053A688D for <6lowpan@ietf.org>; Fri, 3 Apr 2009 07:38:28 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2009 14:39:30 +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 n33EdT4b023907; Fri, 3 Apr 2009 16:39:29 +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 n33EdQsE012327; Fri, 3 Apr 2009 14:39:29 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); Fri, 3 Apr 2009 16:39:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 16:39:23 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC073C40F4@xmb-ams-337.emea.cisco.com> In-Reply-To: <49D616CD.7050906@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] multihop information option metric Thread-Index: Acm0ZNLIypCmuj/sREaEZucYYy7KpgABCYcA References: <49D329A7.6080300@sensinode.com><49D5CE1C.9080902@gmail.com> <2784F829-89FE-4666-BDA7-BD83F7F2CC56@tzi.org> <49D616CD.7050906@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "Carsten Bormann" X-OriginalArrivalTime: 03 Apr 2009 14:39:28.0886 (UTC) FILETIME=[FE5D4160:01C9B469] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4537; t=1238769569; x=1239633569; 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]=20multihop=20information=20op tion=20metric |Sender:=20; bh=+IobwI4buJZ0nqensLja/kx599vVB3AgBnJ5ZhrnePA=; b=vmiu4Vm7XvWHwXEVTvXl5gvsBBDuJUAOUFahmEKd8FfHIz2ZgKDIGfvt/Z Zg5ABxxQuCHn4kuw4rdRpK4lYZzD0SVR7VF3kK70jtRebU5TSCh4i6qbxtGl UiPwVWnD+l; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] multihop information option metric 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: , X-List-Received-Date: Fri, 03 Apr 2009 14:38:29 -0000 I agree with Carsten and Zach: The metric is opaque to the host because it is (derived from) a routing metric and the host does not route. But when it comes to forwarding, then the host would benefit from using it wisely. In more details: - We just make the router preference a bit wider in size than RFC 4191 but the host is clueless about what that means; all it does is compare opaque scalar to opaque scalar. It's probably up to ROLL to give it a meaning and a value but that's out of scope for our spec. - The metric might fluctuate but it's not crucial for the host default router selection as long as the default router still enables reachability to/from an edge router. In Other Words the host does not have to switch default router (and reregister to the edge router) each time that metric varies though it should lazily try to stick to the best one to optimize the return path from the edge router. - But a host might favor the best metric router as next hop on a per packet basis if it likes. And if sending a packet to a router fails then it might select the next best in the default router list per that metric. In that, forwarding host to router is pretty similar to forwarding router to router within the LoWPAN - if ROLL enables this that is. Maybe we need a bit of text to be more specific on all this? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby >Sent: vendredi 3 avril 2009 16:02 >To: Carsten Bormann >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] multihop information option metric > >Hi, > >Carsten Bormann wrote: >> On Apr 3, 2009, at 13:50, Peter Siklosi wrote: >> >>> In my mind, the simplest model would be to represent the cost as >> >> ND in 6lowpan is (mainly) about the host-router interface. >> Does the host even have to know about the way the router metric is >> computed? >> The host (if it wants to be just a host) should not need to know about >> the routing protocol and its metrics. >> >> I have therefore proposed the ND metric to simply be a 16-bit integer, >> with a mid-range default (i.e., 0x8000 if the number is unsigned). >> Routing protocols may want to define a way how to compute that integer >> at a router so that multiple routers present numbers that make sense >> when used together by a host. (And that may not exclude use of the value >> found via ND in bootstrapping a router. Still outside the scope of ND >> proper.) >> >> BTW, standard IPv6 ND does not have such a metric for the following >> stated reason: >> >> Unlike in IPv4 Router Discovery, the Router Advertisement messages >> do not contain a preference field. The preference field is not >> needed to handle routers of different "stability"; the Neighbor >> Unreachability Detection will detect dead routers and switch to a >> working one. >> >> [RFC 4861, p 16]. This thinking does not really seem to apply to >> 6lowpans very well. > >I support this proposal myself, and think it is a nice solution to the >concern Peter brought up. The Multihop Information Option in >draft-ietf-nd has plenty of reserved space for such a 16-bit option. >This is also compatible with e.g. the work going on in ROLL as this >information is meant for hosts that don't have knowledge of the routing >algorithm. If a ROLL algorithm would produce such a metric - the router >would simply copy that into this field for use by hosts. > >With regard to integrating this into -03 of the draft, we would need to >see some more consensus support on the list. Who else finds this useful? > >- Zach > >> Gruesse, Carsten >> >> (No WG chair hats included in this message.) >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > >-- >http://zachshelby.org - My blog "On the Internet of Things" >Mobile: +358 40 7796297 > >Zach Shelby >Head of Research >Sensinode Ltd. >Kidekuja 2 >88610 Vuokatti, FINLAND > >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 alexandru.petrescu@gmail.com Fri Apr 3 13:00:33 2009 Return-Path: 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 2FA583A67D1 for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 13:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhdbksTxmwu6 for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 13:00:32 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 22FAE3A6452 for <6lowpan@ietf.org>; Fri, 3 Apr 2009 13:00:30 -0700 (PDT) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 4835A94014D; Fri, 3 Apr 2009 22:01:29 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 019A9940091; Fri, 3 Apr 2009 22:01:26 +0200 (CEST) Message-ID: <49D66B1E.1070901@gmail.com> Date: Fri, 03 Apr 2009 22:01:34 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Peter Siklosi References: <49D329A7.6080300@sensinode.com> <49D5CE1C.9080902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] multihop information option metric 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: , X-List-Received-Date: Fri, 03 Apr 2009 20:00:33 -0000 Peter Siklosi a écrit : > Alexandru Petrescu wrote: >> Zach Shelby wrote: >>> The issues is that some scalar metric representing the cost to >>> the best ER through a Router should be advertised in RAs. What >>> goes in the metric is determined by some routing algorithm but >>> should be an easily comparable scalar for nodes to use simply to >>> determine which router to use as a default without knowing >>> anything about routing. > >> Let me ask clarification about 'best router', in this example >> topology: >> >> ------ RA1 ------- RA3 ------- |Host >> |---+--|Router1|-----|Router3|\ ------ | ------- ------- >> \_______Internet | ------- / >> +--|Router2|--------------/ RA2 ------- >> >> -what do you assume Host should choose as 'best router' - Router1, >> Router2 or Router3? -did I assume correctly the subnet structure >> above? [...] > In my mind, the simplest model would be to represent the cost as hop > count and in this case router1 would advertise the cost 2, while > router2 would advertise the cost 1. The host would then select > router2 based on lowest cost, which would in this case be the > shortest route to edge router. I agree. But remark I represented Router1 and 2 as devices with two interfaces, and a different subnet for each interface. Not sure this is the case for 6LoWPAN ND. Indeed there seems to be a need for a Cost to be put in the RA but not sure it applies well in the subnet structure here, because 6lowpan ND considers sometimes mesh-under intertwinned with route-over... which is confusing. Were it for Router1 and 2 in 6lowpan ND to have two real interfaces, two different subnets, then I'd agree with the use of Cost as you suggest. Otherwise I'm not clear what a hop is at all (in multihop option metric). Alex In practical cases, this would be infinitely better than > selecting routers by random, but still not perfect. > > A better model would be to take link quality into account. In this > case, the cost going through router1 is a function of the link > quality of the link to router1 and the cost from router1 to the edge > router. It would probably be best to define the cost as the sum of > the cost to router1 and the cost from router1 to the edge router and > we should require the link cost to be at least one. By this > procedure, it would still be possible to use just hop count, but also > possible to use something slightly more sophisticated. > > Peter > > _______________________________________________ 6lowpan mailing list > 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan > From alexandru.petrescu@gmail.com Fri Apr 3 13:13:05 2009 Return-Path: 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 3291F3A6862 for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 13:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMXOK-0QpoLW for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 13:13:04 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id E83523A6885 for <6lowpan@ietf.org>; Fri, 3 Apr 2009 13:12:58 -0700 (PDT) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 7DFFB4C8020; Fri, 3 Apr 2009 22:13:56 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 149C44C8152; Fri, 3 Apr 2009 22:13:54 +0200 (CEST) Message-ID: <49D66E09.6020702@gmail.com> Date: Fri, 03 Apr 2009 22:14:01 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Carsten Bormann References: <49D329A7.6080300@sensinode.com> <49D5CE1C.9080902@gmail.com> <2784F829-89FE-4666-BDA7-BD83F7F2CC56@tzi.org> In-Reply-To: <2784F829-89FE-4666-BDA7-BD83F7F2CC56@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] multihop information option metric 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: , X-List-Received-Date: Fri, 03 Apr 2009 20:13:05 -0000 Carsten Bormann a écrit : > On Apr 3, 2009, at 13:50, Peter Siklosi wrote: > >> In my mind, the simplest model would be to represent the cost as > > ND in 6lowpan is (mainly) about the host-router interface. I agree with the intention. I have hower purposefully pictured Router1 and 2 to have two different interfaces each - I can reason with them so. I'm afraid 6lowpan ND may not uses such devices, though. > Does the host even have to know about the way the router metric is > computed? No. > The host (if it wants to be just a host) should not need to know > about the routing protocol and its metrics. I agree. > I have therefore proposed the ND metric to simply be a 16-bit > integer, with a mid-range default (i.e., 0x8000 if the number is > unsigned). Routing protocols may want to define a way how to compute > that integer at a router so that multiple routers present numbers > that make sense when used together by a host. (And that may not > exclude use of the value found via ND in bootstrapping a router. > Still outside the scope of ND proper.) I agree with ND metric 16-bit, in this sense. Maybe 8bit would be sufficient too. ? > BTW, standard IPv6 ND does not have such a metric for the following > stated reason: > > Unlike in IPv4 Router Discovery, the Router Advertisement messages do > not contain a preference field. The preference field is not needed > to handle routers of different "stability"; the Neighbor > Unreachability Detection will detect dead routers and switch to a > working one. Well yes, but there's something about default routes - which we seem to consider here more than the specific routes. For default routes (address of the default router) there are fields "Router Lifetime". If each router decreased the lifetime it advertised further down the network then Host would make a decision to prefer the default router whose Router Lifetime is higher, and thus reach quicker the Internet via the least decreased Router Lifetime - a potential reuse without defining new Cost field. Yet again, all this provided I understand ok the IP subnet structure in 6lowpan ND. Alex From alexandru.petrescu@gmail.com Fri Apr 3 13:15:23 2009 Return-Path: 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 61CC63A69A8 for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 13:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qAfEV2NaTLx for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 13:15:22 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id 3963E3A69FE for <6lowpan@ietf.org>; Fri, 3 Apr 2009 13:15:20 -0700 (PDT) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id EF9654C80E8; Fri, 3 Apr 2009 22:16:19 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id E580E4C80C0; Fri, 3 Apr 2009 22:16:16 +0200 (CEST) Message-ID: <49D66E98.8020602@gmail.com> Date: Fri, 03 Apr 2009 22:16:24 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <49D329A7.6080300@sensinode.com> <49D5CE1C.9080902@gmail.com> <2784F829-89FE-4666-BDA7-BD83F7F2CC56@tzi.org> <49D616CD.7050906@sensinode.com> In-Reply-To: <49D616CD.7050906@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] multihop information option metric 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: , X-List-Received-Date: Fri, 03 Apr 2009 20:15:23 -0000 Zach Shelby a écrit : > Hi, > > Carsten Bormann wrote: >> On Apr 3, 2009, at 13:50, Peter Siklosi wrote: >> >>> In my mind, the simplest model would be to represent the cost as >> >> ND in 6lowpan is (mainly) about the host-router interface. >> Does the host even have to know about the way the router metric is >> computed? >> The host (if it wants to be just a host) should not need to know about >> the routing protocol and its metrics. >> >> I have therefore proposed the ND metric to simply be a 16-bit integer, >> with a mid-range default (i.e., 0x8000 if the number is unsigned). >> Routing protocols may want to define a way how to compute that integer >> at a router so that multiple routers present numbers that make sense >> when used together by a host. (And that may not exclude use of the >> value found via ND in bootstrapping a router. Still outside the scope >> of ND proper.) >> >> BTW, standard IPv6 ND does not have such a metric for the following >> stated reason: >> >> Unlike in IPv4 Router Discovery, the Router Advertisement messages >> do not contain a preference field. The preference field is not >> needed to handle routers of different "stability"; the Neighbor >> Unreachability Detection will detect dead routers and switch to a >> working one. >> >> [RFC 4861, p 16]. This thinking does not really seem to apply to >> 6lowpans very well. > > I support this proposal myself, and think it is a nice solution to the > concern Peter brought up. The Multihop Information Option in Well yes, I agree with you Zach, but provided that 'hop' in multi-hop is understood. I already said in my review of the document that I don't understand it. > draft-ietf-nd has plenty of reserved space for such a 16-bit option. > This is also compatible with e.g. the work going on in ROLL as this > information is meant for hosts that don't have knowledge of the routing > algorithm. If a ROLL algorithm would produce such a metric - the router > would simply copy that into this field for use by hosts. > > With regard to integrating this into -03 of the draft, we would need to > see some more consensus support on the list. Who else finds this useful? The discussion? Me too. The option as it stands now - I can' grasp it. Alex From alexandru.petrescu@gmail.com Fri Apr 3 13:24:27 2009 Return-Path: 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 385F23A6AD5 for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 13:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmCE33hdlkDW for <6lowpan@core3.amsl.com>; Fri, 3 Apr 2009 13:24:26 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 371633A69F1 for <6lowpan@ietf.org>; Fri, 3 Apr 2009 13:24:24 -0700 (PDT) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 2EE5E818195; Fri, 3 Apr 2009 22:25:22 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id 0C28F8180B2; Fri, 3 Apr 2009 22:25:20 +0200 (CEST) Message-ID: <49D670B7.1030505@gmail.com> Date: Fri, 03 Apr 2009 22:25:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <49D329A7.6080300@sensinode.com><49D5CE1C.9080902@gmail.com> <2784F829-89FE-4666-BDA7-BD83F7F2CC56@tzi.org> <49D616CD.7050906@sensinode.com> <7892795E1A87F04CADFCCF41FADD00FC073C40F4@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC073C40F4@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] multihop information option metric 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: , X-List-Received-Date: Fri, 03 Apr 2009 20:24:27 -0000 Pascal Thubert (pthubert) a écrit : > I agree with Carsten and Zach: > > The metric is opaque to the host because it is (derived from) a routing > metric and the host does not route. But when it comes to forwarding, > then the host would benefit from using it wisely. In more details: > > - We just make the router preference a bit wider in size than RFC 4191 rfc4191 "router prefs and more specific routes" has Preference size 2bits: why would 6lowpan need more? Has it somehow been agreed that the number of IP hops in a 6lowpan network is larger than 4? If we consider all nodes to be mesh-under and the entire 6lowpan link to be one subnet then there' only one hop, which is less than 4. > but the host is clueless about what that means; all it does is compare > opaque scalar to opaque scalar. It's probably up to ROLL to give it a > meaning and a value but that's out of scope for our spec. I agree with this intention. > - The metric might fluctuate but it's not crucial for the host default > router selection as long as the default router still enables > reachability to/from an edge router. In Other Words the host does not > have to switch default router (and reregister to the edge router) each > time that metric varies though it should lazily try to stick to the best > one to optimize the return path from the edge router. But in the pictured case only the default routes are discussed. I think I mean metric Cost -only for default routes. > - But a host might favor the best metric router as next hop on a per > packet basis if it likes. And if sending a packet to a router fails then > it might select the next best in the default router list per that > metric. In that, forwarding host to router is pretty similar to > forwarding router to router within the LoWPAN - if ROLL enables this > that is. Seems to need to go hand in hand with what ROLL may come up with, which is good. > Maybe we need a bit of text to be more specific on all this? Well the text I suggest is "it's not clear at this time what the subnet structure is and the solution to it is that the entire 6lowpan is a single subnet, only one hop". Alex From jvasseur@cisco.com Sun Apr 5 23:48:15 2009 Return-Path: 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 3E5453A67F8 for <6lowpan@core3.amsl.com>; Sun, 5 Apr 2009 23:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.335 X-Spam-Level: X-Spam-Status: No, score=-8.335 tagged_above=-999 required=5 tests=[AWL=-1.736, 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 cq63Noz7w7ws for <6lowpan@core3.amsl.com>; Sun, 5 Apr 2009 23:48:13 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id DF5A33A6A05 for <6lowpan@ietf.org>; Sun, 5 Apr 2009 23:48:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,329,1235952000"; d="scan'208";a="150540419" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2009 06:49:18 +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 n366nIQ2011432; Mon, 6 Apr 2009 08:49:18 +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 n366nHCQ023713; Mon, 6 Apr 2009 06:49:18 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 08:49:18 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 08:49:17 +0200 Message-Id: From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC073C40F4@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 6 Apr 2009 08:49:17 +0200 References: <49D329A7.6080300@sensinode.com><49D5CE1C.9080902@gmail.com> <2784F829-89FE-4666-BDA7-BD83F7F2CC56@tzi.org> <49D616CD.7050906@sensinode.com> <7892795E1A87F04CADFCCF41FADD00FC073C40F4@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Apr 2009 06:49:17.0571 (UTC) FILETIME=[CE597530:01C9B683] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6011; t=1239000558; x=1239864558; c=relaxed/simple; s=amsdkim2001; 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]=20multihop=20information=20op tion=20metric |Sender:=20; bh=QmWh+gpnjQYA5Grf806w9W+imgY0qHRLcW7iu22NekA=; b=K0vLIY0MWxw46wibVD7nnnQWuxHrDyJyqxwr3/PBseT7SB2X81vzs/pjSc H6SGwTyGVgkRiS91LViC4eLn61UU78aDdyjDeE3s+nYQxJGFhUaRVykmtZRk LG7PskYgFo; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] multihop information option metric 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: , X-List-Received-Date: Mon, 06 Apr 2009 06:48:15 -0000 Hi, On Apr 3, 2009, at 4:39 PM, Pascal Thubert (pthubert) wrote: > I agree with Carsten and Zach: > > The metric is opaque to the host because it is (derived from) a > routing > metric and the host does not route. But when it comes to forwarding, > then the host would benefit from using it wisely. In more details: > > - We just make the router preference a bit wider in size than RFC 4191 > but the host is clueless about what that means; all it does is compare > opaque scalar to opaque scalar. It's probably up to ROLL to give it a > meaning and a value but that's out of scope for our spec. > Strongly agreeing. If the host really want to understand the meaning of that metric, it should become part of the routing domain, which is not what we want to achieve here. Provide an opaque metric computed by the routing protocol is a good option. > - The metric might fluctuate but it's not crucial for the host default > router selection as long as the default router still enables > reachability to/from an edge router. In Other Words the host does not > have to switch default router (and reregister to the edge router) each > time that metric varies though it should lazily try to stick to the > best > one to optimize the return path from the edge router. Well, it is an implementation issue but I would prefer not provide fluctuating metric to hosts rather than relying on the host to do the right thing upon receiving metrics that change too quickly. You may still want to add a recommendation (RECOMMENDED) in the I-D with regards to the host behavior in such scenario. > > - But a host might favor the best metric router as next hop on a per > packet basis if it likes. And if sending a packet to a router fails > then > it might select the next best in the default router list per that > metric. In that, forwarding host to router is pretty similar to > forwarding router to router within the LoWPAN - if ROLL enables this > that is. Not sure that I would recommend router selection on a per packet basis ... Such behavior may work in some cases where you have ECMPs with paths having similar characteristics (in term of delays, ...) but clearly there are many situations where this is highly undesirable. I would personally recommend NOT to the this in the I-D. It is a recommendation, up to the implementers to follow it. > > Maybe we need a bit of text to be more specific on all this? Thanks, JP. > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Zach Shelby >> Sent: vendredi 3 avril 2009 16:02 >> To: Carsten Bormann >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] multihop information option metric >> >> Hi, >> >> Carsten Bormann wrote: >>> On Apr 3, 2009, at 13:50, Peter Siklosi wrote: >>> >>>> In my mind, the simplest model would be to represent the cost as >>> >>> ND in 6lowpan is (mainly) about the host-router interface. >>> Does the host even have to know about the way the router metric is >>> computed? >>> The host (if it wants to be just a host) should not need to know > about >>> the routing protocol and its metrics. >>> >>> I have therefore proposed the ND metric to simply be a 16-bit > integer, >>> with a mid-range default (i.e., 0x8000 if the number is unsigned). >>> Routing protocols may want to define a way how to compute that > integer >>> at a router so that multiple routers present numbers that make sense >>> when used together by a host. (And that may not exclude use of the > value >>> found via ND in bootstrapping a router. Still outside the scope of > ND >>> proper.) >>> >>> BTW, standard IPv6 ND does not have such a metric for the following >>> stated reason: >>> >>> Unlike in IPv4 Router Discovery, the Router Advertisement > messages >>> do not contain a preference field. The preference field is not >>> needed to handle routers of different "stability"; the Neighbor >>> Unreachability Detection will detect dead routers and switch to > a >>> working one. >>> >>> [RFC 4861, p 16]. This thinking does not really seem to apply to >>> 6lowpans very well. >> >> I support this proposal myself, and think it is a nice solution to >> the >> concern Peter brought up. The Multihop Information Option in >> draft-ietf-nd has plenty of reserved space for such a 16-bit option. >> This is also compatible with e.g. the work going on in ROLL as this >> information is meant for hosts that don't have knowledge of the >> routing >> algorithm. If a ROLL algorithm would produce such a metric - the >> router >> would simply copy that into this field for use by hosts. >> >> With regard to integrating this into -03 of the draft, we would >> need to >> see some more consensus support on the list. Who else finds this > useful? >> >> - Zach >> >>> Gruesse, Carsten >>> >>> (No WG chair hats included in this message.) >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> >> -- >> http://zachshelby.org - My blog "On the Internet of Things" >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> 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 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From jvasseur@cisco.com Sun Apr 5 23:50:08 2009 Return-Path: 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 B75373A6B7D for <6lowpan@core3.amsl.com>; Sun, 5 Apr 2009 23:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.279 X-Spam-Level: X-Spam-Status: No, score=-10.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz7cLq-3ag5O for <6lowpan@core3.amsl.com>; Sun, 5 Apr 2009 23:50:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EB3FC3A6A05 for <6lowpan@ietf.org>; Sun, 5 Apr 2009 23:49:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,329,1235952000"; d="scan'208";a="37523591" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Apr 2009 06:51:02 +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 n366p2oT032636; Mon, 6 Apr 2009 08:51:02 +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 n366p2MT024270; Mon, 6 Apr 2009 06:51:02 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 08:51:02 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 08:51:02 +0200 Message-Id: From: JP Vasseur To: Bruno Marques In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 6 Apr 2009 08:49:34 +0200 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Apr 2009 06:51:02.0086 (UTC) FILETIME=[0CA52E60:01C9B684] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=892; t=1239000662; x=1239864662; c=relaxed/simple; s=amsdkim1002; 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]=206LoWPAN=20+=20LOAD=20NS-2=2 0Implementation |Sender:=20; bh=h5qcv2YloYAkIVWBLkq811qYoMD9cOx0Z9HOW33WNDo=; b=uFW/gX7RUbE/NgYVXhGpSG+RSRPGmD5gEK3VmXhGyN64isCjPxp5RLFEah ynMllYBE+qJ0eLDBTazyUnK0LuqdFgwg0FBIQ8sysoCbCIFOqEOeiC8UQrys 9haj8T3n8p; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6LoWPAN + LOAD NS-2 Implementation 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: , X-List-Received-Date: Mon, 06 Apr 2009 06:50:08 -0000 Hi, On Apr 3, 2009, at 4:03 PM, Bruno Marques wrote: > Hello > > I'm a portuguese PhD Student at the Engineering Faculty of the > University of Porto (FEUP). > > I'm researching on low power routing protocols and p2p systems. > => You may want to register to roll@ietf.org. > In that context, somebody could distribute me the source code of > 6LoWPAN Adaptation layer and LOAD routing protocol implementation in > NS-2 ? > > Thanking you in advance, > best wishes, > ------------------------------------------------------------------ > Bruno Filipe Marques, > MsC in Electrical and Computer Engineering > > FCT PhD Schollarship (SFRH/BD/36221/2007) > PhD Student @ DEEC/FEUP > WiMobNet, UTM, INESC Porto, > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From zach@sensinode.com Mon Apr 6 00:28:40 2009 Return-Path: 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 28E0D3A68F3 for <6lowpan@core3.amsl.com>; Mon, 6 Apr 2009 00:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvAiTcnhiYJr for <6lowpan@core3.amsl.com>; Mon, 6 Apr 2009 00:28:39 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A0C713A69F2 for <6lowpan@ietf.org>; Mon, 6 Apr 2009 00:28:38 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n367Tdov016417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2009 10:29:40 +0300 Message-ID: <49D9AF4B.8030300@sensinode.com> Date: Mon, 06 Apr 2009 10:29:15 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <49D329A7.6080300@sensinode.com><49D5CE1C.9080902@gmail.com> <2784F829-89FE-4666-BDA7-BD83F7F2CC56@tzi.org> <49D616CD.7050906@sensinode.com> <7892795E1A87F04CADFCCF41FADD00FC073C40F4@xmb-ams-337.emea.cisco.com> <49D670B7.1030505@gmail.com> In-Reply-To: <49D670B7.1030505@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] multihop information option metric 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: , X-List-Received-Date: Mon, 06 Apr 2009 07:28:40 -0000 Hi Alex, Alexandru Petrescu wrote: > Pascal Thubert (pthubert) a écrit : >> I agree with Carsten and Zach: >> >> The metric is opaque to the host because it is (derived from) a routing >> metric and the host does not route. But when it comes to forwarding, >> then the host would benefit from using it wisely. In more details: >> >> - We just make the router preference a bit wider in size than RFC 4191 > > rfc4191 "router prefs and more specific routes" has Preference size > 2bits: why would 6lowpan need more? > > Has it somehow been agreed that the number of IP hops in a 6lowpan > network is larger than 4? If we consider all nodes to be mesh-under and > the entire 6lowpan link to be one subnet then there' only one hop, > which is less than 4. We are already using the preference bits to give preference to an Edge Router rather than a Router. This discussion only pertains to IP routing cases (not mesh-under!). Therefore the LoWPAN is not a single hop, there are IP hops in there. Thus the host may be multiple IP hops away from an ER - which is the whole reason we have Router opertaions defined in this draft, why we are relaying RR/RC messages, and why we are discussing this metric. >> but the host is clueless about what that means; all it does is compare >> opaque scalar to opaque scalar. It's probably up to ROLL to give it a >> meaning and a value but that's out of scope for our spec. > > I agree with this intention. > >> - The metric might fluctuate but it's not crucial for the host default >> router selection as long as the default router still enables >> reachability to/from an edge router. In Other Words the host does not >> have to switch default router (and reregister to the edge router) each >> time that metric varies though it should lazily try to stick to the best >> one to optimize the return path from the edge router. > > But in the pictured case only the default routes are discussed. I think > I mean metric Cost -only for default routes. Basic an a comparison of this metric, the host is able to choose the default route. >> - But a host might favor the best metric router as next hop on a per >> packet basis if it likes. And if sending a packet to a router fails then >> it might select the next best in the default router list per that >> metric. In that, forwarding host to router is pretty similar to >> forwarding router to router within the LoWPAN - if ROLL enables this >> that is. > > Seems to need to go hand in hand with what ROLL may come up with, which > is good. > >> Maybe we need a bit of text to be more specific on all this? > > Well the text I suggest is "it's not clear at this time what the subnet > structure is and the solution to it is that the entire 6lowpan is a > single subnet, only one hop". This is not correct. A LoWPAN may be a single hop if using some kind of mesh-under technology. In that case you have no LoWPAN routers, no multihop, no relaying, and you don't necessarily need this metric. As I pointed out before - this draft supports IP routing where there are multiple IP hops within the LoWPAN. This is the case being discussed here. - Zach > Alex > > -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From jhui@archrock.com Tue Apr 7 12:05:29 2009 Return-Path: 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 EFB113A6D97 for <6lowpan@core3.amsl.com>; Tue, 7 Apr 2009 12:05:28 -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 nR0apgQzmyHv for <6lowpan@core3.amsl.com>; Tue, 7 Apr 2009 12:05: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 199D23A6DAB for <6lowpan@ietf.org>; Tue, 7 Apr 2009 12:05:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id BB964AF8D5 for <6lowpan@ietf.org>; Tue, 7 Apr 2009 12:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOxuWIz6XKLK for <6lowpan@ietf.org>; Tue, 7 Apr 2009 12:06:30 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-74-235.dsl.pltn13.pacbell.net [71.142.74.235]) by mail.sf.archrock.com (Postfix) with ESMTP id D62C6AF881 for <6lowpan@ietf.org>; Tue, 7 Apr 2009 12:06:29 -0700 (PDT) Message-Id: From: Jonathan Hui To: 6lowpan@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 12:06:28 -0700 X-Mailer: Apple Mail (2.930.3) Subject: [6lowpan] HC - IPv6 Extension Headers 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: , X-List-Received-Date: Tue, 07 Apr 2009 19:05:29 -0000 Hi Everyone, During the WG meeting, we discussed the need to add support for IPv6 extension headers. There are two points to supporting IPv6 extension headers: 1) Allowing upper-layer header compression (e.g. UDP) in the presence of IPv6 extension headers. 2) Allowing more compact forms of IPv6 extension headers. From the WG meeting, there seemed to be consensus that case 1 is important to support. In particular, there are good use cases for IPv6 extension headers in 6lowpan networks. The proposal to support case 1 that was discussed in the meeting is as follows: The LOWPAN_NHC encoding for an IPv6 extension header involves a 7-bit NHC identifier followed by a 1-bit NH field that indicates whether the Next Header field is carried inline or the following header is compressed using LOWPAN_NHC. The encoding follows the following format: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 1 | 1 | 0 | 0 | Type |NH | +---+---+---+---+---+---+---+---+ Type: - 0: Hop-by-Hop Options Header - 1: Routing Header - 2: Fragment Header - 3: Destination Options Header NH: Next Header - 0: Full 8 bits for Next Header are carried in-line. - 1: The Next Header field is compressed and the next header is compressed using LOWPAN_NHC When LOWPAN_NHC is used for all IPv6 extension headers and the upper- layer header, the end result is that the 8-bit Next Header field is replaced by 8-bit LOWPAN_NHC encoding above. No other changes to the IPv6 extension headers are required. The above is probably a good base level of support for IPv6 extension headers. But now to address the second point: allowing more compact forms of IPv6 extension headers. The main concern here is on the 8- octet granularity of the Hdr Ext Len field in the Hop-by-Hop and Destination Options headers, wasting up to 7 bytes of padding. There are two ways we can overcome this: 1) Change the meaning of the Hdr Ext Len field to 1-octet granularity when LOWPAN_NHC is in use. If Hdr Ext Len truly exceeds 255, then LOWPAN_NHC cannot be used - a rare case, I think, but still needs to be addressed. 2) Remove the Hdr Ext Len field all together, save another byte, and rely on the length field of each option to reach the next header. The downside is that one cannot simply jump to the next header without going through each option. In practice, I don't see 6LoWPAN networks including a large number of options. In both cases, Pad1 and PadN options cannot be elided unless they appear at the end of the options list. This is to make sure that any alignment requirements for the options are satisfied when expanding the datagram. Note that changing the meaning of the Length field (Case 1) can also be applied to the Routing Header. Finally, I don't think there is much we can do with the Fragment Header. So some questions to guide the discussion: - What do people think of the basic support for IPv6 extension headers? - What do people think about changing the length field to 1-octet granularity? - What do people think about removing the length field from the hop-by- hop/destination options headers? We are down to two open issues before we can LC the HC document (the other being compression of multicast addresses). I'd like to resolve these issues hopefully within the next week so that we can move quickly towards LC. So send your thoughts! Thanks. -- Jonathan Hui From jhui@archrock.com Tue Apr 7 12:05:31 2009 Return-Path: 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 E60AB3A6DBD for <6lowpan@core3.amsl.com>; Tue, 7 Apr 2009 12:05: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 ZHs+sFYulfa6 for <6lowpan@core3.amsl.com>; Tue, 7 Apr 2009 12:05: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 08F603A6DBB for <6lowpan@ietf.org>; Tue, 7 Apr 2009 12:05:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 03CB3AF8D5 for <6lowpan@ietf.org>; Tue, 7 Apr 2009 12:06: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 b2+ivO+JLLt9 for <6lowpan@ietf.org>; Tue, 7 Apr 2009 12:06:33 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-74-235.dsl.pltn13.pacbell.net [71.142.74.235]) by mail.sf.archrock.com (Postfix) with ESMTP id 22310AF8B6 for <6lowpan@ietf.org>; Tue, 7 Apr 2009 12:06:33 -0700 (PDT) Message-Id: From: Jonathan Hui To: 6lowpan@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 12:06:33 -0700 X-Mailer: Apple Mail (2.930.3) Subject: [6lowpan] HC - Multicast Addresses 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: , X-List-Received-Date: Tue, 07 Apr 2009 19:05:32 -0000 Hi Everyone, During the WG meeting, one concern that was brought up is that support for multicast destination addresses may be too complex. Currently, the format supports the following forms: 1) FF02::00XX 2) FF0X::0XXX 3) FFXX::XX:XXXX 4) FFXX::00XX:XXXX:XXXX 5) FFXX:RIID:[plen][prefix]:XXXX:XXXX - Case 1 supports the most common link-local cases (e.g. link-local all-nodes/all-routers). - Case 2 supports variable scoped multicast addresses. - Case 3 supports longer well-known addresses (e.g. all-dhcp-servers). - Case 4 supports solicited node and node information queries commonly used in IPv6 ND. - Case 5 supports Unicast-Prefix-based Multicast addresses. I think everyone agrees that compressing multicast destination addresses is necessary, but we should discuss what level of support is required. Several months ago, some people (Julien in particular) discussed the usefulness of each of the above cases. Here are some of my comments: - Support for cases 1, 3, and 4 are probably a good idea to support. We could combine cases with higher compression into the ones with lower compression, reducing implementation cost but trades wire-line efficiency for those cases. - Extra support only adds required complexity to the decompressor. The compressor can always choose not to support certain cases and, in the base case, can choose not to compress anything at all. - As one data point, my current decompressor implementation requires 38 lines of code (with memcpy being the only function call) to support all 5 cases for multicast destination addresses. It could probably be optimized for smaller code. - It is very hard to add support in later revisions. There is no version number in the protocol format. Even if there was, nodes would have to negotiate and maintain state for which version is being used by its neighbors. In the end, my vote is to keep all of the multicast cases defined in the HC doc, but would like to here what others think. We are down to two open issues before we can LC the HC document (the other being LOWPAN_NHC support for IPv6 extension headers). I'd like to resolve these issues hopefully within the next week so that we can move quickly towards LC. So send your thoughts! Thanks. -- Jonathan Hui From zach@sensinode.com Tue Apr 7 13:37:48 2009 Return-Path: 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 4206A3A6E03 for <6lowpan@core3.amsl.com>; Tue, 7 Apr 2009 13:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYYDMNUOldC7 for <6lowpan@core3.amsl.com>; Tue, 7 Apr 2009 13:37:47 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id AEE9D3A69F1 for <6lowpan@ietf.org>; Tue, 7 Apr 2009 13:37:46 -0700 (PDT) Received: from snl-zach.local (line-18570.dyn.kponet.fi [85.29.118.250]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n37KchfN003989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 23:38:44 +0300 Message-ID: <49DBB9D8.8040104@sensinode.com> Date: Tue, 07 Apr 2009 23:38:48 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jonathan Hui References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] HC - IPv6 Extension Headers 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: , X-List-Received-Date: Tue, 07 Apr 2009 20:37:48 -0000 Hi, Regarding the base support, I strongly think we need this as it is broken as is if you try to use header options with UDP NHC. Regarding option 1 (1-octet granularity), I would find this very useful for piggybacking small hop-by-hop options and in general options followed by a payload as frames are extremely limited already. Regarding option 2 (eliding Hdr Ext Len), this is nice and helps compress options even more. Agreed that there are typically very few options. I support this as well. - Zach Jonathan Hui wrote: > > Hi Everyone, > > During the WG meeting, we discussed the need to add support for IPv6 > extension headers. There are two points to supporting IPv6 extension > headers: > 1) Allowing upper-layer header compression (e.g. UDP) in the presence of > IPv6 extension headers. > 2) Allowing more compact forms of IPv6 extension headers. > > From the WG meeting, there seemed to be consensus that case 1 is > important to support. In particular, there are good use cases for IPv6 > extension headers in 6lowpan networks. The proposal to support case 1 > that was discussed in the meeting is as follows: > > The LOWPAN_NHC encoding for an IPv6 extension header involves a 7-bit > NHC identifier followed by a 1-bit NH field that indicates whether the > Next Header field is carried inline or the following header is > compressed using LOWPAN_NHC. The encoding follows the following format: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 | 1 | 1 | 0 | 0 | Type |NH | > +---+---+---+---+---+---+---+---+ > > Type: > - 0: Hop-by-Hop Options Header > - 1: Routing Header > - 2: Fragment Header > - 3: Destination Options Header > > NH: Next Header > - 0: Full 8 bits for Next Header are carried in-line. > - 1: The Next Header field is compressed and the next header is > compressed using LOWPAN_NHC > > When LOWPAN_NHC is used for all IPv6 extension headers and the > upper-layer header, the end result is that the 8-bit Next Header field > is replaced by 8-bit LOWPAN_NHC encoding above. No other changes to the > IPv6 extension headers are required. > > The above is probably a good base level of support for IPv6 extension > headers. But now to address the second point: allowing more compact > forms of IPv6 extension headers. The main concern here is on the 8-octet > granularity of the Hdr Ext Len field in the Hop-by-Hop and Destination > Options headers, wasting up to 7 bytes of padding. There are two ways we > can overcome this: > 1) Change the meaning of the Hdr Ext Len field to 1-octet granularity > when LOWPAN_NHC is in use. If Hdr Ext Len truly exceeds 255, then > LOWPAN_NHC cannot be used - a rare case, I think, but still needs to be > addressed. > 2) Remove the Hdr Ext Len field all together, save another byte, and > rely on the length field of each option to reach the next header. The > downside is that one cannot simply jump to the next header without going > through each option. In practice, I don't see 6LoWPAN networks including > a large number of options. > > In both cases, Pad1 and PadN options cannot be elided unless they appear > at the end of the options list. This is to make sure that any alignment > requirements for the options are satisfied when expanding the datagram. > > Note that changing the meaning of the Length field (Case 1) can also be > applied to the Routing Header. Finally, I don't think there is much we > can do with the Fragment Header. > > So some questions to guide the discussion: > - What do people think of the basic support for IPv6 extension headers? > - What do people think about changing the length field to 1-octet > granularity? > - What do people think about removing the length field from the > hop-by-hop/destination options headers? > > We are down to two open issues before we can LC the HC document (the > other being compression of multicast addresses). I'd like to resolve > these issues hopefully within the next week so that we can move quickly > towards LC. So send your thoughts! > > Thanks. > > -- > Jonathan Hui > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From zach@sensinode.com Wed Apr 8 05:22:06 2009 Return-Path: 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 06A833A6936 for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 05:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPVZLWCSsPDr for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 05:22:04 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 5A6263A67F1 for <6lowpan@ietf.org>; Wed, 8 Apr 2009 05:22:03 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n38CN3Xf019606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2009 15:23:03 +0300 Message-ID: <49DC972F.6000409@sensinode.com> Date: Wed, 08 Apr 2009 15:23:11 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jonathan Hui References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] HC - Multicast Addresses 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: , X-List-Received-Date: Wed, 08 Apr 2009 12:22:06 -0000 Hi, After talking back and forth with Julien, Pascal and Jonathan I have to agree that there really isn't much better that we can do here without splitting hairs. So I suggest that we just keep it as in the current draft wrt multicast compression. Thanks to Jonathan anyways for exploring the possibilities. So that one concern is now withdrawn ;-) - Zach Jonathan Hui wrote: > > Hi Everyone, > > During the WG meeting, one concern that was brought up is that support > for multicast destination addresses may be too complex. > > Currently, the format supports the following forms: > 1) FF02::00XX > 2) FF0X::0XXX > 3) FFXX::XX:XXXX > 4) FFXX::00XX:XXXX:XXXX > 5) FFXX:RIID:[plen][prefix]:XXXX:XXXX > > - Case 1 supports the most common link-local cases (e.g. link-local > all-nodes/all-routers). > - Case 2 supports variable scoped multicast addresses. > - Case 3 supports longer well-known addresses (e.g. all-dhcp-servers). > - Case 4 supports solicited node and node information queries commonly > used in IPv6 ND. > - Case 5 supports Unicast-Prefix-based Multicast addresses. > > I think everyone agrees that compressing multicast destination addresses > is necessary, but we should discuss what level of support is required. > Several months ago, some people (Julien in particular) discussed the > usefulness of each of the above cases. > > Here are some of my comments: > > - Support for cases 1, 3, and 4 are probably a good idea to support. We > could combine cases with higher compression into the ones with lower > compression, reducing implementation cost but trades wire-line > efficiency for those cases. > - Extra support only adds required complexity to the decompressor. The > compressor can always choose not to support certain cases and, in the > base case, can choose not to compress anything at all. > - As one data point, my current decompressor implementation requires 38 > lines of code (with memcpy being the only function call) to support all > 5 cases for multicast destination addresses. It could probably be > optimized for smaller code. > - It is very hard to add support in later revisions. There is no version > number in the protocol format. Even if there was, nodes would have to > negotiate and maintain state for which version is being used by its > neighbors. > > In the end, my vote is to keep all of the multicast cases defined in the > HC doc, but would like to here what others think. > > We are down to two open issues before we can LC the HC document (the > other being LOWPAN_NHC support for IPv6 extension headers). I'd like to > resolve these issues hopefully within the next week so that we can move > quickly towards LC. So send your thoughts! > > Thanks. > > -- > Jonathan Hui > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From pthubert@cisco.com Wed Apr 8 06:07:51 2009 Return-Path: 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 5A2B33A6E4A for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 06:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.829 X-Spam-Level: X-Spam-Status: No, score=-7.829 tagged_above=-999 required=5 tests=[AWL=-1.230, 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 QKQgPIbExb0M for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 06:07:50 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 435763A6813 for <6lowpan@ietf.org>; Wed, 8 Apr 2009 06:07:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,344,1235952000"; d="scan'208";a="282451158" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-6.cisco.com with ESMTP; 08 Apr 2009 13:08:56 +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 n38D8upd024221; Wed, 8 Apr 2009 15:08:56 +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 n38D8uve018140; Wed, 8 Apr 2009 13:08:56 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 15:08:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2009 15:08:18 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC074273FD@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] HC - IPv6 Extension Headers Thread-Index: Acm3s/wffHO+NkKSQ5yVl0pSBL8YgQAjfrbw References: From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , <6lowpan@ietf.org> X-OriginalArrivalTime: 08 Apr 2009 13:08:56.0338 (UTC) FILETIME=[2C60F720:01C9B84B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4627; t=1239196136; x=1240060136; 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]=20HC=20-=20IPv6=20Extension=2 0Headers |Sender:=20; bh=Hja5yA/GZUf+4fIFtHr6Gd9RnG7KGo1VJuEb+AP1lP0=; b=oX8Ly96/msdQgppr9wqgqTpwTlA/Ik5k1wY7OLHUUt+wnNDf0qqGEn7310 f+TCQhxm7qAzSjnLkR2XTcs0PcSopqLuUjOjPg7Mk3y8Vq7iuOLTYkmOSTw+ J6z62mU78g; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [6lowpan] HC - IPv6 Extension Headers 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: , X-List-Received-Date: Wed, 08 Apr 2009 13:07:51 -0000 Hi Jonathan: So a compressed packet will have a number of (LOWPAN_NHC + rest of option) in sequence. >- What do people think of the basic support for IPv6 extension headers? I love it. I think that ROLL might need compressing routing headers and we could very well be deprecating mesh header altogether. >- What do people think about changing the length field to 1-octet >granularity? Rather positive since it save stuff -trailer pads - and is easy to do, not sure it's important >- What do people think about removing the length field from the hop-by- >hop/destination options headers?=20 Rather negative for complexity reason, not sure it's important either. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: mardi 7 avril 2009 21:06 >To: 6lowpan@ietf.org >Subject: [6lowpan] HC - IPv6 Extension Headers=20 > > >Hi Everyone, > >During the WG meeting, we discussed the need to add support for IPv6 >extension headers. There are two points to supporting IPv6 extension >headers: >1) Allowing upper-layer header compression (e.g. UDP) in the presence >of IPv6 extension headers. >2) Allowing more compact forms of IPv6 extension headers. > > From the WG meeting, there seemed to be consensus that case 1 is >important to support. In particular, there are good use cases for IPv6 >extension headers in 6lowpan networks. The proposal to support case 1 >that was discussed in the meeting is as follows: > >The LOWPAN_NHC encoding for an IPv6 extension header involves a 7-bit >NHC identifier followed by a 1-bit NH field that indicates whether >the Next Header field is carried inline or the following header is >compressed using LOWPAN_NHC. The encoding follows the following format: > > 0 1 2 3 4 5 6 7 >+---+---+---+---+---+---+---+---+ >| 1 | 1 | 1 | 0 | 0 | Type |NH | >+---+---+---+---+---+---+---+---+ > >Type: > - 0: Hop-by-Hop Options Header > - 1: Routing Header > - 2: Fragment Header > - 3: Destination Options Header > >NH: Next Header > - 0: Full 8 bits for Next Header are carried in-line. > - 1: The Next Header field is compressed and the next header is >compressed using LOWPAN_NHC > >When LOWPAN_NHC is used for all IPv6 extension headers and the upper- >layer header, the end result is that the 8-bit Next Header field is >replaced by 8-bit LOWPAN_NHC encoding above. No other changes to the >IPv6 extension headers are required. > >The above is probably a good base level of support for IPv6 extension >headers. But now to address the second point: allowing more compact >forms of IPv6 extension headers. The main concern here is on the 8- >octet granularity of the Hdr Ext Len field in the Hop-by-Hop and >Destination Options headers, wasting up to 7 bytes of padding. There >are two ways we can overcome this: >1) Change the meaning of the Hdr Ext Len field to 1-octet granularity >when LOWPAN_NHC is in use. If Hdr Ext Len truly exceeds 255, then >LOWPAN_NHC cannot be used - a rare case, I think, but still needs to >be addressed. >2) Remove the Hdr Ext Len field all together, save another byte, and >rely on the length field of each option to reach the next header. The >downside is that one cannot simply jump to the next header without >going through each option. In practice, I don't see 6LoWPAN networks >including a large number of options. > >In both cases, Pad1 and PadN options cannot be elided unless they >appear at the end of the options list. This is to make sure that any >alignment requirements for the options are satisfied when expanding >the datagram. > >Note that changing the meaning of the Length field (Case 1) can also >be applied to the Routing Header. Finally, I don't think there is much >we can do with the Fragment Header. > >So some questions to guide the discussion: >- What do people think of the basic support for IPv6 extension headers? >- What do people think about changing the length field to 1-octet >granularity? >- What do people think about removing the length field from the hop-by- >hop/destination options headers? > >We are down to two open issues before we can LC the HC document (the >other being compression of multicast addresses). I'd like to resolve >these issues hopefully within the next week so that we can move >quickly towards LC. So send your thoughts! > >Thanks. > >-- >Jonathan Hui >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From alexandru.petrescu@gmail.com Wed Apr 8 07:12:55 2009 Return-Path: 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 BC9423A6953 for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 07:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmQ3cQRmR4Qw for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 07:12:55 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 975133A69B7 for <6lowpan@ietf.org>; Wed, 8 Apr 2009 07:12:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n38EDuVN012083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Apr 2009 16:13:57 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n38EGmiJ002885; Wed, 8 Apr 2009 16:16:49 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n38EDsd0015822; Wed, 8 Apr 2009 16:13:55 +0200 Message-ID: <49DCB122.7060101@gmail.com> Date: Wed, 08 Apr 2009 16:13:54 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jonathan Hui References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] HC - IPv6 Extension Headers 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: , X-List-Received-Date: Wed, 08 Apr 2009 14:12:55 -0000 Jonathan, I have some remarks to the questions you raise below. I may not have the full context, but I'm trying to get up to speed with 6lowpan. Jonathan Hui a écrit : > > Hi Everyone, > > During the WG meeting, we discussed the need to add support for IPv6 > extension headers. There are two points to supporting IPv6 extension > headers: > 1) Allowing upper-layer header compression (e.g. UDP) in the presence of > IPv6 extension headers. > 2) Allowing more compact forms of IPv6 extension headers. > > From the WG meeting, there seemed to be consensus that case 1 is > important to support. In particular, there are good use cases for IPv6 > extension headers in 6lowpan networks. The proposal to support case 1 > that was discussed in the meeting is as follows: > > The LOWPAN_NHC encoding for an IPv6 extension header involves a 7-bit > NHC identifier followed by a 1-bit NH field that indicates whether the > Next Header field is carried inline or the following header is > compressed using LOWPAN_NHC. The encoding follows the following format: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 | 1 | 1 | 0 | 0 | Type |NH | > +---+---+---+---+---+---+---+---+ > > Type: > - 0: Hop-by-Hop Options Header > - 1: Routing Header > - 2: Fragment Header > - 3: Destination Options Header AH, ESP and MH no? [...] > In practice, I don't see 6LoWPAN networks including a large number of > options. But is or isn't the 6LoWPAN network connected to the Internet: if yes then one particular node having a 6lowpan interface could connect to the Internet through the 6lowpan network, and use its existing IPv6 stack the way it uses it when connecting to Ethernet, for example. In this case, there are many options needed (Mobile IP, AH/ESP to name a few). [...] > So some questions to guide the discussion: > - What do people think of the basic support for IPv6 extension headers? A side comment to this question: I would have preferred that the most basic IPv6 support in 6lowpan works without header compression, and compression to come as an optimization. And in the context of this question as a full-fledged optimization covering all the currently specified extensions headers. This is just a side remark. > - What do people think about changing the length field to 1-octet > granularity? > - What do people think about removing the length field from the > hop-by-hop/destination options headers? Removing the header extension length field from the hbh/do1/2 extension headers would be too hard to achieve, no? All the software using these extensions headers will have to be modified? There are a number of WGs where these extensions have been used (together with the length field) and one would make sure interact with these WGs before deciding removing the respective field. Alex > > We are down to two open issues before we can LC the HC document (the > other being compression of multicast addresses). I'd like to resolve > these issues hopefully within the next week so that we can move quickly > towards LC. So send your thoughts! > > Thanks. > > -- > Jonathan Hui > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From pthubert@cisco.com Wed Apr 8 08:05:20 2009 Return-Path: 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 2E91F3A68C3 for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 08:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.764 X-Spam-Level: X-Spam-Status: No, score=-7.764 tagged_above=-999 required=5 tests=[AWL=-1.165, 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 riiWydd+i5pX for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 08:05:19 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 420BD3A6A10 for <6lowpan@ietf.org>; Wed, 8 Apr 2009 08:05:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,345,1235952000"; d="scan'208";a="282530596" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-6.cisco.com with ESMTP; 08 Apr 2009 15:06:25 +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 n38F6OYL005712; Wed, 8 Apr 2009 17:06:24 +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 n38F6ONb008224; Wed, 8 Apr 2009 15:06:24 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, 8 Apr 2009 17:06:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2009 17:06:17 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC074274CD@xmb-ams-337.emea.cisco.com> In-Reply-To: <49DCB122.7060101@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] HC - IPv6 Extension Headers Thread-Index: Acm4VIJ6S9u6uD8/Timkh3En1paC+QABm5Bw References: <49DCB122.7060101@gmail.com> From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Jonathan Hui" X-OriginalArrivalTime: 08 Apr 2009 15:06:24.0707 (UTC) FILETIME=[9588B930:01C9B85B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=762; t=1239203184; x=1240067184; 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]=20HC=20-=20IPv6=20Extension=2 0Headers |Sender:=20; bh=Y26T4XTxg64d72JyXtYDYkNhKGa1dex5hj63/QlczdU=; b=QlDeRTwRB83KvHR1tToFu8DPQ6msYjQgIYnX8Bhlz4wMw9op9iv/0XX7Kj K3kqaT0F6JAzt3Q5d9qwTSUPAJ+yt0nogAiQtj5X8XgXDsIIqxPwrPx335e6 8d+fd2P0RW; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] HC - IPv6 Extension Headers 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: , X-List-Received-Date: Wed, 08 Apr 2009 15:05:20 -0000 Hi: >> The LOWPAN_NHC encoding for an IPv6 extension header involves a 7-bit >> NHC identifier followed by a 1-bit NH field that indicates whether the >> Next Header field is carried inline or the following header is >> compressed using LOWPAN_NHC. The encoding follows the following format: >> >> 0 1 2 3 4 5 6 7 >> +---+---+---+---+---+---+---+---+ >> | 1 | 1 | 1 | 0 | 0 | Type |NH | >> +---+---+---+---+---+---+---+---+ >> >> Type: >> - 0: Hop-by-Hop Options Header >> - 1: Routing Header >> - 2: Fragment Header >> - 3: Destination Options Header > >AH, ESP and MH no? Bit 4 does not have to be forced to 0 so we could actually support these by making the type 3 bits. Jonathan, what do you think? Pascal From jhui@archrock.com Wed Apr 8 09:56:46 2009 Return-Path: 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 D17BA3A6B16 for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 09:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV-JrkJWSUZW for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 09:56:46 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 325B33A6A74 for <6lowpan@ietf.org>; Wed, 8 Apr 2009 09:56:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id B0379AF8B8; Wed, 8 Apr 2009 09:57:53 -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 Xwbyq20uT7C2; Wed, 8 Apr 2009 09:57:49 -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 E5CC9AF8AE; Wed, 8 Apr 2009 09:57:48 -0700 (PDT) Message-Id: <8BFA4F21-EDF0-4452-B5D1-60AC88A28A35@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC074274CD@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 09:57:48 -0700 References: <49DCB122.7060101@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC074274CD@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] HC - IPv6 Extension Headers 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: , X-List-Received-Date: Wed, 08 Apr 2009 16:56:46 -0000 On Apr 8, 2009, at 8:06 AM, Pascal Thubert (pthubert) wrote: >> AH, ESP and MH no? > > Bit 4 does not have to be forced to 0 so we could actually support > these > by making the type 3 bits. > Jonathan, what do you think? Sounds good to me. So maybe we should expand to the following: 0: Hop-by-Hop Options 1: Routing 2: Fragment 3: Destination Options 4: Encap Security Payload 5: Authentication Header 6: Mobility Header 7: Reserved What about changing the meaning of the Length field in the Authentication and Mobility headers? Authentication header is a bit different since it specifies 4-octet units. Do we have a good header for type 7? :-) What do others think? -- Jonathan Hui From richard.kelsey@ember.com Wed Apr 8 10:44:27 2009 Return-Path: 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 675303A6E89 for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 10:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob4Uj4d7HI33 for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 10:44:26 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 8FA0E3A6E8A for <6lowpan@ietf.org>; Wed, 8 Apr 2009 10:44:26 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Apr 2009 13:46:16 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n38HjXel030326; Wed, 8 Apr 2009 13:45:33 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n38HjWwi030323; Wed, 8 Apr 2009 13:45:32 -0400 Date: Wed, 8 Apr 2009 13:45:32 -0400 Message-Id: <200904081745.n38HjWwi030323@kelsey-ws.hq.ember.com> To: jhui@archrock.com In-reply-to: <8BFA4F21-EDF0-4452-B5D1-60AC88A28A35@archrock.com> (message from Jonathan Hui on Wed, 8 Apr 2009 09:57:48 -0700) From: Richard Kelsey References: <49DCB122.7060101@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC074274CD@xmb-ams-337.emea.cisco.com> <8BFA4F21-EDF0-4452-B5D1-60AC88A28A35@archrock.com> X-OriginalArrivalTime: 08 Apr 2009 17:46:17.0008 (UTC) FILETIME=[EAFDB300:01C9B871] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] HC - IPv6 Extension Headers 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: , X-List-Received-Date: Wed, 08 Apr 2009 17:44:27 -0000 From: Jonathan Hui Date: Wed, 8 Apr 2009 09:57:48 -0700 Sounds good to me. So maybe we should expand to the following: 0: Hop-by-Hop Options 1: Routing 2: Fragment 3: Destination Options 4: Encap Security Payload 5: Authentication Header 6: Mobility Header 7: Reserved I have lost the thread a bit here. How many bytes do we save by having an NHC identifier for a particular extension header type? It seems likely that the marginal advantage of adding each new NHC identifier is decreasing. Why pick these seven in particular? -Richard Kelsey From cabo@tzi.org Wed Apr 8 10:56:37 2009 Return-Path: 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 95B6C3A6917 for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 10:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 G1H7lzga6Ih0 for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 10:56:37 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 59E6928C2A1 for <6lowpan@ietf.org>; Wed, 8 Apr 2009 10:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id n38HuTkm025526; Wed, 8 Apr 2009 19:56:29 +0200 (CEST) Received: from [192.168.217.107] (p5489BACB.dip.t-dialin.net [84.137.186.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 65DC71704D7; Wed, 8 Apr 2009 19:56:29 +0200 (CEST) From: Carsten Bormann To: Richard Kelsey In-Reply-To: <200904081745.n38HjWwi030323@kelsey-ws.hq.ember.com> References: <49DCB122.7060101@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC074274CD@xmb-ams-337.emea.cisco.com> <8BFA4F21-EDF0-4452-B5D1-60AC88A28A35@archrock.com> <200904081745.n38HjWwi030323@kelsey-ws.hq.ember.com> Message-Id: <06BFFFDF-8F3D-43DC-90A5-D366F6FE9EF2@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 19:56:30 +0200 X-Mailer: Apple Mail (2.930.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] HC - IPv6 Extension Headers 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: , X-List-Received-Date: Wed, 08 Apr 2009 17:56:37 -0000 > I have lost the thread a bit here. I actually was lost a couple of messages earlier, already. Can someone give a worked example of how, e.g., the ESP case would look like? (All headers in the uncompressed and compressed case, not just the NHC byte.) It may be worthwhile to look into RFC 5225, which represents the latest thinking we had in ROHC about extension headers (of course, for a different use case). Gruesse, Carsten From jhui@archrock.com Wed Apr 8 10:56:41 2009 Return-Path: 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 129E73A6900 for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 10:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOE-obLQNalo for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 10:56:40 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id CA5EA3A6B19 for <6lowpan@ietf.org>; Wed, 8 Apr 2009 10:56:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 662BCAF8AE; Wed, 8 Apr 2009 10:57: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 N7WXl3zhutnC; Wed, 8 Apr 2009 10:57:33 -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 A5651AF897; Wed, 8 Apr 2009 10:57:33 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <200904081745.n38HjWwi030323@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 10:57:32 -0700 References: <49DCB122.7060101@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC074274CD@xmb-ams-337.emea.cisco.com> <8BFA4F21-EDF0-4452-B5D1-60AC88A28A35@archrock.com> <200904081745.n38HjWwi030323@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.930.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] HC - IPv6 Extension Headers 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: , X-List-Received-Date: Wed, 08 Apr 2009 17:56:41 -0000 Hi Richard, Defining NHCs for each extension header allows the use of LOWPAN_NHC when those extension headers are present, saving up to 6 bytes. Note that the current proposal for supporting extension headers only replaces the Next Header field with the NHC encoding - so no additional bytes are added in the worst case. If we change the meaning of the Length field from 8-octet units to 1- octet units, then we save up to 7 bytes per extension header. The 7 extension headers listed are the only IPv6 extension headers that I am aware of, though, in my last email, I did solicit the WG for other headers lurking out there in case I missed them. -- Jonathan Hui On Apr 8, 2009, at 10:45 AM, Richard Kelsey wrote: > From: Jonathan Hui > Date: Wed, 8 Apr 2009 09:57:48 -0700 > > Sounds good to me. So maybe we should expand to the following: > > 0: Hop-by-Hop Options > 1: Routing > 2: Fragment > 3: Destination Options > 4: Encap Security Payload > 5: Authentication Header > 6: Mobility Header > 7: Reserved > > I have lost the thread a bit here. How many bytes do we > save by having an NHC identifier for a particular extension > header type? It seems likely that the marginal advantage > of adding each new NHC identifier is decreasing. Why pick > these seven in particular? > -Richard Kelsey From jhui@archrock.com Wed Apr 8 11:37:37 2009 Return-Path: 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 12CAF28C1A9 for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 11:37:37 -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 BYcT9mTBXa1h for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 11:37:36 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id CA03D28C1DD for <6lowpan@ietf.org>; Wed, 8 Apr 2009 11:35:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 1A7CDAF8B5; Wed, 8 Apr 2009 11:36:56 -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 vBENETLvMip0; Wed, 8 Apr 2009 11:36:51 -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 3651BAF8AD; Wed, 8 Apr 2009 11:36:51 -0700 (PDT) Message-Id: From: Jonathan Hui To: Carsten Bormann In-Reply-To: <06BFFFDF-8F3D-43DC-90A5-D366F6FE9EF2@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 11:36:49 -0700 References: <49DCB122.7060101@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC074274CD@xmb-ams-337.emea.cisco.com> <8BFA4F21-EDF0-4452-B5D1-60AC88A28A35@archrock.com> <200904081745.n38HjWwi030323@kelsey-ws.hq.ember.com> <06BFFFDF-8F3D-43DC-90A5-D366F6FE9EF2@tzi.org> X-Mailer: Apple Mail (2.930.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] HC - IPv6 Extension Headers 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: , X-List-Received-Date: Wed, 08 Apr 2009 18:37:37 -0000 Hi Carsten, The basic idea is to provide a simple mechanism that allows 6lowpan to support chaining across IPv6 extension headers and not compression of those headers themselves. So simply replace the Next Header/Protocol ID field with what is effectively a 7-bit header identifier + 1-bit field to indicate whether or not the Next Header/Protocol ID field is elided. As a minor improvement, we are also considering changing the resolution of the Ext Hdr Len field in headers that contain one, most notably the options and routing headers, to remove unnecessary padding at the tail of a header. That's really it. You're right that the ESP header is a bit of an odd ball since the Next Header field appears at the end of the extension header, but I don't see a show stopper in supporting that. The examples you requested are below. Do you see any issues with the transformations? With the ESP header in particular? Hop-by-Hop/Destination Options: Original: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LOWPAN_NHC: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 0 0 0 1| Hdr Ext Len | Options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Routing Original: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LOWPAN_NHC: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 0 0 1 1| Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fragment Original: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | Fragment Offset |Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LOWPAN_NHC: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 0 1 0 1| Reserved | Fragment Offset |Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication Header Original: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LOWPAN_NHC: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 1 1| Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mobility Header Original: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LOWPAN_NHC: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 1 0 1| Header Len | MH Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Encapsulating Security Payload Original: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Data* (variable) | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LOWPAN_NHC: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 0 1| Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI cont. | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq cont. | Payload Data* (variable) | +-+-+-+-+-+-+-+-+ + | | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Pad Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- Jonathan Hui On Apr 8, 2009, at 10:56 AM, Carsten Bormann wrote: >> I have lost the thread a bit here. > > I actually was lost a couple of messages earlier, already. > > Can someone give a worked example of how, e.g., the ESP case would > look like? > (All headers in the uncompressed and compressed case, not just the > NHC byte.) > > It may be worthwhile to look into RFC 5225, which represents the > latest thinking we had in ROHC about extension headers (of course, > for a different use case). > > Gruesse, Carsten > From alexandru.petrescu@gmail.com Wed Apr 8 13:28:04 2009 Return-Path: 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 93DFF3A6B2A for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 13:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqB4MpIgBPMV for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 13:28:03 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 3831A3A63D3 for <6lowpan@ietf.org>; Wed, 8 Apr 2009 13:28:01 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 85E41E08084; Wed, 8 Apr 2009 22:29:03 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5EFEDE08056; Wed, 8 Apr 2009 22:29:01 +0200 (CEST) Message-ID: <49DD090B.9040800@gmail.com> Date: Wed, 08 Apr 2009 22:28:59 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jonathan Hui References: <49DCB122.7060101@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC074274CD@xmb-ams-337.emea.cisco.com> <8BFA4F21-EDF0-4452-B5D1-60AC88A28A35@archrock.com> In-Reply-To: <8BFA4F21-EDF0-4452-B5D1-60AC88A28A35@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] HC - IPv6 Extension Headers 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: , X-List-Received-Date: Wed, 08 Apr 2009 20:28:04 -0000 Jonathan Hui a écrit : > > On Apr 8, 2009, at 8:06 AM, Pascal Thubert (pthubert) wrote: >>> AH, ESP and MH no? >> >> Bit 4 does not have to be forced to 0 so we could actually support these >> by making the type 3 bits. >> Jonathan, what do you think? > > Sounds good to me. So maybe we should expand to the following: > > 0: Hop-by-Hop Options > 1: Routing > 2: Fragment > 3: Destination Options > 4: Encap Security Payload > 5: Authentication Header > 6: Mobility Header > 7: Reserved It covers extension headers defined in rfc2460 "IPv6 spec" and rfc3775 "Mobile IPv6". They're intertwinned at http://www.iana.org/assignments/protocol-numbers/ Method should consider that DO may appear twice, but same type. (DO1 and DO2, and no more). Also, if there's a jumbogram hop-by-hop extension header the total length of the packet comes from that hbh option (and not from the base header). In addition, there's ongoing work about a new generic extension header, GIEH: draft-krishnan-ipv6-exthdr-06 which may or may not fly. If it flies, IANA is going to assign a new type for it. And there may also be this CGA extension header draft-dong-savi-cga-header-00.txt. Or HIP extension headers draft-nikander-hip-hiccups-01. > What about changing the meaning of the Length field in the > Authentication and Mobility headers? I am not sure what you mean by changing the meaning? Do you mean to change the way 6lowpan Header Compression interprets these Length fields? Or the way e.g. rfc2460 "IPv6" should be modified? > Authentication header is a bit > different since it specifies 4-octet units. > > Do we have a good header for type 7? :-) I guess type 7 being there is a potentially good way to say we don't know now all the extension headers (but maybe later we will). It should probably be longer than 1bit. > What do others think? I am also interested in other opinions. Alex From alexandru.petrescu@gmail.com Wed Apr 8 13:29:56 2009 Return-Path: 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 8CD713A6859 for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 13:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgv7ymXdy9EJ for <6lowpan@core3.amsl.com>; Wed, 8 Apr 2009 13:29:55 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 82B7B3A63D3 for <6lowpan@ietf.org>; Wed, 8 Apr 2009 13:29:53 -0700 (PDT) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 49EDC8180D1; Wed, 8 Apr 2009 22:30:56 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id 3751E81805A; Wed, 8 Apr 2009 22:30:54 +0200 (CEST) Message-ID: <49DD097D.1090102@gmail.com> Date: Wed, 08 Apr 2009 22:30:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jonathan Hui References: <49DCB122.7060101@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC074274CD@xmb-ams-337.emea.cisco.com> <8BFA4F21-EDF0-4452-B5D1-60AC88A28A35@archrock.com> <200904081745.n38HjWwi030323@kelsey-ws.hq.ember.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] HC - IPv6 Extension Headers 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: , X-List-Received-Date: Wed, 08 Apr 2009 20:29:56 -0000 Jonathan Hui a écrit : > > Hi Richard, > > Defining NHCs for each extension header allows the use of LOWPAN_NHC > when those extension headers are present, saving up to 6 bytes. It could save more if more extension headers are present. For example often both ESP and AH are present. Alex Note > that the current proposal for supporting extension headers only replaces > the Next Header field with the NHC encoding - so no additional bytes are > added in the worst case. > > If we change the meaning of the Length field from 8-octet units to > 1-octet units, then we save up to 7 bytes per extension header. > > The 7 extension headers listed are the only IPv6 extension headers that > I am aware of, though, in my last email, I did solicit the WG for other > headers lurking out there in case I missed them. > > -- > Jonathan Hui > > On Apr 8, 2009, at 10:45 AM, Richard Kelsey wrote: > >> From: Jonathan Hui >> Date: Wed, 8 Apr 2009 09:57:48 -0700 >> >> Sounds good to me. So maybe we should expand to the following: >> >> 0: Hop-by-Hop Options >> 1: Routing >> 2: Fragment >> 3: Destination Options >> 4: Encap Security Payload >> 5: Authentication Header >> 6: Mobility Header >> 7: Reserved >> >> I have lost the thread a bit here. How many bytes do we >> save by having an NHC identifier for a particular extension >> header type? It seems likely that the marginal advantage >> of adding each new NHC identifier is decreasing. Why pick >> these seven in particular? >> -Richard Kelsey > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From alexandru.petrescu@gmail.com Fri Apr 10 11:28:02 2009 Return-Path: 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 643613A6B4A for <6lowpan@core3.amsl.com>; Fri, 10 Apr 2009 11:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDXgPmxUAEUV for <6lowpan@core3.amsl.com>; Fri, 10 Apr 2009 11:28:01 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id 7953D3A6A68 for <6lowpan@ietf.org>; Fri, 10 Apr 2009 11:27:59 -0700 (PDT) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 332CE4C8190 for <6lowpan@ietf.org>; Fri, 10 Apr 2009 20:29:05 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 3A7DA4C818D for <6lowpan@ietf.org>; Fri, 10 Apr 2009 20:29:03 +0200 (CEST) Message-ID: <49DF8FEE.8090503@gmail.com> Date: Fri, 10 Apr 2009 20:29:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] Single-interface routers... 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: , X-List-Received-Date: Fri, 10 Apr 2009 18:28:02 -0000 Dear 6LoWPANners, This is clarification discussion issued from recent exchanges on ROLL list, and in private with some co-authors - I thank for having taken the time. Often was mentioned that 6lowpan/roll router would have a single interface, that subnet and routing is different than my understanding, and exact match (non-longest-prefix) match and host-based routes are relevant to this new IP routing model. Let me picture what I understand by an IP router: if1 ------ if2 --------|Router|------- subnet1 ------ subnet2 Router forwards by inspecting dst field and longest-prefix matching it in the routing table. Moreover, a router decides to forward a packet to only one outgoing interface, among two, like this: _______ / ------/if0 ----|Router| ------\ \if1 ------ But when we talk the picture of 6lowpan/roll router, it seemingly does not need to make any such IP routing decision: ---------------- new "subnet" |if0 ---- / \ / \ / Sensor \ \ Router / \ / \----/ What would be the critical SensorRouter operation? It would look at which fields of an incoming packet? And it would match it how? Into a table of what? A table of MAC addresses? (dst of the received packet, exact match search). A table of IP addresses? (with a new exact match search). What is the IP routing model assumed by the single-interface router? The text in 6lowpan ND is not clear about this, because at several places it uses old terms with new assumed meanings (for example it says there's a single subnet, a single link-scope multicast scope, but at the same time comments say IP routing and subnet is not what used to be). Alex From alexandru.petrescu@gmail.com Fri Apr 10 11:38:51 2009 Return-Path: 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 02B863A6ED4 for <6lowpan@core3.amsl.com>; Fri, 10 Apr 2009 11:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnnD751rQQF7 for <6lowpan@core3.amsl.com>; Fri, 10 Apr 2009 11:38:50 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id DEFE83A6E16 for <6lowpan@ietf.org>; Fri, 10 Apr 2009 11:38:48 -0700 (PDT) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 13FB5940041; Fri, 10 Apr 2009 20:39:52 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 099F09400AC; Fri, 10 Apr 2009 20:39:49 +0200 (CEST) Message-ID: <49DF9275.50104@gmail.com> Date: Fri, 10 Apr 2009 20:39:49 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Carsten Bormann References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> In-Reply-To: <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan routing and subnets (was: 6lowpan-ND vs. ROLL) 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: , X-List-Received-Date: Fri, 10 Apr 2009 18:38:51 -0000 Switched to 6lowpan from ROLL... Carsten Bormann a écrit : [...] > (If you think that routing within a subnet is not something that > immediately comes to mind when hearing "route-over", I'm with you, > but again that is the current terminology.) TErminology may be so, but I haven't agreed with it, and I believe it could be subject to change when there's a couple of different queriers. >>> With the backhaul model, in a mesh under network the link and >>> subnet are equivalent as the link spans the entire LoWPAN. >> >> But do you mean when there's no backhaul model > > (I don't tend to think about the case where there is no Edge Router > -- is that what you mean?) I meant when there _is_ an ER and the entire "subnet" covers both the wireless lowpan nodes _and_ the wired ER interfaces. That's what the ND doc says, that there's a single "subnet" for both. In this case, ER and 6lowpan nodes doing "IP routing" within a single subnet is difficult to understand to me. >> the link and subnet are not equivalent? > > In a pure mesh-under world (which the cited text is talking about), > they are equivalent -- making them equivalent is exactly the job of a > full mesh-under protocol. In a route-over world (with or without > embedded mesh-under islands), they aren't. It's strange... >>> In this document, a LoWPAN subnet is defined to be a collection >>> of LoWPAN links interconnected by routers that have the same >>> subnet prefix. >> >> Let's exemplify collection with two members: >> >> How does a router connect two links, yet has a single interface, >> and has the same subnet prefix on both (on both "what")? > > ("Two links" sounds as if the extent of a "link" is independent from > one's point of view, which in a radio network it isn't. A 6lowpan > node typically has exactly one interface and thus one link.) MAC layers should offer a link abstraction to the IP stack. I could have two WiFi APs in a room, all radio hear each other, yet there are different IP links, allowing to build a typical IP subnet on each such link. > By making the on-link decision (i.e., L2-address the host via ND vs. > L2-address the next-hop router via the routing protocol) based on > the routing information instead of just using the prefix. A routing protocol based on L2 addresses... is it an IP routing protocol? >> Is that a dumb repeater? > > No. Forwarding of a packet received is based on L2 address matching > (possibly followed by reassembly) followed by a consultation of the > L3 FIB. I get the first part "forwarding based on MAC address exact match" but if forwarding is done so then why consulting the L3 FIB? >> Is that an application-layer (UDP) repeating all packets it >> receives? (no routing table entry, only one interface). > > No. The forwarding is at L3, e.g., no interpretation of IPv6 > fragment headers or destination options headers is involved in the > forwarding. But you said above the forwarding is based on L2 address matching, thus not at L3... I'm sure there's a logic in what you said, and I may have missed something by too much dissection. But it would be very helpful to make a picture about a single-interface router presented with a packet in input, name the examined field, name the type of search (exact match?) and name a typical entry in that table. Alex From zach@sensinode.com Sat Apr 11 01:26:06 2009 Return-Path: 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 5A6023A6A65 for <6lowpan@core3.amsl.com>; Sat, 11 Apr 2009 01:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhUhWtqoKNBJ for <6lowpan@core3.amsl.com>; Sat, 11 Apr 2009 01:26:04 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4D13B3A6A8D for <6lowpan@ietf.org>; Sat, 11 Apr 2009 01:25:53 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n3B8Qvi6001540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 11:26:58 +0300 Message-ID: <49E0546A.3030702@sensinode.com> Date: Sat, 11 Apr 2009 11:27:22 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <49DF8FEE.8090503@gmail.com> In-Reply-To: <49DF8FEE.8090503@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Single-interface routers... 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: , X-List-Received-Date: Sat, 11 Apr 2009 08:26:06 -0000 Alex, I do not agree that this is that new of an IP routing model. In wireless mesh networks it surely is not. For a decade MANET has been doing IP routing in a similar way, and those of us involved with embedded IP have been doing IP routing like this for just as long. We have several commercial and open-source 6LoWPAN implementations, and plenty of MANET implementations doing this. Other non-IP embedded wireless network solutions do L3 routing using the same paradigm - for example ZigBee uses a variation of AODV style routing. If it really that hard to understand, then we will just have to describe it better. Some suggestions below on how to do that. Alexandru Petrescu wrote: > Dear 6LoWPANners, > > This is clarification discussion issued from recent exchanges on ROLL > list, and in private with some co-authors - I thank for having taken the > time. > > Often was mentioned that 6lowpan/roll router would have a single > interface, that subnet and routing is different than my understanding, > and exact match (non-longest-prefix) match and host-based routes are > relevant to this new IP routing model. > > Let me picture what I understand by an IP router: > > if1 ------ if2 > --------|Router|------- > subnet1 ------ subnet2 > > Router forwards by inspecting dst field and longest-prefix > matching it in the routing table. > > Moreover, a router decides to forward a packet to only one outgoing > interface, among two, like this: > > _______ > / > ------/if0 > ----|Router| > ------\ > \if1 > ------ Yep, we only have this in edge routers connected to other IP networks. In that case if0 maye be an Ethernet interface, and if1 a 6lowpan wireless interface. The edge router does IP routing between these interfaces. > But when we talk the picture of 6lowpan/roll router, it seemingly does > not need to make any such IP routing decision: > > ---------------- new "subnet" > |if0 > ---- > / \ > / \ > / Sensor \ > \ Router / > \ / > \----/ This is correct, 6LoWPAN nodes have a single interface participating in a LoWPAN. If a node has multiple interfaces each operates independently. > What would be the critical SensorRouter operation? It would look at > which fields of an incoming packet? And it would match it how? Into a > table of what? It matches the IPv6 destination address, with an IP route table which logically contains Destination.Address, Next-hop.Address tuples. If there is no match the router uses a default next-hop route up to an ER (it may keep secondary next-hop defaults). If there is some reactive routing algorithm it may also trigger some kind of route request action (e.g. DYMO) which would then find a next-hop for that destination. A host uses a default next-hop router (the one it sends RR messages to). It may also use secondary default next-hop routers. > A table of MAC addresses? (dst of the received packet, exact match > search). No, the link-layer dst address would be that of the SensorRouter receiving the packet. Link-layer src/dst are only for that hop. > > A table of IP addresses? (with a new exact match search). Yes, it uses an IP route table doing an exact match search on the IPv6 dst. However, as there is a direct mapping between IID and the L2 address in 6LoWPAN it is actually the L2 address it is matching if the destination address is in the LoWPAN. This has no importance on the IP routing operation though. If the address is outside the LoWPAN a default route to an ER is used. > What is the IP routing model assumed by the single-interface router? > The text in 6lowpan ND is not clear about this, because at several > places it uses old terms with new assumed meanings (for example it says > there's a single subnet, a single link-scope multicast scope, but at the > same time comments say IP routing and subnet is not what used to be). We are going to stop using the "subnet" term as it does not describe what we have here. We tried to define LoWPAN Subnet, but subnet is too overloaded with restrictions and presumptions. In draft-ietf-6lowpan-nd-03 we are just calling it a LoWPAN, and a LoWPAN is defined by a shared prefix across the interfaces of nodes. We don't have subnets as the links are so unstable they can't support subnets as defined by IPv6. Based on your comments we do need to describe a few things better for newcomers: 1. That LoWPAN routers route on a single interface, and the model for routing with that single interface should be described in some more detail. draft-ietf-6lowpan-nd and architecture doc. Can use a figure like that above. 2. The LoWPAN model, sharing a prefix which you may do IP routing within. This is not an IPv6 subnet. draft-ietf-6lowpan-nd and architecture doc. 3. How does next-hop determination work with this model. We already describe this in draft-ietf-6lowpan-nd under Host (Node in -03) Operations. Can be improved, with more detailed description and an example. 4. How does an IP routing algorithm work in such a network? This is a job for ROLL, although an architecture doc for 6lowpan may give a simple example? Most MANET protocols work fine in such a network from practical experience. - Zach > Alex > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From zach@sensinode.com Sat Apr 11 05:06:32 2009 Return-Path: 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 322513A6B1A for <6lowpan@core3.amsl.com>; Sat, 11 Apr 2009 05:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvqTc7k59+sD for <6lowpan@core3.amsl.com>; Sat, 11 Apr 2009 05:06:31 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A58B03A68BC for <6lowpan@ietf.org>; Sat, 11 Apr 2009 05:06:29 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n3BC7YEu005456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Sat, 11 Apr 2009 15:07:34 +0300 Message-ID: <49E08820.8050502@sensinode.com> Date: Sat, 11 Apr 2009 15:08:00 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowpan] Wikipedia entry 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: , X-List-Received-Date: Sat, 11 Apr 2009 12:06:32 -0000 Would anybody have energy to update http://en.wikipedia.org/wiki/6LoWPAN ? It starts to be a bit out-of-date, and could mention latest HC and ND developments along with IP routing and ROLL. This is at least the first place many newcomers will look in addition to the WG for information. Anyways I can write something about ND when I get a chance. Would be cool to have some figures there too (protocol stack? header format?) - Zach -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From zach@sensinode.com Sat Apr 11 05:19:48 2009 Return-Path: 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 1FB133A6B1A for <6lowpan@core3.amsl.com>; Sat, 11 Apr 2009 05:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3SCGkiH0Ykg for <6lowpan@core3.amsl.com>; Sat, 11 Apr 2009 05:19:47 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C428E3A69E6 for <6lowpan@ietf.org>; Sat, 11 Apr 2009 05:19:46 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n3BCKpAg005927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 15:20:51 +0300 Message-ID: <49E08B3D.6030003@sensinode.com> Date: Sat, 11 Apr 2009 15:21:17 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <49DFB1DB.3040602@gmail.com> <49E04284.6000900@sensinode.com> <49E0880E.1030803@gmail.com> In-Reply-To: <49E0880E.1030803@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] [Roll] 6lowpan-ND vs. ROLL 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: , X-List-Received-Date: Sat, 11 Apr 2009 12:19:48 -0000 Thread moved to 6lowpan... diverging into ND ;-) Alexandru Petrescu wrote: > Zach Shelby a écrit : >> Hi, >> >> Alexandru Petrescu wrote: >>> Richard Kelsey a écrit : >>>> From: Carsten Bormann Date: Fri, 10 Apr 2009 >>>> 19:00:42 +0200 >>>> >>>> (I don't tend to think about the case where there is no Edge >>>> Router -- ...) >>>> >>>> I have a question on this, stemming from my lack of familiarity >>>> with the details of IP routing. >>>> >>>> Suppose I have a 6LowPAN/ROLL network being used for energy >>>> management in a home. The network includes the electric meter, >>>> which has a backhaul connection back to the utility. The utility, >>>> being very protective of its backhaul network, has a firewall in >>>> the meter to keep out everything except the utility's own >>>> traffic. Given the presence of the firewall, does it still make >>>> sense to use the meter as an Edge Router? >>> >>> I don't think it would make much sense because Edge Router as >>> currently specified by 6LoWPAN ND seems to not be doing any routing >>> at all - but a sort of bridging, and firewalls are very much rules >>> on the IP fields, and less if at all rules on the MAC fields. >> >> That is not true. In 6LoWPAN the edge router is an IP router just >> like any other, and is a natural place to use a firewall. > > Yes, but, pictorially speaking: > > |egress(backbone) \ > ------ | > | ER | | > ------ > single IPv6 subnet > |ingress | > o o | > o o (lowpan nodes) / > > ND doc: >> This document also specifies the seamless integration of an extended >> LoWPAN and multiple edge routers on a shared backbone link (e.g. >> Ethernet) to form a single IPv6 subnet. > > The ND document says that ER egress interface and the LoWPAN nodes form > a single subnet - that is not a typical router. A typical router is > connected to two or more different subnets. Actually, that is only a special case that occurs with an Extended LoWPAN with multiple ERs interconnected by a common backbone link. In the simple LoWPAN case the LoWPAN subnet only covers the 6lowpan interfaces and not the egress. Therefore in this example it works exactly like a standard CPE. Even in the Extended LoWPAN case you will have route table entries for destinations in the LoWPAN maintained by some routing algorithm (e.g. ROLL). There is no reason why you can't use a firewall there either. Anyways, this stuff doesn't need to be completely "typical". I mean we are not installing an F-Secure firewall on a Windows PC here. These are application-specific embedded devices most of the time. You can use an embedded Linux box with Linux firewall features to achieve a 6LoWPAN Edge Router. Of course the 6lowpan wireless interface driver and ER features need to be implemented. - Zach > In this sense, it's difficult to consider ER to be a typical router > doing a typical firewall. > > Alex > > -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From alexandru.petrescu@gmail.com Sat Apr 11 06:09:39 2009 Return-Path: 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 C63CC3A685F for <6lowpan@core3.amsl.com>; Sat, 11 Apr 2009 06:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YurEx2AoiU7O for <6lowpan@core3.amsl.com>; Sat, 11 Apr 2009 06:09:38 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id 427273A67E1 for <6lowpan@ietf.org>; Sat, 11 Apr 2009 06:09:36 -0700 (PDT) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 8C4854C8152; Sat, 11 Apr 2009 15:10:41 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 45A944C8128; Sat, 11 Apr 2009 15:10:39 +0200 (CEST) Message-ID: <49E096D1.8000507@gmail.com> Date: Sat, 11 Apr 2009 15:10:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <49DF8FEE.8090503@gmail.com> <49E0546A.3030702@sensinode.com> In-Reply-To: <49E0546A.3030702@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Single-interface routers... 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: , X-List-Received-Date: Sat, 11 Apr 2009 13:09:39 -0000 Zach Shelby a écrit : [ER discussion left apart] >> But when we talk the picture of 6lowpan/roll router, it seemingly >> does not need to make any such IP routing decision: >> >> ---------------- new "subnet" |if0 ---- / \ / \ / Sensor \ >> \ Router / \ / \----/ > > This is correct, 6LoWPAN nodes have a single interface participating > in a LoWPAN. Ok. > If a node has multiple interfaces each operates independently. Ok, I get this part, it's often the case anyways in non-6lowpan. >> What would be the critical SensorRouter operation? It would look >> at which fields of an incoming packet? And it would match it how? >> Into a table of what? > > It matches the IPv6 destination address, with an IP route table which > logically contains Destination.Address, Next-hop.Address tuples. Something like this? IP route table ---------------------------------------- | Destination.Address | Next-hop.Address | |----------------------------------------| search | address1(128bit) | nexthop1(128bit) | dst(128bit) ---------->| address2(128bit) | nexthop2(128bit) | (IP dst field of | ... | ... | the incoming packet's | addressn(128bit) | nexthopn(128bit) | base header.) ---------------------------------------- If yes, an IP route table has additional necessary fields: prefix lengths and interface. I would like to picture them to make sure we're in concordance with implementations - do you think I could? > If there is no match the router uses a default next-hop route up to > an ER (it may keep secondary next-hop defaults). I think this is very important. First, when saying there may be no match it implies that we have a precise idea about what a match is, i.e. the search method is clearly defined. Until now that search method was longest-prefix match (with various implementations on various types of data structures, but always a longest-prefix match). Second, it means there are special routes in the routing table, called default, that I would like to picture like this: IP route table ---------------------------------------- | Destination.Address | Next-hop.Address | |----------------------------------------| search | address1(128bit) | nexthop1(128bit) | dst(128bit) ---------->| address2(128bit) | nexthop2(128bit) | (IP dst field of | ... | ... | the incoming packet's | addressn(128bit) | nexthopn(128bit) | base header.) | ::/0 | nexthopd(128bit) | | ::/0 | nexthope(128bit) | ---------------------------------------- > If there is some reactive routing algorithm it may also trigger some > kind of route request action (e.g. DYMO) which would then find a > next-hop for that destination. I agree, that would be the ROLL part... > A host uses a default next-hop router (the one it sends RR messages > to). It may also use secondary default next-hop routers. I agree, I've pictured the two default routes above. >> A table of MAC addresses? (dst of the received packet, exact match >> search). > > No, the link-layer dst address would be that of the SensorRouter > receiving the packet. Link-layer src/dst are only for that hop. Pictorially, if0----- eth0 -----------------------------| ER |---Internet |if1 |if2 mac0----- |mac1 |mac2 ---- ---- / \ / \ / \ / \ / Sensor \ / Sensor \ \ Router1/ \ Router2/ \ / \ / \----/ \----/ How would one see the use of MAC addresses in this picture? A means coming to mind is typical ND resolving IP addresses into MAC addresses. But. Draft says: > Link-layer information should be used to maintain the neighbor cahce > whenever possible rather than using ND traffic. What is the 'link-layer information' used and how? Once I know that, I can draw the respective tables of MAC addresses and the ways they are used. >> A table of IP addresses? (with a new exact match search). > > Yes, it uses an IP route table doing an exact match search on the > IPv6 dst. Ok, in this case I know what to picture as search algorithm in the routing table: an exact match search, and answers some questions above. I want also to stress that this is completely different than the typical IP routing table using a longest-prefix match search. I'm open to accept this is something new, and I would like to stress this requires new implementation effort, which may raise compatibility issues too, which I could discuss separately. (would a 6lowpan node work ok when adding a WiFi interface to it? which needs typical routing table). > However, as there is a direct mapping between IID and the L2 address This mapping could be concluded as true conceptually... It is a very strong assumption in 6lowpan which should be stated upfront somewhere very early in the draft. Because it is not assumed anywhere else, or otherwise I can't remember. > in 6LoWPAN it is actually the L2 address it is matching if the > destination address is in the LoWPAN. This has no importance on the > IP routing operation though. If the address is outside the LoWPAN a > default route to an ER is used. > >> What is the IP routing model assumed by the single-interface >> router? > >> The text in 6lowpan ND is not clear about this, because at several >> places it uses old terms with new assumed meanings (for example it >> says there's a single subnet, a single link-scope multicast scope, >> but at the same time comments say IP routing and subnet is not what >> used to be). > > We are going to stop using the "subnet" term as it does not describe > what we have here. We tried to define LoWPAN Subnet, but subnet is > too overloaded with restrictions and presumptions. In > draft-ietf-6lowpan-nd-03 we are just calling it a LoWPAN, and a > LoWPAN is defined by a shared prefix across the interfaces of nodes. But a shared prefix across the interfaces of nodes is a subnet, why calling it a "LoWPAN"? For me until now the radical differences of LoWPAN vs typical subnet and IP routing are the following: -no longest-prefix match, but always exact match. -an IID is always related to a unique MAC address and vice-versa. -use ND as least as possible, and "link-layer information" as much as possible. So, instead of a LoWPAN I'd call it an EMIMLIND like in "ExactMatch-IidisMac-LinkLayerInforatherthanND". (excuses, no offence, just to say a more suggestive name should be found which better illustrates this in terms of its implementation traits). > We don't have subnets as the links are so unstable they can't support > subnets as defined by IPv6. Well this is a long discussion about links which are unstable... if links are unstable then IP can't make them more stable... whatever energy is spent on it. > Based on your comments we do need to describe a few things better for > newcomers: > > 1. That LoWPAN routers route on a single interface, and the model for > routing with that single interface should be described in some more > detail. draft-ietf-6lowpan-nd and architecture doc. Can use a figure > like that above. Yes, I could help describe that. > 2. The LoWPAN model, sharing a prefix which you may do IP routing > within. This is not an IPv6 subnet. draft-ietf-6lowpan-nd and > architecture doc. > > 3. How does next-hop determination work with this model. We already > describe this in draft-ietf-6lowpan-nd under Host (Node in -03) > Operations. Can be improved, with more detailed description and an > example. WEll yes, it could be improved, and I hope it clarifies what "link-layer information" is, how it allows a node to safely get rid of using ND (as02 says). > 4. How does an IP routing algorithm work in such a network? This is a > job for ROLL, although an architecture doc for 6lowpan may give a > simple example? IP routing algorithm... I think this encompasses many things, among which at least the search method in the routing table is relevant to 6lowpan documents as well. > Most MANET protocols work fine in such a network from > practical experience. Well yes, I guess they do in particular cases, but even those MANET protocols do have some issues about how IPv6 addresses are allocated and what the subnet structure is, for example, see the AUTOCONF WG. Alex > > - Zach > >> Alex >> >> >> _______________________________________________ 6lowpan mailing >> list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan >> > From richard.kelsey@ember.com Sat Apr 11 10:47:01 2009 Return-Path: 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 0E1983A6A8B for <6lowpan@core3.amsl.com>; Sat, 11 Apr 2009 10:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LbifEO6IT6D for <6lowpan@core3.amsl.com>; Sat, 11 Apr 2009 10:47:00 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 320CA3A685F for <6lowpan@ietf.org>; Sat, 11 Apr 2009 10:47:00 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 11 Apr 2009 13:48:54 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3BHm8f3002707; Sat, 11 Apr 2009 13:48:08 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3BHm8Sw002704; Sat, 11 Apr 2009 13:48:08 -0400 Date: Sat, 11 Apr 2009 13:48:08 -0400 Message-Id: <200904111748.n3BHm8Sw002704@kelsey-ws.hq.ember.com> To: zach@sensinode.com In-reply-to: <49E08B3D.6030003@sensinode.com> (message from Zach Shelby on Sat, 11 Apr 2009 15:21:17 +0300) From: Richard Kelsey References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <49DFB1DB.3040602@gmail.com> <49E04284.6000900@sensinode.com> <49E0880E.1030803@gmail.com> <49E08B3D.6030003@sensinode.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Apr 2009 17:48:54.0429 (UTC) FILETIME=[C80F7CD0:01C9BACD] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] 6lowpan-ND vs. ROLL 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: , X-List-Received-Date: Sat, 11 Apr 2009 17:47:01 -0000 Date: Sat, 11 Apr 2009 15:21:17 +0300 From: Zach Shelby >>> Richard Kelsey a écrit : >>>> From: Carsten Bormann Date: Fri, 10 Apr 2009 >>>> 19:00:42 +0200 >>>> >>>> (I don't tend to think about the case where there is no Edge >>>> Router -- ...) >>>> >>>> I have a question on this, stemming from my lack of familiarity >>>> with the details of IP routing. >>>> >>>> Suppose I have a 6LowPAN/ROLL network being used for energy >>>> management in a home. The network includes the electric meter, >>>> which has a backhaul connection back to the utility. The utility, >>>> being very protective of its backhaul network, has a firewall in >>>> the meter to keep out everything except the utility's own >>>> traffic. Given the presence of the firewall, does it still make >>>> sense to use the meter as an Edge Router? [Is an Edge Router an IP router? ... Yes.] Anyways, this stuff doesn't need to be completely "typical". I mean we are not installing an F-Secure firewall on a Windows PC here. These are application-specific embedded devices most of the time. You can use an embedded Linux box with Linux firewall features to achieve a 6LoWPAN Edge Router. Of course the 6lowpan wireless interface driver and ER features need to be implemented. In the network I was describing, the meter has no more horsepower than the other devices on the network. It has a small micro with around 4k of RAM. It certainly isn't something as powerful as an embedded Linux box. Is it unreasonable to expect it to act as an Edge Router? If not, how should its connection between the LowPAN and the utility backhaul be handled? -Richard Kelsey From jhui@archrock.com Sat Apr 11 11:18:39 2009 Return-Path: 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 52D693A69D4; Sat, 11 Apr 2009 11:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u10XUtUXOWuN; Sat, 11 Apr 2009 11:18:38 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 51C523A6860; Sat, 11 Apr 2009 11:18:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id ECB50AF8B1; Sat, 11 Apr 2009 11:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UasdrxZ7PP1W; Sat, 11 Apr 2009 11:19:43 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-74-235.dsl.pltn13.pacbell.net [71.142.74.235]) by mail.sf.archrock.com (Postfix) with ESMTP id 8241AAF882; Sat, 11 Apr 2009 11:19:43 -0700 (PDT) Message-Id: <78F9E848-A866-45C6-94ED-A5BC6F741F8B@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 11 Apr 2009 11:19:42 -0700 References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.930.3) Cc: cabo@tzi.org, 6lowpan <6lowpan@ietf.org>, roll@ietf.org Subject: Re: [6lowpan] [Roll] 6lowpan-ND vs. ROLL 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: , X-List-Received-Date: Sat, 11 Apr 2009 18:18:39 -0000 Hi Richard, If both egress routers are advertising default routes, then I see no problem with the stub network deciding which to choose. If they have different costs, then definitely the two should be advertising different costs. If the meter network only wants to accept traffic to a particular prefix, then it should only be advertising that. I do think we need to better define what exactly is an Edge Router in and out of a 6lowpan context. In general, I think of an Edge Router as nothing more than a router that routes between an L2N network to a non- L2N network. In the 6lowpan context, we typically associate an Edge Router with one that also maintains the "whiteboard" for nodes in the 6lowpan network. However, I'm not sure we need to bind them together. Specific to the 6LoWPAN ND draft, you do bring up an important case - one where two or more Edge Routers are not connected by a "backbone" network. I think there are interesting questions there that are not dealt with in the current 6LoWPAN ND draft (e.g. how is the whiteboard information distributed between edge routers if at all? can we have a particular whiteboard specific for a prefix maintained at only the Edge Router that advertises that prefix? do whiteboards have to be maintained at edge routers?). We should probably open a new thread on this topic in the 6LoWPAN ML... -- Jonathan Hui On Apr 10, 2009, at 1:01 PM, Richard Kelsey wrote: > From: Carsten Bormann > Date: Fri, 10 Apr 2009 19:00:42 +0200 > > (I don't tend to think about the case where there is no > Edge Router -- ...) > > I have a question on this, stemming from my lack of > familiarity with the details of IP routing. > > Suppose I have a 6LowPAN/ROLL network being used for energy > management in a home. The network includes the electric > meter, which has a backhaul connection back to the utility. > The utility, being very protective of its backhaul network, > has a firewall in the meter to keep out everything except > the utility's own traffic. Given the presence of the > firewall, does it still make sense to use the meter as an > Edge Router? > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From zach@sensinode.com Sun Apr 12 03:41:19 2009 Return-Path: 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 01ABE3A6950 for <6lowpan@core3.amsl.com>; Sun, 12 Apr 2009 03:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxrKvcqw-HHr for <6lowpan@core3.amsl.com>; Sun, 12 Apr 2009 03:41:18 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A7F463A6ADD for <6lowpan@ietf.org>; Sun, 12 Apr 2009 03:41:15 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n3CAgIUu018111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Apr 2009 13:42:18 +0300 Message-ID: <49E1C5A9.4060800@sensinode.com> Date: Sun, 12 Apr 2009 13:42:49 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jonathan Hui References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <78F9E848-A866-45C6-94ED-A5BC6F741F8B@archrock.com> In-Reply-To: <78F9E848-A866-45C6-94ED-A5BC6F741F8B@archrock.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Whiteboard + ER (Was 6LoWPAN vs. ROLL) 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: , X-List-Received-Date: Sun, 12 Apr 2009 10:41:19 -0000 Hi, Thread now on 6lowpan only. Jonathan Hui wrote: > > Hi Richard, > > If both egress routers are advertising default routes, then I see no > problem with the stub network deciding which to choose. If they have > different costs, then definitely the two should be advertising different > costs. If the meter network only wants to accept traffic to a particular > prefix, then it should only be advertising that. Agreed. > I do think we need to better define what exactly is an Edge Router in > and out of a 6lowpan context. In general, I think of an Edge Router as > nothing more than a router that routes between an L2N network to a > non-L2N network. In the 6lowpan context, we typically associate an Edge > Router with one that also maintains the "whiteboard" for nodes in the > 6lowpan network. However, I'm not sure we need to bind them together. Yep, I agree it needs to be a generic term usable in both 6LoWPAN and IP contexts (e.g. in roll). Proposal 1: We call it an Access Router (AR) and agree to share that term with ROLL. An AR is simply a router that routes between L2N and non-L2N networks. Proposal 2: We define Whiteboard as an additional feature that SHOULD be implemented in an Access Router but MAY be implemented on any other node in the network (e.g. in the ad-hoc LoWPAN case). > Specific to the 6LoWPAN ND draft, you do bring up an important case - > one where two or more Edge Routers are not connected by a "backbone" > network. I think there are interesting questions there that are not > dealt with in the current 6LoWPAN ND draft (e.g. how is the whiteboard > information distributed between edge routers if at all? can we have a > particular whiteboard specific for a prefix maintained at only the Edge > Router that advertises that prefix? do whiteboards have to be maintained > at edge routers?). We should probably open a new thread on this topic in > the 6LoWPAN ML... The Whiteboard is specific to a LoWPAN (= a prefix). Whiteboard information is not distributed between different LoWPANs (there is no point). In an extended LoWPAN multiple whiteboards on ARs are part of the same LoWPAN (same prefix) and use a backbone link to perform DAD and claim/defend node addresses across the whole LoWPAN. A Whiteboard does not need to be located at an AR, but it is a logical place in most cases. In the Extended LoWPAN case the whiteboard needs to be located on nodes which have a shared backbone link (usually ARs). We discuss that a little in the ND draft but I think it can be expanded to make that clear with an example. - Zach > -- > Jonathan Hui > > On Apr 10, 2009, at 1:01 PM, Richard Kelsey wrote: > >> From: Carsten Bormann >> Date: Fri, 10 Apr 2009 19:00:42 +0200 >> >> (I don't tend to think about the case where there is no >> Edge Router -- ...) >> >> I have a question on this, stemming from my lack of >> familiarity with the details of IP routing. >> >> Suppose I have a 6LowPAN/ROLL network being used for energy >> management in a home. The network includes the electric >> meter, which has a backhaul connection back to the utility. >> The utility, being very protective of its backhaul network, >> has a firewall in the meter to keep out everything except >> the utility's own traffic. Given the presence of the >> firewall, does it still make sense to use the meter as an >> Edge Router? >> -Richard Kelsey >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From alexandru.petrescu@gmail.com Sun Apr 12 11:07:19 2009 Return-Path: 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 99E4D3A6A6E for <6lowpan@core3.amsl.com>; Sun, 12 Apr 2009 11:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXn5EN-eSu0g for <6lowpan@core3.amsl.com>; Sun, 12 Apr 2009 11:07:18 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6693A68DE for <6lowpan@ietf.org>; Sun, 12 Apr 2009 11:07:16 -0700 (PDT) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 800C7940123; Sun, 12 Apr 2009 20:08:22 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 42700940168; Sun, 12 Apr 2009 20:08:20 +0200 (CEST) Message-ID: <49E22E1A.6020108@gmail.com> Date: Sun, 12 Apr 2009 20:08:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <78F9E848-A866-45C6-94ED-A5BC6F741F8B@archrock.com> <49E1C5A9.4060800@sensinode.com> In-Reply-To: <49E1C5A9.4060800@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Whiteboard + ER (Was 6LoWPAN vs. ROLL) 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: , X-List-Received-Date: Sun, 12 Apr 2009 18:07:19 -0000 Zach Shelby a écrit : > Hi, > > Thread now on 6lowpan only. > > Jonathan Hui wrote: >> >> Hi Richard, >> >> If both egress routers are advertising default routes, then I see >> no problem with the stub network deciding which to choose. If they >> have different costs, then definitely the two should be advertising >> different costs. If the meter network only wants to accept traffic >> to a particular prefix, then it should only be advertising that. > > Agreed. > >> I do think we need to better define what exactly is an Edge Router >> in and out of a 6lowpan context. In general, I think of an Edge >> Router as nothing more than a router that routes between an L2N >> network to a non-L2N network. In the 6lowpan context, we typically >> associate an Edge Router with one that also maintains the >> "whiteboard" for nodes in the 6lowpan network. However, I'm not >> sure we need to bind them together. > > Yep, I agree it needs to be a generic term usable in both 6LoWPAN and > IP contexts (e.g. in roll). > > Proposal 1: We call it an Access Router (AR) and agree to share that > term with ROLL. An AR is simply a router that routes between L2N and > non-L2N networks. I agree with the term AR, and it simply routes between L2N and non-L2N networks. In this sense it would (1) no longer state its egress and the L2N interface share the same IPv6 subnet (as the current 6lowpan ND document states) and (2) would need a definition at least distinguishing it from the AR of rfc3753 "mobility terminology". > Proposal 2: We define Whiteboard as an additional feature that SHOULD > be implemented in an Access Router but MAY be implemented on any > other node in the network (e.g. in the ad-hoc LoWPAN case). I'm interested in the 'whiteboard' conceptual data structure. >> Specific to the 6LoWPAN ND draft, you do bring up an important case >> - one where two or more Edge Routers are not connected by a >> "backbone" network. I think there are interesting questions there >> that are not dealt with in the current 6LoWPAN ND draft (e.g. how >> is the whiteboard information distributed between edge routers if >> at all? can we have a particular whiteboard specific for a prefix >> maintained at only the Edge Router that advertises that prefix? do >> whiteboards have to be maintained at edge routers?). We should >> probably open a new thread on this topic in the 6LoWPAN ML... > > The Whiteboard is specific to a LoWPAN (= a prefix). Whiteboard > information is not distributed between different LoWPANs (there is no > point). In an extended LoWPAN multiple whiteboards on ARs are part > of the same LoWPAN (same prefix) and use a backbone link to perform > DAD and claim/defend node addresses across the whole LoWPAN. > > A Whiteboard does not need to be located at an AR, but it is a > logical place in most cases. In the Extended LoWPAN case the > whiteboard needs to be located on nodes which have a shared backbone > link (usually ARs). > > We discuss that a little in the ND draft but I think it can be > expanded to make that clear with an example. YEs, 'whiteboard' is presented at length in the ND draft. Reading it let me represent what I understand: One entry in the whiteboard is for one unique node, and contains these fields: IPv6 Prefix IPv6 address1(128bit) IPv6 address2(128bit) Interface ID (64bit) Owner Interface Identifier(64bit) Transaction ID1 (16bit) Transaction ID2 (16bit) Transaction ID3 (16bit) Transaction ID4 (16bit) Lifetime(32bit) I've put an entry "IPv6 Prefix" because you mentioned it above, and makes sense to have a unique prefix for all nodes in the lowpan, be it a subnet. But it would be helpful to say whether it is a 'prefix length' attached to the IPv6 address1/2 fields below it, or is it an independent bitstring (of what length?), etc. There are two IPv6 addresses in each entry because the draft says whiteboard is similar to a MIPv6 Binding Cache, which has 2, but I'm not sure this was the intention. Also the draft says that the node may have several addresses, but I'm not sure the intention to have n IPv6 addresses in each entry - or is it? Also there's an IID and an OII, but I doubt the intention is to have two 64bit identifiers. At times it is _implied_ that a MAC address could be in the whiteboard, but it is not clear whether yes or no, and whether a 48bit address or a 16bit 'short' address. I think this could be clarified further. I personally see the en entry in the whiteboard conceptual data structure to contain only the following: IPv6 address Prefix length MAC short address MAC address lifetime TID1 TID2 TID3 TID4 Alex From jhui@archrock.com Sun Apr 12 11:25:31 2009 Return-Path: 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 5A87B3A6BE6 for <6lowpan@core3.amsl.com>; Sun, 12 Apr 2009 11:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fWRFMl3CfGt for <6lowpan@core3.amsl.com>; Sun, 12 Apr 2009 11:25:19 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 3CB193A6B04 for <6lowpan@ietf.org>; Sun, 12 Apr 2009 11:25:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id F19A1AF8C2; Sun, 12 Apr 2009 11:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXbw1zM4wqPr; Sun, 12 Apr 2009 11:26:20 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-74-235.dsl.pltn13.pacbell.net [71.142.74.235]) by mail.sf.archrock.com (Postfix) with ESMTP id BDC59AF882; Sun, 12 Apr 2009 11:26:19 -0700 (PDT) Message-Id: <144E9B49-F3E7-4936-B3F2-01DFD8B75CF3@archrock.com> From: Jonathan Hui To: Zach Shelby In-Reply-To: <49E1C5A9.4060800@sensinode.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 12 Apr 2009 11:26:19 -0700 References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <78F9E848-A866-45C6-94ED-A5BC6F741F8B@archrock.com> <49E1C5A9.4060800@sensinode.com> X-Mailer: Apple Mail (2.930.3) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Whiteboard + ER (Was 6LoWPAN vs. ROLL) 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: , X-List-Received-Date: Sun, 12 Apr 2009 18:25:31 -0000 Hi Zach, On Apr 12, 2009, at 3:42 AM, Zach Shelby wrote: >> Specific to the 6LoWPAN ND draft, you do bring up an important case =20= >> - one where two or more Edge Routers are not connected by a =20 >> "backbone" network. I think there are interesting questions there =20 >> that are not dealt with in the current 6LoWPAN ND draft (e.g. how =20 >> is the whiteboard information distributed between edge routers if =20 >> at all? can we have a particular whiteboard specific for a prefix =20 >> maintained at only the Edge Router that advertises that prefix? do =20= >> whiteboards have to be maintained at edge routers?). We should =20 >> probably open a new thread on this topic in the 6LoWPAN ML... > > The Whiteboard is specific to a LoWPAN (=3D a prefix). Whiteboard =20 > information is not distributed between different LoWPANs (there is =20 > no point). In an extended LoWPAN multiple whiteboards on ARs are =20 > part of the same LoWPAN (same prefix) and use a backbone link to =20 > perform DAD and claim/defend node addresses across the whole LoWPAN. Be careful about your definition of a "LoWPAN". Just because a LoWPAN =20= is defined by a single prefix doesn't mean that a PAN cannot support =20 multiple prefixes. In Richard's case, I see two different Access Routers *not* connected =20= over a backbone but advertise different prefixes to the same PAN. =20 Nodes in the PAN may be multihomed and configure addresses for the two =20= different networks. If we define a whiteboard to manage addresses for =20= a particular prefix, then we have two whiteboards and let's assume =20 that each resides at their respective advertising Access Router. I =20 think there's an open question as to how RRs are sent - in particular, =20= how does an RR get sent to the appropriate whiteboard? This is not =20 considered in the current ND draft. > A Whiteboard does not need to be located at an AR, but it is a =20 > logical place in most cases. In the Extended LoWPAN case the =20 > whiteboard needs to be located on nodes which have a shared backbone =20= > link (usually ARs). > > We discuss that a little in the ND draft but I think it can be =20 > expanded to make that clear with an example. I do think we need to be more clear. The draft is confusing because it =20= makes concrete statements like: "The edge router maintains a =20 whiteboard of all hosts in the network." There's a bunch of =20 assumptions that can be made from this statement. The obvious is that =20= the whiteboard is located at an edge router. Another is that the =20 whiteboard is not bound to a particular prefix, but maintains =20 information for all hosts. -- Jonathan Hui > > - Zach > >> --=20 >> Jonathan Hui >> On Apr 10, 2009, at 1:01 PM, Richard Kelsey wrote: >>> From: Carsten Bormann >>> Date: Fri, 10 Apr 2009 19:00:42 +0200 >>> >>> (I don't tend to think about the case where there is no >>> Edge Router -- ...) >>> >>> I have a question on this, stemming from my lack of >>> familiarity with the details of IP routing. >>> >>> Suppose I have a 6LowPAN/ROLL network being used for energy >>> management in a home. The network includes the electric >>> meter, which has a backhaul connection back to the utility. >>> The utility, being very protective of its backhaul network, >>> has a firewall in the meter to keep out everything except >>> the utility's own traffic. Given the presence of the >>> firewall, does it still make sense to use the meter as an >>> Edge Router? >>> -Richard Kelsey >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > --=20 > http://zachshelby.org - My blog =93On the Internet of Things=94 > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may =20 > contain legally privileged information. If you are not the intended =20= > recipient, please contact the sender and delete the e-mail from your =20= > system without producing, distributing or retaining copies thereof. From zach@sensinode.com Sun Apr 12 23:15:17 2009 Return-Path: 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 2ADC53A6BEA for <6lowpan@core3.amsl.com>; Sun, 12 Apr 2009 23:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F3Lpybu4nhm for <6lowpan@core3.amsl.com>; Sun, 12 Apr 2009 23:15:16 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 951563A67E5 for <6lowpan@ietf.org>; Sun, 12 Apr 2009 23:15:14 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n3D6GHHc004231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 09:16:18 +0300 Message-ID: <49E2D8D5.4040404@sensinode.com> Date: Mon, 13 Apr 2009 09:16:53 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jonathan Hui References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <78F9E848-A866-45C6-94ED-A5BC6F741F8B@archrock.com> <49E1C5A9.4060800@sensinode.com> <144E9B49-F3E7-4936-B3F2-01DFD8B75CF3@archrock.com> In-Reply-To: <144E9B49-F3E7-4936-B3F2-01DFD8B75CF3@archrock.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Whiteboard + ER (Was 6LoWPAN vs. ROLL) 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: , X-List-Received-Date: Mon, 13 Apr 2009 06:15:17 -0000 Hi, Jonathan Hui wrote: > > Hi Zach, > > On Apr 12, 2009, at 3:42 AM, Zach Shelby wrote: >>> Specific to the 6LoWPAN ND draft, you do bring up an important case - >>> one where two or more Edge Routers are not connected by a "backbone" >>> network. I think there are interesting questions there that are not >>> dealt with in the current 6LoWPAN ND draft (e.g. how is the >>> whiteboard information distributed between edge routers if at all? >>> can we have a particular whiteboard specific for a prefix maintained >>> at only the Edge Router that advertises that prefix? do whiteboards >>> have to be maintained at edge routers?). We should probably open a >>> new thread on this topic in the 6LoWPAN ML... >> >> The Whiteboard is specific to a LoWPAN (= a prefix). Whiteboard >> information is not distributed between different LoWPANs (there is no >> point). In an extended LoWPAN multiple whiteboards on ARs are part of >> the same LoWPAN (same prefix) and use a backbone link to perform DAD >> and claim/defend node addresses across the whole LoWPAN. > > Be careful about your definition of a "LoWPAN". Just because a LoWPAN is > defined by a single prefix doesn't mean that a PAN cannot support > multiple prefixes. I agree completely. You can have several LoWPANs (L3 concept) running over the same PAN (L2 concept specific to IEEE 802.15.4). > In Richard's case, I see two different Access Routers *not* connected > over a backbone but advertise different prefixes to the same PAN. Nodes > in the PAN may be multihomed and configure addresses for the two > different networks. If we define a whiteboard to manage addresses for a > particular prefix, then we have two whiteboards and let's assume that > each resides at their respective advertising Access Router. I think > there's an open question as to how RRs are sent - in particular, how > does an RR get sent to the appropriate whiteboard? This is not > considered in the current ND draft. Yep, this will be a common case. A router will need to specifically choose which LoWPAN it wants to advertise routes for so it is advertising a consistent prefix information set of context IDs. This way a host can choose which LoWPAN to participate in by choosing the router advertising that prefix. Hosts could then multihome as you suggest. Yes, we need to discuss that in the draft more. As the draft is now we don't have sufficient information advertised in RAs to allow routers to advertise prefixes for multiple LoWPANs simultaneously. >> A Whiteboard does not need to be located at an AR, but it is a logical >> place in most cases. In the Extended LoWPAN case the whiteboard needs >> to be located on nodes which have a shared backbone link (usually ARs). >> >> We discuss that a little in the ND draft but I think it can be >> expanded to make that clear with an example. > > I do think we need to be more clear. The draft is confusing because it > makes concrete statements like: "The edge router maintains a whiteboard > of all hosts in the network." There's a bunch of assumptions that can be > made from this statement. The obvious is that the whiteboard is located > at an edge router. Another is that the whiteboard is not bound to a > particular prefix, but maintains information for all hosts. Agreed. Will make a ticket for this. > -- > Jonathan Hui > >> >> - Zach >> >>> -- >>> Jonathan Hui >>> On Apr 10, 2009, at 1:01 PM, Richard Kelsey wrote: >>>> From: Carsten Bormann >>>> Date: Fri, 10 Apr 2009 19:00:42 +0200 >>>> >>>> (I don't tend to think about the case where there is no >>>> Edge Router -- ...) >>>> >>>> I have a question on this, stemming from my lack of >>>> familiarity with the details of IP routing. >>>> >>>> Suppose I have a 6LowPAN/ROLL network being used for energy >>>> management in a home. The network includes the electric >>>> meter, which has a backhaul connection back to the utility. >>>> The utility, being very protective of its backhaul network, >>>> has a firewall in the meter to keep out everything except >>>> the utility's own traffic. Given the presence of the >>>> firewall, does it still make sense to use the meter as an >>>> Edge Router? >>>> -Richard Kelsey >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> >> -- >> http://zachshelby.org - My blog “On the Internet of Things” >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> 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. > -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From eunah.ietf@gmail.com Mon Apr 13 00:26:44 2009 Return-Path: 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 E6B473A6B45 for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 00:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ToF+483p+oSJ for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 00:26:44 -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 1D7613A69D2 for <6lowpan@ietf.org>; Mon, 13 Apr 2009 00:26:44 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so1606563rvb.49 for <6lowpan@ietf.org>; Mon, 13 Apr 2009 00:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=yJ08ssvCLnAmoQdkB/vmJO4DEyU3eThdP7AcHdjrKdA=; b=hKpYddJfKbFIOM6g4rVDo9O2tBeBFxu0PCJ8G/mliDlDkzai+UF7zEg3x8L+WYC4Ug CTl5NgpraBB2Yy058pOfosGjstjSH6RS9foHpc9ADL9M0rWbXqvW2ZXvximA5tRSHSw0 Ni9PaTYo8MOs+8Vydm8Y9VWghC6o6DIy4upEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=c8tQ49XByBoZ2M5Alp9KGYP0euK0yZt7l87vAJ9OK22T8bR5ewTDo9KbSPVSdGGoZq 5J4EFTasdz+pTDbK4OkPhJGLbnK875EZJ8diqZr/zQdeA8Cg36yxHSgQTbwifER8lQmg 0gPM56LGwvHKP7zNKr/iULxGBCjZ2ucJtzubA= MIME-Version: 1.0 Received: by 10.140.143.13 with SMTP id q13mr1284649rvd.66.1239607674800; Mon, 13 Apr 2009 00:27:54 -0700 (PDT) In-Reply-To: <20090325212241.0BAC53A6DBC@core3.amsl.com> References: <20090325212241.0BAC53A6DBC@core3.amsl.com> Date: Mon, 13 Apr 2009 16:27:54 +0900 Message-ID: <77f1dba80904130027p6f9587ft9876607c93a77747@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-routing-requirements-02 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: , X-List-Received-Date: Mon, 13 Apr 2009 07:26:45 -0000 Dear 6LoWPANers, 6LoWPAN routing requirements draft has been updated right after the 6LoWPAN meeting in SF (March 25th). Somehow, it seems that the auto-announcement for a new doc was not made for this update. After -02, we got some issues and we are preparing -03 to solve the following 3 issues: 1. clarification that this document is only requirement, not assuming solution part. all 6lowpaners understand this part well, but JP raised the issue that new-comers and non-6lowpaners may feel confused. 2. Terminology. Based on the current ND discussion, we also need to change ER to AR if concensus is there. 3. Security consideration. Last SF meeting, AD mentioned that each doc may need stronger security considerations as we've included a lot of 'architecture like introduction part' for on-going 6lowpan WG docs. (as a solution for WG milestone with lack of security doc progressing) I'll put these 3 issues in 6lowpan issue tracker. Comments are invited. -eunah ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Thu, Mar 26, 2009 at 6:22 AM Subject: New Version Notification for draft-ietf-6lowpan-routing-requirements-02 To: cabo@tzi.org Cc: eunah.ietf@gmail.com, dokaspar.ietf@gmail.com, carlesgo@entel.upc.edu A new version of I-D, draft-ietf-6lowpan-routing-requirements-02.txt has been successfuly submitted by Carsten Bormann and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-ietf-6lowpan-routing-requirements Revision: =A0 =A0 =A0 =A002 Title: =A0 =A0 =A0 =A0 =A0 Problem Statement and Requirements for 6LoWPAN R= outing Creation_date: =A0 2009-03-25 WG ID: =A0 =A0 =A0 =A0 =A0 6lowpan Number_of_pages: 32 Abstract: This document provides the problem statement for 6LoWPAN routing. =A0It also defines the requirements for 6LoWPAN routing considering IEEE 802.15.4 specificities and the low-power characteristics of the network and its devices. The IETF Secretariat. From richard.kelsey@ember.com Mon Apr 13 07:23:09 2009 Return-Path: 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 5C04A3A6D47 for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 07:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztblOg7rzSgm for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 07:23:08 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6EFD73A6C33 for <6lowpan@ietf.org>; Mon, 13 Apr 2009 07:23:08 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 10:25:05 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3DEOIfa030512; Mon, 13 Apr 2009 10:24:18 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3DEOGMO030509; Mon, 13 Apr 2009 10:24:16 -0400 Date: Mon, 13 Apr 2009 10:24:16 -0400 Message-Id: <200904131424.n3DEOGMO030509@kelsey-ws.hq.ember.com> To: zach@sensinode.com In-reply-to: <49E2D8D5.4040404@sensinode.com> (message from Zach Shelby on Mon, 13 Apr 2009 09:16:53 +0300) From: Richard Kelsey References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <78F9E848-A866-45C6-94ED-A5BC6F741F8B@archrock.com> <49E1C5A9.4060800@sensinode.com> <144E9B49-F3E7-4936-B3F2-01DFD8B75CF3@archrock.com> <49E2D8D5.4040404@sensinode.com> X-OriginalArrivalTime: 13 Apr 2009 14:25:05.0258 (UTC) FILETIME=[A3BB94A0:01C9BC43] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Whiteboard + ER (Was 6LoWPAN vs. ROLL) 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: , X-List-Received-Date: Mon, 13 Apr 2009 14:23:09 -0000 Date: Mon, 13 Apr 2009 09:16:53 +0300 From: Zach Shelby Jonathan Hui wrote: > > Hi Zach, > > On Apr 12, 2009, at 3:42 AM, Zach Shelby wrote: >> >> The Whiteboard is specific to a LoWPAN (= a prefix). Whiteboard >> information is not distributed between different LoWPANs (there is no >> point). In an extended LoWPAN multiple whiteboards on ARs are part of >> the same LoWPAN (same prefix) and use a backbone link to perform DAD >> and claim/defend node addresses across the whole LoWPAN. > > Be careful about your definition of a "LoWPAN". Just because a LoWPAN is > defined by a single prefix doesn't mean that a PAN cannot support > multiple prefixes. I agree completely. You can have several LoWPANs (L3 concept) running over the same PAN (L2 concept specific to IEEE 802.15.4). This would seem to put the hop-by-hop PAN routing in L2 in order to allow full use of the wireless mesh. This would be problematic. The alternative is to have L3 keep track of LoWPAN and PAN addressing and routing separately in order to allow use of a next hop in one LowPAN when routing to a destination in a different LowPAN. -Richard Kelsey From richard.kelsey@ember.com Mon Apr 13 07:39:20 2009 Return-Path: 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 669633A6E19 for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 07:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwgAZTLE-7+Q for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 07:39:19 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 7877F3A6D9D for <6lowpan@ietf.org>; Mon, 13 Apr 2009 07:39:19 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 10:41:17 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3DEeU45030668; Mon, 13 Apr 2009 10:40:30 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3DEeTgj030665; Mon, 13 Apr 2009 10:40:29 -0400 Date: Mon, 13 Apr 2009 10:40:29 -0400 Message-Id: <200904131440.n3DEeTgj030665@kelsey-ws.hq.ember.com> To: jhui@archrock.com In-reply-to: <144E9B49-F3E7-4936-B3F2-01DFD8B75CF3@archrock.com> (message from Jonathan Hui on Sun, 12 Apr 2009 11:26:19 -0700) From: Richard Kelsey References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <78F9E848-A866-45C6-94ED-A5BC6F741F8B@archrock.com> <49E1C5A9.4060800@sensinode.com> <144E9B49-F3E7-4936-B3F2-01DFD8B75CF3@archrock.com> X-OriginalArrivalTime: 13 Apr 2009 14:41:17.0054 (UTC) FILETIME=[E6F7E1E0:01C9BC45] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Whiteboard + ER (Was 6LoWPAN vs. ROLL) 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: , X-List-Received-Date: Mon, 13 Apr 2009 14:39:20 -0000 From: Jonathan Hui Date: Sun, 12 Apr 2009 11:26:19 -0700 On Apr 12, 2009, at 3:42 AM, Zach Shelby wrote: >> Specific to the 6LoWPAN ND draft, you do bring up an important case >> - one where two or more Edge Routers are not connected by a >> "backbone" network. I think there are interesting questions there >> that are not dealt with in the current 6LoWPAN ND draft (e.g. how >> is the whiteboard information distributed between edge routers if >> at all? can we have a particular whiteboard specific for a prefix >> maintained at only the Edge Router that advertises that prefix? do >> whiteboards have to be maintained at edge routers?). We should >> probably open a new thread on this topic in the 6LoWPAN ML... > > The Whiteboard is specific to a LoWPAN (= a prefix). Whiteboard > information is not distributed between different LoWPANs (there is > no point). In an extended LoWPAN multiple whiteboards on ARs are > part of the same LoWPAN (same prefix) and use a backbone link to > perform DAD and claim/defend node addresses across the whole LoWPAN. Be careful about your definition of a "LoWPAN". Just because a LoWPAN is defined by a single prefix doesn't mean that a PAN cannot support multiple prefixes. In Richard's case, I see two different Access Routers *not* connected over a backbone but advertise different prefixes to the same PAN. Nodes in the PAN may be multihomed and configure addresses for the two different networks. If we define a whiteboard to manage addresses for a particular prefix, then we have two whiteboards and let's assume that each resides at their respective advertising Access Router. Ouch. I have been worrying about where to find the space to store one whiteboard and now there are two. Does the whiteboard have to be on a LoWPAN device or can it be on some other router reachable via a backhaul network? -Richard Kelsey From jhui@archrock.com Mon Apr 13 07:41:05 2009 Return-Path: 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 E417D28C128 for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 07:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpBxtN5dY6Ji for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 07:41:05 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 50B453A6DEC for <6lowpan@ietf.org>; Mon, 13 Apr 2009 07:40:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 5A1EBAF8D0; Mon, 13 Apr 2009 07:41:48 -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 BJftZLIxBwJS; Mon, 13 Apr 2009 07:41:43 -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 8D638AF865; Mon, 13 Apr 2009 07:41:43 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <200904131424.n3DEOGMO030509@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 07:41:42 -0700 References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <78F9E848-A866-45C6-94ED-A5BC6F741F8B@archrock.com> <49E1C5A9.4060800@sensinode.com> <144E9B49-F3E7-4936-B3F2-01DFD8B75CF3@archrock.com> <49E2D8D5.4040404@sensinode.com> <200904131424.n3DEOGMO030509@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.930.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Whiteboard + ER (Was 6LoWPAN vs. ROLL) 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: , X-List-Received-Date: Mon, 13 Apr 2009 14:41:06 -0000 Hi Richard, On Apr 13, 2009, at 7:24 AM, Richard Kelsey wrote: > Date: Mon, 13 Apr 2009 09:16:53 +0300 > From: Zach Shelby > > Jonathan Hui wrote: >> Be careful about your definition of a "LoWPAN". Just because a >> LoWPAN is >> defined by a single prefix doesn't mean that a PAN cannot support >> multiple prefixes. > > I agree completely. You can have several LoWPANs (L3 concept) > running over the same PAN (L2 concept specific to IEEE 802.15.4). > > This would seem to put the hop-by-hop PAN routing in L2 in > order to allow full use of the wireless mesh. This would be > problematic. The alternative is to have L3 keep track of > LoWPAN and PAN addressing and routing separately in order to > allow use of a next hop in one LowPAN when routing to a > destination in a different LowPAN. The current definition of LoWPAN is simply a collection of interfaces in the same PAN that are assigned addresses with the same prefix. It doesn't have anything to do with the definition of a link. As such, a LoWPAN can consist of either a mesh-under or route-over configuration. -- Jonathan Hui From jhui@archrock.com Mon Apr 13 07:45:23 2009 Return-Path: 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 5AC503A6E19 for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 07:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NK3KmCCFl-g1 for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 07:45:22 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id A65363A6DEC for <6lowpan@ietf.org>; Mon, 13 Apr 2009 07:45:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id BC66DAF8D0; Mon, 13 Apr 2009 07:46:33 -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 vX3+xKPnx0KY; Mon, 13 Apr 2009 07:46:29 -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 E91E5AF865; Mon, 13 Apr 2009 07:46:28 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <200904131440.n3DEeTgj030665@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 07:46:27 -0700 References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <78F9E848-A866-45C6-94ED-A5BC6F741F8B@archrock.com> <49E1C5A9.4060800@sensinode.com> <144E9B49-F3E7-4936-B3F2-01DFD8B75CF3@archrock.com> <200904131440.n3DEeTgj030665@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.930.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Whiteboard + ER (Was 6LoWPAN vs. ROLL) 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: , X-List-Received-Date: Mon, 13 Apr 2009 14:45:23 -0000 Hi Richard, On Apr 13, 2009, at 7:40 AM, Richard Kelsey wrote: > In Richard's case, I see two different Access Routers *not* > connected > over a backbone but advertise different prefixes to the same PAN. > Nodes in the PAN may be multihomed and configure addresses for the > two > different networks. If we define a whiteboard to manage addresses > for > a particular prefix, then we have two whiteboards and let's assume > that each resides at their respective advertising Access Router. > > Ouch. I have been worrying about where to find the space to > store one whiteboard and now there are two. Does the > whiteboard have to be on a LoWPAN device or can it be on > some other router reachable via a backhaul network? In the current 6LoWPAN ND model, there needs to be a whiteboard entry for every IPv6 address assigned to an interface in the PAN. That's true whether or not the information is spread across one or multiple white boards. If you're worried about code space, then yes, of course, that part is duplicated. But if you want the network to function with Access Router A or Access Router B or both and the whiteboard is located at an Access Router, then both have to implement it any way. The 6LoWPAN ND model does support a Relay option. There's a question of whether or not there can be multiple Relay hops. If we did that, then this would start to look awfully close to DHCPv6. -- Jonathan Hui From ben@blindcreek.com Mon Apr 13 07:59:18 2009 Return-Path: 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 AF9EB3A6CED for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 07:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k7tuUj7mun6 for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 07:59:17 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [65.254.51.10]) by core3.amsl.com (Postfix) with ESMTP id ABE053A6DAA for <6lowpan@ietf.org>; Mon, 13 Apr 2009 07:59:17 -0700 (PDT) Received: from [64.74.213.174] (port=2184 helo=RunningDog2) by wilson.nswebhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LtNe5-0008Rc-J8 for 6lowpan@ietf.org; Mon, 13 Apr 2009 10:00:26 -0500 Message-ID: <38532F0136A84A188E6A9ACCF03FF06D@RunningDog2> From: "Benjamin A. Rolfe" To: <6lowpan@ietf.org> References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com><49DFB1DB.3040602@gmail.com> <49E04284.6000900@sensinode.com><49E0880E.1030803@gmail.com> <49E08B3D.6030003@sensinode.com> <200904111748.n3BHm8Sw002704@kelsey-ws.hq.ember.com> Date: Mon, 13 Apr 2009 08:00:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] [Roll] 6lowpan-ND vs. ROLL 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: , X-List-Received-Date: Mon, 13 Apr 2009 14:59:18 -0000 This is very interesting and relevant question. In the scenario given, the utility side of the meter is likely a mesh also, and it needs to be isolated from the home side (we're using SUN and HAN to describe these two - Smart Utility Network and Home Area Network - in the context of 802.15.4 work). The general desire of the utility to maintain a secure SUN is one reason, and the general desire of consumers to keep their HAN private is another (and the general 'we don't want a ninth grader with a laptop crashing the grid' concern may figure in, too ;-). From either perspective the meter forms an "edge" from the point of view as entrance/egress between two logically separate networks. As pointed out, this is still a resource constrained device (although in some implementations it is has a bit more to play with than a typical thermostat or light dimmer). On the SUN side mesh the meter is keeping track only of it's adjacent neighbors; on the HAN there are likely fewer neighbors, in the home situation. But consider the same situation in an industrial context, where you have the same need for the in-prem network to be separated from the utility side, but the in-prem mesh might be thousands of nodes. I would expect again that the meter/gateway is keeping track only of adjacent neighbors. This is what we see happening now. Not sure if that helps in the discussion, so FWIW. -Ben ----- Original Message ----- From: "Richard Kelsey" To: Cc: <6lowpan@ietf.org> Sent: Saturday, April 11, 2009 10:48 AM Subject: Re: [6lowpan] [Roll] 6lowpan-ND vs. ROLL > Date: Sat, 11 Apr 2009 15:21:17 +0300 > From: Zach Shelby > > >>> Richard Kelsey a écrit : > >>>> From: Carsten Bormann Date: Fri, 10 Apr 2009 > >>>> 19:00:42 +0200 > >>>> > >>>> (I don't tend to think about the case where there is no Edge > >>>> Router -- ...) > >>>> > >>>> I have a question on this, stemming from my lack of familiarity > >>>> with the details of IP routing. > >>>> > >>>> Suppose I have a 6LowPAN/ROLL network being used for energy > >>>> management in a home. The network includes the electric meter, > >>>> which has a backhaul connection back to the utility. The utility, > >>>> being very protective of its backhaul network, has a firewall in > >>>> the meter to keep out everything except the utility's own > >>>> traffic. Given the presence of the firewall, does it still make > >>>> sense to use the meter as an Edge Router? > > [Is an Edge Router an IP router? ... Yes.] > > Anyways, this stuff doesn't need to be completely "typical". I mean we > are not installing an F-Secure firewall on a Windows PC here. These are > application-specific embedded devices most of the time. You can use an > embedded Linux box with Linux firewall features to achieve a 6LoWPAN > Edge Router. Of course the 6lowpan wireless interface driver and ER > features need to be implemented. > > In the network I was describing, the meter has no more > horsepower than the other devices on the network. It has a > small micro with around 4k of RAM. It certainly isn't > something as powerful as an embedded Linux box. Is it > unreasonable to expect it to act as an Edge Router? If not, > how should its connection between the LowPAN and the utility > backhaul be handled? > -Richard Kelsey > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From richard.kelsey@ember.com Mon Apr 13 09:29:15 2009 Return-Path: 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 805C73A6D99 for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 09:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Badj3XN+SXQK for <6lowpan@core3.amsl.com>; Mon, 13 Apr 2009 09:29:14 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id A80D83A6EA0 for <6lowpan@ietf.org>; Mon, 13 Apr 2009 09:29:14 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 12:31:11 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3DGUObd031696; Mon, 13 Apr 2009 12:30:24 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3DGUOhm031693; Mon, 13 Apr 2009 12:30:24 -0400 Date: Mon, 13 Apr 2009 12:30:24 -0400 Message-Id: <200904131630.n3DGUOhm031693@kelsey-ws.hq.ember.com> To: jhui@archrock.com In-reply-to: (message from Jonathan Hui on Mon, 13 Apr 2009 07:46:27 -0700) From: Richard Kelsey References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <78F9E848-A866-45C6-94ED-A5BC6F741F8B@archrock.com> <49E1C5A9.4060800@sensinode.com> <144E9B49-F3E7-4936-B3F2-01DFD8B75CF3@archrock.com> <200904131440.n3DEeTgj030665@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 13 Apr 2009 16:31:11.0568 (UTC) FILETIME=[419ADD00:01C9BC55] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Whiteboard + ER (Was 6LoWPAN vs. ROLL) 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: , X-List-Received-Date: Mon, 13 Apr 2009 16:29:15 -0000 From: Jonathan Hui Date: Mon, 13 Apr 2009 07:46:27 -0700 On Apr 13, 2009, at 7:40 AM, Richard Kelsey wrote: > Ouch. I have been worrying about where to find the space to > store one whiteboard and now there are two. Does the > whiteboard have to be on a LoWPAN device or can it be on > some other router reachable via a backhaul network? The 6LoWPAN ND model does support a Relay option. There's a question of whether or not there can be multiple Relay hops. If we did that, then this would start to look awfully close to DHCPv6. Given the limited RAM available on typical 6LoWPAN devices, it would be nice if the whiteboard could either be on a router reached via a backhaul network or stored in a distributed fashion on the LoWPAN itself. I am not familiar enough with the issues involved to have a sense of the possibilities or implications of either of these approaches. Both would seem to add significant complexity. -Richard Kelsey From pthubert@cisco.com Tue Apr 14 09:16:07 2009 Return-Path: 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 544823A6E45 for <6lowpan@core3.amsl.com>; Tue, 14 Apr 2009 09:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.855 X-Spam-Level: X-Spam-Status: No, score=-9.855 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYfXFlyVWCSe for <6lowpan@core3.amsl.com>; Tue, 14 Apr 2009 09:16:06 -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 8D2573A6E3E for <6lowpan@ietf.org>; Tue, 14 Apr 2009 09:15:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,186,1238976000"; d="scan'208";a="38282315" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2009 16:17:06 +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 n3EGH6Kc021448; Tue, 14 Apr 2009 18:17:06 +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 n3EGH6Dr022509; Tue, 14 Apr 2009 16:17:06 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 18:17:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 14 Apr 2009 18:16:59 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0748F82F@xmb-ams-337.emea.cisco.com> In-Reply-To: <38532F0136A84A188E6A9ACCF03FF06D@RunningDog2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] 6lowpan-ND vs. ROLL Thread-Index: Acm8SJvTyl8Dy9umQUSA00WASTHwRwA0oOGg References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com><49DFB1DB.3040602@gmail.com><49E04284.6000900@sensinode.com><49E0880E.1030803@gmail.com><49E08B3D.6030003@sensinode.com><200904111748.n3BHm8Sw002704@kelsey-ws.hq.ember.com> <38532F0136A84A188E6A9ACCF03FF06D@RunningDog2> From: "Pascal Thubert (pthubert)" To: "Benjamin A. Rolfe" , <6lowpan@ietf.org> X-OriginalArrivalTime: 14 Apr 2009 16:17:06.0084 (UTC) FILETIME=[7411FE40:01C9BD1C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6216; t=1239725826; x=1240589826; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20[Roll]=206lowpan-ND=20vs.=2 0ROLL |Sender:=20; bh=yeiDoz8Vlzk3+iP/CcDjHF+qw4lo/4e0WDZ18tvCJ5Y=; b=kFzqLkd4efJyhMm8HUlzABFSGYdyWCP1EsAKIiE3PEDYWUMF8O6N1gHbiS ee3+PKaBbtE7Koi7vszCdxO7U3lb1gT5ZTXNmEG1Lm/w7mE4D/EjOjefZr0r IpYetLWogk; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [6lowpan] [Roll] 6lowpan-ND vs. ROLL 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: , X-List-Received-Date: Tue, 14 Apr 2009 16:16:07 -0000 SGkgQmVuamFtaW46DQoNClNlZW1zIHRoYXQgdGhlIFNVTiBzaG91bGQgYmUgcHJvdGVjdGVkIGF0 IEwyIGFuZCB0aGUgSEFOIHdvdWxkIG5vdCBwb3NzZXNzIHRoZSBhcHByb3ByaWF0ZSBrZXlzLCBp cyB0aGF0IHJpZ2h0PyBJZiBzbyB0aGUgU1VOIGFuZCBIQU4gd291bGQgb3BlcmF0ZSBhcyAyIGRp ZmZlcmVudCBuZXR3b3JrcyBpbiBzaGlwIGluIHRoZSBuaWdodCB3b3VsZG4ndCB0aGV5PyANCg0K VGhhdCdzIGhvdyBJJ2QgZXhwZWN0IGl0IGluIHRoZSBpbmR1c3RyaWFsIHNwYWNlIHdpdGggMiBk aWZmZXJlbnQgcHJvZmlsZXMuIEluIGZpbmUgd2hhdCB3ZSBzZWUgaXMgdGhhdCB0aGUgc2VjdXJp dHkgcmVhbGx5IGRlZmluZXMgd2hhdCBhIFBBTiBpcyBhbmQgdGhlIG5ldHdvcmsgYm91bmRhcmll cy4NCg0KUGFzY2FsDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IDZsb3dw YW4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOjZsb3dwYW4tYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEJlbmphbWluIEEuIFJvbGZlDQo+U2VudDogbHVuZGkgMTMgYXZyaWwgMjAwOSAx NzowMA0KPlRvOiA2bG93cGFuQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFs2bG93cGFuXSBbUm9s bF0gNmxvd3Bhbi1ORCB2cy4gUk9MTA0KPg0KPlRoaXMgaXMgIHZlcnkgaW50ZXJlc3RpbmcgYW5k IHJlbGV2YW50IHF1ZXN0aW9uLg0KPkluIHRoZSBzY2VuYXJpbyBnaXZlbiwgdGhlIHV0aWxpdHkg c2lkZSBvZiB0aGUgbWV0ZXIgaXMgbGlrZWx5IGEgbWVzaCBhbHNvLA0KPmFuZCBpdCBuZWVkcyB0 byBiZSBpc29sYXRlZCBmcm9tIHRoZSBob21lIHNpZGUgKHdlJ3JlIHVzaW5nIFNVTiBhbmQgSEFO IHRvDQo+ZGVzY3JpYmUgdGhlc2UgdHdvIC0gU21hcnQgVXRpbGl0eSBOZXR3b3JrIGFuZCBIb21l IEFyZWEgTmV0d29yayAtIGluIHRoZQ0KPmNvbnRleHQgb2YgODAyLjE1LjQgd29yaykuICBUaGUg Z2VuZXJhbCBkZXNpcmUgb2YgdGhlIHV0aWxpdHkgdG8gbWFpbnRhaW4gYQ0KPnNlY3VyZSBTVU4g aXMgb25lIHJlYXNvbiwgYW5kIHRoZSBnZW5lcmFsIGRlc2lyZSBvZiBjb25zdW1lcnMgdG8ga2Vl cCB0aGVpcg0KPkhBTiBwcml2YXRlIGlzIGFub3RoZXIgKGFuZCB0aGUgZ2VuZXJhbCAnd2UgZG9u J3Qgd2FudCBhIG5pbnRoIGdyYWRlciB3aXRoIGENCj5sYXB0b3AgY3Jhc2hpbmcgdGhlIGdyaWQn IGNvbmNlcm4gbWF5IGZpZ3VyZSBpbiwgdG9vIDstKS4gICBGcm9tIGVpdGhlcg0KPnBlcnNwZWN0 aXZlIHRoZSBtZXRlciBmb3JtcyBhbiAiZWRnZSIgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBhcw0K PmVudHJhbmNlL2VncmVzcyBiZXR3ZWVuIHR3byBsb2dpY2FsbHkgc2VwYXJhdGUgbmV0d29ya3Mu IEFzIHBvaW50ZWQgb3V0LA0KPnRoaXMgaXMgc3RpbGwgYSByZXNvdXJjZSBjb25zdHJhaW5lZCBk ZXZpY2UgKGFsdGhvdWdoIGluIHNvbWUNCj5pbXBsZW1lbnRhdGlvbnMgaXQgaXMgaGFzIGEgYml0 IG1vcmUgdG8gcGxheSB3aXRoIHRoYW4gYSB0eXBpY2FsIHRoZXJtb3N0YXQNCj5vciBsaWdodCBk aW1tZXIpLg0KPg0KPk9uIHRoZSBTVU4gc2lkZSBtZXNoIHRoZSBtZXRlciBpcyBrZWVwaW5nIHRy YWNrIG9ubHkgb2YgaXQncyBhZGphY2VudA0KPm5laWdoYm9yczsgb24gdGhlIEhBTiB0aGVyZSBh cmUgbGlrZWx5IGZld2VyIG5laWdoYm9ycywgaW4gdGhlIGhvbWUNCj5zaXR1YXRpb24uIEJ1dCBj b25zaWRlciB0aGUgc2FtZSBzaXR1YXRpb24gaW4gYW4gaW5kdXN0cmlhbCBjb250ZXh0LCB3aGVy ZQ0KPnlvdSBoYXZlIHRoZSBzYW1lIG5lZWQgZm9yIHRoZSBpbi1wcmVtIG5ldHdvcmsgdG8gYmUg c2VwYXJhdGVkIGZyb20gdGhlDQo+dXRpbGl0eSBzaWRlLCBidXQgdGhlIGluLXByZW0gbWVzaCBt aWdodCBiZSB0aG91c2FuZHMgb2Ygbm9kZXMuICBJIHdvdWxkDQo+ZXhwZWN0IGFnYWluIHRoYXQg dGhlIG1ldGVyL2dhdGV3YXkgaXMga2VlcGluZyB0cmFjayBvbmx5IG9mIGFkamFjZW50DQo+bmVp Z2hib3JzLiAgIFRoaXMgaXMgd2hhdCB3ZSBzZWUgaGFwcGVuaW5nIG5vdy4NCj4NCj5Ob3Qgc3Vy ZSBpZiB0aGF0IGhlbHBzIGluIHRoZSBkaXNjdXNzaW9uLCBzbyBGV0lXLg0KPi1CZW4NCj4NCj4N Cj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+RnJvbTogIlJpY2hhcmQgS2Vsc2V5IiA8 cmljaGFyZC5rZWxzZXlAZW1iZXIuY29tPg0KPlRvOiA8emFjaEBzZW5zaW5vZGUuY29tPg0KPkNj OiA8Nmxvd3BhbkBpZXRmLm9yZz4NCj5TZW50OiBTYXR1cmRheSwgQXByaWwgMTEsIDIwMDkgMTA6 NDggQU0NCj5TdWJqZWN0OiBSZTogWzZsb3dwYW5dIFtSb2xsXSA2bG93cGFuLU5EIHZzLiBST0xM DQo+DQo+DQo+PiAgIERhdGU6IFNhdCwgMTEgQXByIDIwMDkgMTU6MjE6MTcgKzAzMDANCj4+ICAg RnJvbTogWmFjaCBTaGVsYnkgPHphY2hAc2Vuc2lub2RlLmNvbT4NCj4+DQo+PiAgID4+PiBSaWNo YXJkIEtlbHNleSBhIMOpY3JpdCA6DQo+PiAgID4+Pj4gRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIDxj YWJvQHR6aS5vcmc+IERhdGU6IEZyaSwgMTAgQXByIDIwMDkNCj4+ICAgPj4+PiAxOTowMDo0MiAr MDIwMA0KPj4gICA+Pj4+DQo+PiAgID4+Pj4gKEkgZG9uJ3QgdGVuZCB0byB0aGluayBhYm91dCB0 aGUgY2FzZSB3aGVyZSB0aGVyZSBpcyBubyBFZGdlDQo+PiAgID4+Pj4gUm91dGVyIC0tIC4uLikN Cj4+ICAgPj4+Pg0KPj4gICA+Pj4+IEkgaGF2ZSBhIHF1ZXN0aW9uIG9uIHRoaXMsIHN0ZW1taW5n IGZyb20gbXkgbGFjayBvZiBmYW1pbGlhcml0eQ0KPj4gICA+Pj4+IHdpdGggdGhlIGRldGFpbHMg b2YgSVAgcm91dGluZy4NCj4+ICAgPj4+Pg0KPj4gICA+Pj4+IFN1cHBvc2UgSSBoYXZlIGEgNkxv d1BBTi9ST0xMIG5ldHdvcmsgYmVpbmcgdXNlZCBmb3IgZW5lcmd5DQo+PiAgID4+Pj4gbWFuYWdl bWVudCBpbiBhIGhvbWUuICBUaGUgbmV0d29yayBpbmNsdWRlcyB0aGUgZWxlY3RyaWMgbWV0ZXIs DQo+PiAgID4+Pj4gd2hpY2ggaGFzIGEgYmFja2hhdWwgY29ubmVjdGlvbiBiYWNrIHRvIHRoZSB1 dGlsaXR5LiBUaGUgdXRpbGl0eSwNCj4+ICAgPj4+PiBiZWluZyB2ZXJ5IHByb3RlY3RpdmUgb2Yg aXRzIGJhY2toYXVsIG5ldHdvcmssIGhhcyBhIGZpcmV3YWxsIGluDQo+PiAgID4+Pj4gdGhlIG1l dGVyIHRvIGtlZXAgb3V0IGV2ZXJ5dGhpbmcgZXhjZXB0IHRoZSB1dGlsaXR5J3Mgb3duDQo+PiAg ID4+Pj4gdHJhZmZpYy4gICBHaXZlbiB0aGUgcHJlc2VuY2Ugb2YgdGhlIGZpcmV3YWxsLCBkb2Vz IGl0IHN0aWxsIG1ha2UNCj4+ICAgPj4+PiBzZW5zZSB0byB1c2UgdGhlIG1ldGVyIGFzIGFuIEVk Z2UgUm91dGVyPw0KPj4NCj4+ICAgW0lzIGFuIEVkZ2UgUm91dGVyIGFuIElQIHJvdXRlcj8gLi4u IFllcy5dDQo+Pg0KPj4gICBBbnl3YXlzLCB0aGlzIHN0dWZmIGRvZXNuJ3QgbmVlZCB0byBiZSBj b21wbGV0ZWx5ICJ0eXBpY2FsIi4gSSBtZWFuIHdlDQo+PiAgIGFyZSBub3QgaW5zdGFsbGluZyBh biBGLVNlY3VyZSBmaXJld2FsbCBvbiBhIFdpbmRvd3MgUEMgaGVyZS4gVGhlc2UgYXJlDQo+PiAg IGFwcGxpY2F0aW9uLXNwZWNpZmljIGVtYmVkZGVkIGRldmljZXMgbW9zdCBvZiB0aGUgdGltZS4g WW91IGNhbiB1c2UgYW4NCj4+ICAgZW1iZWRkZWQgTGludXggYm94IHdpdGggTGludXggZmlyZXdh bGwgZmVhdHVyZXMgdG8gYWNoaWV2ZSBhIDZMb1dQQU4NCj4+ICAgRWRnZSBSb3V0ZXIuIE9mIGNv dXJzZSB0aGUgNmxvd3BhbiB3aXJlbGVzcyBpbnRlcmZhY2UgZHJpdmVyIGFuZCBFUg0KPj4gICBm ZWF0dXJlcyBuZWVkIHRvIGJlIGltcGxlbWVudGVkLg0KPj4NCj4+IEluIHRoZSBuZXR3b3JrIEkg d2FzIGRlc2NyaWJpbmcsIHRoZSBtZXRlciBoYXMgbm8gbW9yZQ0KPj4gaG9yc2Vwb3dlciB0aGFu IHRoZSBvdGhlciBkZXZpY2VzIG9uIHRoZSBuZXR3b3JrLiAgSXQgaGFzIGENCj4+IHNtYWxsIG1p Y3JvIHdpdGggYXJvdW5kIDRrIG9mIFJBTS4gIEl0IGNlcnRhaW5seSBpc24ndA0KPj4gc29tZXRo aW5nIGFzIHBvd2VyZnVsIGFzIGFuIGVtYmVkZGVkIExpbnV4IGJveC4gIElzIGl0DQo+PiB1bnJl YXNvbmFibGUgdG8gZXhwZWN0IGl0IHRvIGFjdCBhcyBhbiBFZGdlIFJvdXRlcj8gIElmIG5vdCwN Cj4+IGhvdyBzaG91bGQgaXRzIGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUgTG93UEFOIGFuZCB0aGUg dXRpbGl0eQ0KPj4gYmFja2hhdWwgYmUgaGFuZGxlZD8NCj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC1SaWNoYXJkIEtlbHNleQ0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IDZsb3dwYW4gbWFpbGluZyBsaXN0DQo+PiA2bG93cGFu QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dw YW4NCj4+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj42bG93cGFuIG1haWxpbmcgbGlzdA0KPjZsb3dwYW5AaWV0Zi5vcmcNCj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4NCg== From robert.assimiti@nivis.com Mon Apr 20 16:15:16 2009 Return-Path: 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 BAB3B3A6B83 for <6lowpan@core3.amsl.com>; Mon, 20 Apr 2009 16:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 XyYkNUR6c3sO for <6lowpan@core3.amsl.com>; Mon, 20 Apr 2009 16:15:15 -0700 (PDT) Received: from mail.nivis.com (mail.nivis.com [65.205.163.229]) by core3.amsl.com (Postfix) with SMTP id 8D22F3A6953 for <6lowpan@ietf.org>; Mon, 20 Apr 2009 16:15:15 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C20E.09B63424" Date: Mon, 20 Apr 2009 19:16:26 -0400 Message-ID: In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0748F82F@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6loWPAN] 6loWPAN Design and Application Spaces for 6loWPANs - 02- thread-index: Acm8SJvTyl8Dy9umQUSA00WASTHwRwA0oOGgATxAMgA= References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com><49DFB1DB.3040602@gmail.com><49E04284.6000900@sensinode.com><49E0880E.1030803@gmail.com><49E08B3D.6030003@sensinode.com><200904111748.n3BHm8Sw002704@kelsey-ws.hq.ember.com><38532F0136A84A188E6A9ACCF03FF06D@RunningDog2> <7892795E1A87F04CADFCCF41FADD00FC0748F82F@xmb-ams-337.emea.cisco.com> From: "Robert Assimiti" To: <6lowpan@ietf.org> Subject: [6lowpan] [6loWPAN] 6loWPAN Design and Application Spaces for 6loWPANs - 02- 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: , X-List-Received-Date: Mon, 20 Apr 2009 23:15:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C20E.09B63424 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCiANCg0KSSB3YXMgZ29pbmcgb3ZlciB0aGUgc2Vjb25kIHNwaW4gb2YgRHJhZnQt SUVURi02bG93cGFuLXVzZXJjYXNlcy4NCg0KIA0KDQpJIGFtIGEgYml0IHVuY2xlYXIgb24gdGhl IGRlZmluaXRpb24gb2YgdGhlIExvV1BBTiBsaW5rLiBBIExvV1BBTiBMaW5rIGlzIGNvaW5lZCBh czoNCg0KIA0KDQrigJxBIGxvdy1wb3dlciB3aXJlbGVzcyBsaW5rIHdoaWNoIGlzIHNoYXJlZCBi eSBhIGxpbmstbG9jYWwgc2NvcGUgaW4gYSBMb1dQQU4uIEluIGEgTG9XUEFOLCBhIGxpbmsgY2Fu IGJlIGEgdmVyeSBpbnN0YWJsZSBzZXQgb2Ygbm9kZXMsIGZvciBpbnN0YW5jZSB0aGUgc2V0IG9m IG5vZGVzIHRoYXQgY2FuIHJlY2VpdmUgYSBwYWNrZXQNCg0KdGhhdCBpcyBicm9hZGNhc3Qgb3Zl ciB0aGUgYWlyIGluIGEgcm91dGUgb3ZlciBMb1dQQU4sIG9yIHRoZSBzZXQgb2Ygbm9kZXMgY3Vy cmVudGx5IHJlYWNoYWJsZSBpbiBhbiBMMiBtZXNoIGluIGEgbWVzaCB1bmRlciBMb1dQQU4uIFN1 Y2ggYSBzZXQgbWF5IHZhcnkgZnJvbSBvbmUgcGFja2V0IHRvIHRoZSBuZXh0IA0KDQphcyB0aGUg bm9kZXMgbW92ZSBvciBhcyB0aGUgcmFkaW8gcHJvcGFnYXRpb24gY29uZGl0aW9ucyBjaGFuZ2Uu 4oCdDQoNCiANCg0KSXQgaXMgY2xlYXIgdGhhdCB3ZSBhcmUgdGFyZ2V0aW5nIHBvaW50LXRvLXBv aW50IGFuZCBwb2ludC10by1tdWx0aXBvaW50IGhlcmUsIGJ1dCB0aGVyZSBpcyBub3RoaW5nIHRo YXQgaW5kaWNhdGVzIHRoZSBkaXJlY3Rpb25hbGl0eSBvZiB0aGUgbGluay4gDQoNCiANCg0KSXMg dGhlIGRlZmluaXRpb24gaGVyZSAoc2luY2UgaXQgaXMgYSB3aXJlbGVzcyBjb250ZXh0KSBjb25z aWRlcmVkIHVuaWRpcmVjdGlvbmFsIG9yIGJpLWRpcmVjdGlvbmFsPyANCg0KIA0KDQpBbHNvLCB0 aGUgZGVmaW5pdGlvbiBnaXZlbiBpbiBSRkM0ODYxIGRvZXMgbm90IHJlYWxseSBhcHBseSBoZXJl Lg0KDQogDQoNCiBUaGFua3MgZm9yIGFueW9uZSB0aGF0IGNvdWxkIG9mZmVyIGEgY2xhcmlmaWNh dGlvbi4NCg0KIA0KDQogDQoNCiANCg0KIlRoZSBuaWNlIHRoaW5nIGFib3V0IHN0YW5kYXJkcyBp cyB0aGF0IHRoZXJlIGFyZSBzbyBtYW55IHRvIGNob29zZSBmcm9tLiIgLSBBbmRyZXcgUy4gVGFu ZW5iYXVtIA0KDQpSb2JlcnQgQXNzaW1pdGkNCg0KRXhlY3V0aXZlIFN0YWZmIEVuZ2luZWVyDQoN Ck9mZmljZTogWzY3OF0tMjAyLTY4NTkNCg0KTW9iaWxlOiBbNDA0XS01NzgtMDIwNQ0KDQpyb2Jl cnQuYXNzaW1pdGlAbml2aXMuY29tDQoNCiANCg0KIA0KDQogDQoNCg0KDQpUaGlzIGUtbWFpbCAo aW5jbHVkaW5nIGFueSBhdHRhY2htZW50cyB0byBpdCkgaXMgY29uZmlkZW50aWFsLCBwcm9wcmll dGFyeSwgbGVnYWxseSBwcml2aWxlZ2VkLCBzdWJqZWN0IHRvIGNvcHlyaWdodCBhbmQgaXMgc2Vu dCBmb3IgdGhlIHBlcnNvbmFsIGF0dGVudGlvbiBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9u bHkuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2UgcmVw bHkgdG8gYWR2aXNlIHVzIGltbWVkaWF0ZWx5LCBkZWxldGUgaXQgYW5kIGRlc3Ryb3kgYW55IHBy aW50ZWQgY29waWVzIG9mIGl0LiBZb3UgYXJlIG5vdGlmaWVkIHRoYXQgcmVhZGluZywgZGlzY2xv c2luZywgY29weWluZywgZGlzdHJpYnV0aW5nIG9yIHRha2luZyBhbnkgYWN0aW9uIGluIHJlbGlh bmNlIG9uIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIE5vIGVtcGxveWVlIGlzIGF1dGhvcml6ZWQgdG8gY29uY2x1ZGUgYW55IGJpbmRpbmcg YWdyZWVtZW50IG9uIGJlaGFsZiBvZiBOSVZJUyBMTEMgd2l0aCBhbm90aGVyIHBhcnR5IGJ5IGUt bWFpbCB3aXRob3V0IGV4cHJlc3Mgd3JpdHRlbiBjb25maXJtYXRpb24gYnkgYW4gb2ZmaWNlciBv ZiB0aGUgY29tcGFueS4gQWx0aG91Z2ggd2UgaGF2ZSB0YWtlbiByZWFzb25hYmxlIHByZWNhdXRp b25zIHRvIGVuc3VyZSBubyB2aXJ1c2VzIGFyZSBwcmVzZW50IGluIHRoaXMgZS1tYWlsLCB3ZSBj YW5ub3QgYWNjZXB0IHJlc3BvbnNpYmlsaXR5IGZvciBhbnkgbG9zcyBvciBkYW1hZ2UgYXJpc2lu ZyBmcm9tIHRoZSB2aXJ1c2VzIGluIHRoaXMgZS1tYWlsIG9yIGF0dGFjaG1lbnRzLg0K ------_=_NextPart_001_01C9C20E.09B63424 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpEPSJE QVY6IiB4bWxuczptdD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3Nv YXAvbWVldGluZ3MvIiB4bWxuczp4Mj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvZXhjZWwvMjAwMy94bWwiIHhtbG5zOm9pcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9zaGFyZXBvaW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvc29hcC9kaXJlY3RvcnkvIiB4bWxuczpkcz0iaHR0cDovL3d3dy53 My5vcmcvMjAwMC8wOS94bWxkc2lnIyIgeG1sbnM6ZHNwPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvZHNwIiB4bWxuczp1ZGM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vZGF0YS91ZGMiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl bWEiIHhtbG5zOnN1Yj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3Nv YXAvMjAwMi8xL2FsZXJ0cy8iIHhtbG5zOmVjPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3ht bGVuYyMiIHhtbG5zOnNwPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQv IiB4bWxuczpzcHM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2Fw LyIgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIg eG1sbnM6dWRjcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9zb2FwIiB4 bWxuczp1ZGN4Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy94bWxmaWxl IiB4bWxuczp1ZGNwMnA9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0YS91ZGMvcGFy dHRvcGFydCIgeG1sbnM6d2Y9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL3dvcmtmbG93LyIgeG1sbnM6ZHNzcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9vZmZpY2UvMjAwNi9kaWdzaWctc2V0dXAiIHhtbG5zOmRzc2k9Imh0dHA6Ly9zY2hlbWFzLm1p Y3Jvc29mdC5jb20vb2ZmaWNlLzIwMDYvZGlnc2lnIiB4bWxuczptZHNzaT0iaHR0cDovL3NjaGVt YXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAwNi9kaWdpdGFsLXNpZ25hdHVyZSIgeG1s bnM6bXZlcj0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL21hcmt1cC1jb21wYXRp YmlsaXR5LzIwMDYiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNl LzIwMDQvMTIvb21tbCIgeG1sbnM6bXJlbHM9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRz Lm9yZy9wYWNrYWdlLzIwMDYvcmVsYXRpb25zaGlwcyIgeG1sbnM6c3B3cD0iaHR0cDovL21pY3Jv c29mdC5jb20vc2hhcmVwb2ludC93ZWJwYXJ0cGFnZXMiIHhtbG5zOmV4MTJ0PSJodHRwOi8vc2No ZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYvdHlwZXMiIHhtbG5zOmV4 MTJtPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYv bWVzc2FnZXMiIHhtbG5zOnBwdHNsPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJl cG9pbnQvc29hcC9TbGlkZUxpYnJhcnkvIiB4bWxuczpzcHNsPSJodHRwOi8vbWljcm9zb2Z0LmNv bS93ZWJzZXJ2aWNlcy9TaGFyZVBvaW50UG9ydGFsU2VydmVyL1B1Ymxpc2hlZExpbmtzU2Vydmlj ZSIgeG1sbnM6Wj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbToiIHhtbG5zOnN0PSImIzE7IiB4 bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEg aHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04 Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0 ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQog QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjIgNyA0IDkgMiAy IDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N CiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiMxN0JCRkQ7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiNG Rjc5QzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRl eHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFn ZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGlu az0iIzE3QkJGRCIgdmxpbms9IiNGRjc5QzIiPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+SGVsbG8sPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+SQ0Kd2FzIGdvaW5nIG92 ZXIgdGhlIHNlY29uZCBzcGluIG9mIERyYWZ0LUlFVEYtNmxvd3Bhbi11c2VyY2FzZXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+ SQ0KYW0gYSBiaXQgdW5jbGVhciBvbiB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgTG9XUEFOIGxpbmsu IEEgTG9XUEFOIExpbmsgaXMgY29pbmVkDQphczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PGk+4oCc PC9pPjxpPkEgbG93LXBvd2VyIHdpcmVsZXNzDQpsaW5rIHdoaWNoIGlzIHNoYXJlZCBieSBhIGxp bmstbG9jYWwgc2NvcGUgaW4gYSBMb1dQQU4uIEluIGEgTG9XUEFOLCBhIGxpbmsgY2FuDQpiZSBh IHZlcnkgaW5zdGFibGUgc2V0IG9mIG5vZGVzLCBmb3IgaW5zdGFuY2UgdGhlIHNldCBvZiBub2Rl cyB0aGF0IGNhbiByZWNlaXZlDQphIHBhY2tldDxvOnA+PC9vOnA+PC9pPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48aT50aGF0IGlzIGJyb2Fk Y2FzdCBvdmVyIHRoZQ0KYWlyIGluIGEgcm91dGUgb3ZlciBMb1dQQU4sIG9yIHRoZSBzZXQgb2Yg bm9kZXMgY3VycmVudGx5IHJlYWNoYWJsZSBpbiBhbiBMMg0KbWVzaCBpbiBhIG1lc2ggdW5kZXIg TG9XUEFOLiBTdWNoIGEgc2V0IG1heSB2YXJ5IGZyb20gb25lIHBhY2tldCB0byB0aGUgbmV4dCA8 bzpwPjwvbzpwPjwvaT48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRv c3BhY2U6bm9uZSc+PGk+YXMgdGhlIG5vZGVzIG1vdmUgb3IgYXMgdGhlDQpyYWRpbyBwcm9wYWdh dGlvbiBjb25kaXRpb25zIGNoYW5nZS7igJ08bzpwPjwvbzpwPjwvaT48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5JdA0KaXMgY2xlYXIgdGhhdCB3ZSBhcmUgdGFy Z2V0aW5nIHBvaW50LXRvLXBvaW50IGFuZCBwb2ludC10by1tdWx0aXBvaW50IGhlcmUsIGJ1dA0K dGhlcmUgaXMgbm90aGluZyB0aGF0IGluZGljYXRlcyB0aGUgZGlyZWN0aW9uYWxpdHkgb2YgdGhl IGxpbmsuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiInPklzDQp0aGUgZGVmaW5pdGlvbiBoZXJlIChzaW5jZSBpdCBpcyBhIHdpcmVs ZXNzIGNvbnRleHQpIGNvbnNpZGVyZWQgdW5pZGlyZWN0aW9uYWwNCm9yIGJpLWRpcmVjdGlvbmFs PyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiJz5BbHNvLA0KdGhlIGRlZmluaXRpb24gZ2l2ZW4gaW4gUkZDNDg2MSBkb2VzIG5vdCBy ZWFsbHkgYXBwbHkgaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz7CoFRoYW5rcw0KZm9yIGFueW9uZSB0aGF0IGNvdWxkIG9m ZmVyIGEgY2xhcmlmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzAwMzQ5RSc+ JnF1b3Q7VGhlIG5pY2UgdGhpbmcgYWJvdXQgc3RhbmRhcmRzIGlzIHRoYXQgdGhlcmUgYXJlIHNv IG1hbnkNCnRvIGNob29zZSBmcm9tLiZxdW90OyAtIEFuZHJldyBTLiBUYW5lbmJhdW0gPG86cD48 L286cD48L3NwYW4+PC9iPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjojMDAzNDlFJz5Sb2JlcnQgQXNzaW1pdGk8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMwMDM0OUUnPkV4 ZWN1dGl2ZSBTdGFmZiZuYnNwO0VuZ2luZWVyPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCg0K PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMDAzNDlFJz5PZmZpY2U6 IFs2NzhdLTIwMi02ODU5PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCg0KPHAgY2xhc3M9TXNv UGxhaW5UZXh0PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMDAzNDlFJz5Nb2JpbGU6IFs0MDRdLTU3OC0w MjA1PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxi PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQpjb2xvcjojMDAzNDlFJz5yb2JlcnQuYXNzaW1pdGlAbml2aXMuY29tPG86cD48 L286cD48L3NwYW4+PC9iPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjxESVY+Jm5ic3A7PC9ESVY+PGJyPjxicj5UaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBh dHRhY2htZW50cyB0byBpdCkgaXMgY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSwgbGVnYWxseSBw cml2aWxlZ2VkLCBzdWJqZWN0IHRvIGNvcHlyaWdodCBhbmQgaXMgc2VudCBmb3IgdGhlIHBlcnNv bmFsIGF0dGVudGlvbiBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9ubHkuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2UgcmVwbHkgdG8gYWR2aXNlIHVz IGltbWVkaWF0ZWx5LCBkZWxldGUgaXQgYW5kIGRlc3Ryb3kgYW55IHByaW50ZWQgY29waWVzIG9m IGl0LiBZb3UgYXJlIG5vdGlmaWVkIHRoYXQgcmVhZGluZywgZGlzY2xvc2luZywgY29weWluZywg ZGlzdHJpYnV0aW5nIG9yIHRha2luZyBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIG9uIHRoZSBjb250 ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIE5vIGVtcGxv eWVlIGlzIGF1dGhvcml6ZWQgdG8gY29uY2x1ZGUgYW55IGJpbmRpbmcgYWdyZWVtZW50IG9uIGJl aGFsZiBvZiBOSVZJUyBMTEMgd2l0aCBhbm90aGVyIHBhcnR5IGJ5IGUtbWFpbCB3aXRob3V0IGV4 cHJlc3Mgd3JpdHRlbiBjb25maXJtYXRpb24gYnkgYW4gb2ZmaWNlciBvZiB0aGUgY29tcGFueS4g QWx0aG91Z2ggd2UgaGF2ZSB0YWtlbiByZWFzb25hYmxlIHByZWNhdXRpb25zIHRvIGVuc3VyZSBu byB2aXJ1c2VzIGFyZSBwcmVzZW50IGluIHRoaXMgZS1tYWlsLCB3ZSBjYW5ub3QgYWNjZXB0IHJl c3BvbnNpYmlsaXR5IGZvciBhbnkgbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB2aXJ1 c2VzIGluIHRoaXMgZS1tYWlsIG9yIGF0dGFjaG1lbnRzLjwvYm9keT4NCg0KPC9odG1sPg0KDQo= ------_=_NextPart_001_01C9C20E.09B63424-- From alexandru.petrescu@gmail.com Wed Apr 22 08:11:38 2009 Return-Path: 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 5ED653A6921 for <6lowpan@core3.amsl.com>; Wed, 22 Apr 2009 08:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-gJ4X2UmRAm for <6lowpan@core3.amsl.com>; Wed, 22 Apr 2009 08:11:37 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 32FB53A6CE0 for <6lowpan@ietf.org>; Wed, 22 Apr 2009 08:11:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3MFAbqE013479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Apr 2009 17:10:37 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3MFCeQL031588; Wed, 22 Apr 2009 17:12:40 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3MFCdRP021564; Wed, 22 Apr 2009 17:12:40 +0200 Message-ID: <49EF33E7.50008@gmail.com> Date: Wed, 22 Apr 2009 17:12:39 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Robert Assimiti References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com><49DFB1DB.3040602@gmail.com><49E04284.6000900@sensinode.com><49E0880E.1030803@gmail.com><49E08B3D.6030003@sensinode.com><200904111748.n3BHm8Sw002704@kelsey-ws.hq.ember.com><38532F0136A84A188E6A9ACCF03FF06D@RunningDog2> <7892795E1A87F04CADFCCF41FADD00FC0748F82F@xmb-ams-337.emea.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [6loWPAN] 6loWPAN Design and Application Spaces for 6loWPANs - 02- 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: , X-List-Received-Date: Wed, 22 Apr 2009 15:11:38 -0000 Hi Robert, let me give my oppinion on this. Robert Assimiti a écrit : > Hello, > > I was going over the second spin of Draft-IETF-6lowpan-usercases. > > I am a bit unclear on the definition of the LoWPAN link. A LoWPAN Link > is coined as: > > /“//A low-power wireless link which is shared by a link-local scope in a > LoWPAN. In a LoWPAN, a link can be a very instable set of nodes, for > instance the set of nodes that can receive a packet/ > /that is broadcast over the air in a route over LoWPAN, or the set of > nodes currently reachable in an L2 mesh in a mesh under LoWPAN. Such a > set may vary from one packet to the next / > /as the nodes move or as the radio propagation conditions change.â€/ > > It is clear that we are targeting point-to-point and point-to-multipoint > here, but there is nothing that indicates the directionality of the link. I am not sure what you mean being clear we're targetting ptp and pt-to-mpt links... I am aware ROLL WG targets the point-to-multipoint types of traffic (not the links). I think 802.15.4 link may be a point-to-point link, or a 'star' topology, which one may interpret as being a point-to-multipoint link. Whereas I understand very well running IP over a point-to-point link, I don't see how would it run over a point-to-multipoint link, never saw this before. As for the link-local scope mentioned in the paragraph above, I think it comes from what a "link-local scope" is for link like an Ethernet link. But, it is not clear at all what a link-local scope would be on a 802.15.4 star topology made of a point-to-multipoint link: would a packet sent by the center reach all edges? Or only one? Would a packet from an edge to another have a dst address the center or the edge? Two dst addresses? I prefer to think that a LoWPAN subnet is covered by an IP link-local scope, has at least one single IPv6 subnet prefix; and that IP packets addressed to a link-local IPv6 address reaches all nodes in the LoWPAN, without being 'IP-forwarded'. If such LoWPAN subnet sit on a 802.15.4 link then that 802.15.4 link should offer link-layer multicast support to the LoWPAN subnet, such that the words "link-local scope" to have a meaning for a 802.15.4-based LoWPAN. This is not the case today. > Is the definition here (since it is a wireless context) considered > unidirectional or bi-directional? This is a good question. I do suppose 6LoWPAN WG uses links which are bidirectional and symmetric. Alex > > > > Also, the definition given in RFC4861 does not really apply here. > > > > Thanks for anyone that could offer a clarification. > > > > > > > > *"The nice thing about standards is that there are so many to choose > from." - Andrew S. Tanenbaum * > > *Robert Assimiti* > > *Executive Staff Engineer* > > *Office: [678]-202-6859* > > *Mobile: [404]-578-0205* > > *robert.assimiti@nivis.com* > > > > > > > > > > > This e-mail (including any attachments to it) is confidential, > proprietary, legally privileged, subject to copyright and is sent for > the personal attention of the intended recipient only. If you have > received this e-mail in error, please reply to advise us immediately, > delete it and destroy any printed copies of it. You are notified that > reading, disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited. No > employee is authorized to conclude any binding agreement on behalf of > NIVIS LLC with another party by e-mail without express written > confirmation by an officer of the company. Although we have taken > reasonable precautions to ensure no viruses are present in this e-mail, > we cannot accept responsibility for any loss or damage arising from the > viruses in this e-mail or attachments. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From robert.assimiti@nivis.com Wed Apr 22 13:18:33 2009 Return-Path: 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 3BF9528C27C for <6lowpan@core3.amsl.com>; Wed, 22 Apr 2009 13:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZeNXTQxn1Uf for <6lowpan@core3.amsl.com>; Wed, 22 Apr 2009 13:18:32 -0700 (PDT) Received: from mail.nivis.com (mail.nivis.com [65.205.163.229]) by core3.amsl.com (Postfix) with SMTP id F41A83A6DEC for <6lowpan@ietf.org>; Wed, 22 Apr 2009 13:18:31 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 22 Apr 2009 16:19:44 -0400 Message-ID: In-Reply-To: <49EF33E7.50008@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6loWPAN] 6loWPAN Design and Application Spaces for 6loWPANs - 02- thread-index: AcnDXMo9lhSuXQxZRRGmUu7C6DaPaAAKlfyg References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com><49DFB1DB.3040602@gmail.com><49E04284.6000900@sensinode.com><49E0880E.1030803@gmail.com><49E08B3D.6030003@sensinode.com><200904111748.n3BHm8Sw002704@kelsey-ws.hq.ember.com><38532F0136A84A188E6A9ACCF03FF06D@RunningDog2> <7892795E1A87F04CADFCCF41FADD00FC0748F82F@xmb-ams-337.emea.cisco.com> <49EF33E7.50008@gmail.com> From: "Robert Assimiti" To: "Alexandru Petrescu" Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [6loWPAN] 6loWPAN Design and Application Spaces for 6loWPANs - 02- 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: , X-List-Received-Date: Wed, 22 Apr 2009 20:18:33 -0000 SGVsbG8gQWxleC4gSSB0aGluayB0aGlzIGRlZmluaXRpb24gbmVlZHMgdG8gYmUgcmV2aXNlZCBp biBvcmRlciB0byBhY2NvbW1vZGF0ZSBub3Qgb25seSB0aGUgY29udGV4dCBvZiBhIDgwMi4xNS40 IFBBTiBidXQgYWxzbyB0aGUgY29udGV4dCBvZiB3aXJlbGVzcyBzdWJuZXRzIGluIGdlbmVyYWwu DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWxleGFuZHJ1IFBldHJl c2N1IFttYWlsdG86YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbV0gDQpTZW50OiBXZWRuZXNk YXksIEFwcmlsIDIyLCAyMDA5IDExOjEzIEFNDQpUbzogUm9iZXJ0IEFzc2ltaXRpDQpDYzogNmxv d3BhbkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFs2bG9XUEFOXSA2bG9XUEFOIERlc2lnbiBhbmQg QXBwbGljYXRpb24gU3BhY2VzIGZvciA2bG9XUEFOcyAtIDAyLQ0KDQpIaSBSb2JlcnQsIGxldCBt ZSBnaXZlIG15IG9wcGluaW9uIG9uIHRoaXMuDQoNClJvYmVydCBBc3NpbWl0aSBhIMOpY3JpdCA6 DQo+IEhlbGxvLA0KPiANCj4gSSB3YXMgZ29pbmcgb3ZlciB0aGUgc2Vjb25kIHNwaW4gb2YgRHJh ZnQtSUVURi02bG93cGFuLXVzZXJjYXNlcy4NCj4gDQo+IEkgYW0gYSBiaXQgdW5jbGVhciBvbiB0 aGUgZGVmaW5pdGlvbiBvZiB0aGUgTG9XUEFOIGxpbmsuIEEgTG9XUEFOIExpbmsgDQo+IGlzIGNv aW5lZCBhczoNCj4gDQo+IC/igJwvL0EgbG93LXBvd2VyIHdpcmVsZXNzIGxpbmsgd2hpY2ggaXMg c2hhcmVkIGJ5IGEgbGluay1sb2NhbCBzY29wZSBpbiBhIA0KPiBMb1dQQU4uIEluIGEgTG9XUEFO LCBhIGxpbmsgY2FuIGJlIGEgdmVyeSBpbnN0YWJsZSBzZXQgb2Ygbm9kZXMsIGZvciANCj4gaW5z dGFuY2UgdGhlIHNldCBvZiBub2RlcyB0aGF0IGNhbiByZWNlaXZlIGEgcGFja2V0Lw0KPiAvdGhh dCBpcyBicm9hZGNhc3Qgb3ZlciB0aGUgYWlyIGluIGEgcm91dGUgb3ZlciBMb1dQQU4sIG9yIHRo ZSBzZXQgb2YgDQo+IG5vZGVzIGN1cnJlbnRseSByZWFjaGFibGUgaW4gYW4gTDIgbWVzaCBpbiBh IG1lc2ggdW5kZXIgTG9XUEFOLiBTdWNoIGEgDQo+IHNldCBtYXkgdmFyeSBmcm9tIG9uZSBwYWNr ZXQgdG8gdGhlIG5leHQgLw0KPiAvYXMgdGhlIG5vZGVzIG1vdmUgb3IgYXMgdGhlIHJhZGlvIHBy b3BhZ2F0aW9uIGNvbmRpdGlvbnMgY2hhbmdlLuKAnS8NCj4gDQo+IEl0IGlzIGNsZWFyIHRoYXQg d2UgYXJlIHRhcmdldGluZyBwb2ludC10by1wb2ludCBhbmQgcG9pbnQtdG8tbXVsdGlwb2ludCAN Cj4gaGVyZSwgYnV0IHRoZXJlIGlzIG5vdGhpbmcgdGhhdCBpbmRpY2F0ZXMgdGhlIGRpcmVjdGlv bmFsaXR5IG9mIHRoZSBsaW5rLg0KDQpJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYmVpbmcg Y2xlYXIgd2UncmUgdGFyZ2V0dGluZyBwdHAgYW5kIA0KcHQtdG8tbXB0IGxpbmtzLi4uDQoNCkkg YW0gYXdhcmUgUk9MTCBXRyB0YXJnZXRzIHRoZSBwb2ludC10by1tdWx0aXBvaW50IHR5cGVzIG9m IHRyYWZmaWMgKG5vdCANCnRoZSBsaW5rcykuDQoNCkkgdGhpbmsgODAyLjE1LjQgbGluayBtYXkg YmUgYSBwb2ludC10by1wb2ludCBsaW5rLCBvciBhICdzdGFyJyANCnRvcG9sb2d5LCB3aGljaCBv bmUgbWF5IGludGVycHJldCBhcyBiZWluZyBhIHBvaW50LXRvLW11bHRpcG9pbnQgbGluay4NCg0K V2hlcmVhcyBJIHVuZGVyc3RhbmQgdmVyeSB3ZWxsIHJ1bm5pbmcgSVAgb3ZlciBhIHBvaW50LXRv LXBvaW50IGxpbmssIEkgDQpkb24ndCBzZWUgaG93IHdvdWxkIGl0IHJ1biBvdmVyIGEgcG9pbnQt dG8tbXVsdGlwb2ludCBsaW5rLCBuZXZlciBzYXcgDQp0aGlzIGJlZm9yZS4NCg0KQXMgZm9yIHRo ZSBsaW5rLWxvY2FsIHNjb3BlIG1lbnRpb25lZCBpbiB0aGUgcGFyYWdyYXBoIGFib3ZlLCBJIHRo aW5rIGl0IA0KY29tZXMgZnJvbSB3aGF0IGEgImxpbmstbG9jYWwgc2NvcGUiIGlzIGZvciBsaW5r IGxpa2UgYW4gRXRoZXJuZXQgbGluay4gDQogIEJ1dCwgaXQgaXMgbm90IGNsZWFyIGF0IGFsbCB3 aGF0IGEgbGluay1sb2NhbCBzY29wZSB3b3VsZCBiZSBvbiBhIA0KODAyLjE1LjQgc3RhciB0b3Bv bG9neSBtYWRlIG9mIGEgcG9pbnQtdG8tbXVsdGlwb2ludCBsaW5rOiB3b3VsZCBhIA0KcGFja2V0 IHNlbnQgYnkgdGhlIGNlbnRlciByZWFjaCBhbGwgZWRnZXM/ICBPciBvbmx5IG9uZT8gIFdvdWxk IGEgcGFja2V0IA0KZnJvbSBhbiBlZGdlIHRvIGFub3RoZXIgaGF2ZSBhIGRzdCBhZGRyZXNzIHRo ZSBjZW50ZXIgb3IgdGhlIGVkZ2U/ICBUd28gDQpkc3QgYWRkcmVzc2VzPw0KDQpJIHByZWZlciB0 byB0aGluayB0aGF0IGEgTG9XUEFOIHN1Ym5ldCBpcyBjb3ZlcmVkIGJ5IGFuIElQIGxpbmstbG9j YWwgDQpzY29wZSwgaGFzIGF0IGxlYXN0IG9uZSBzaW5nbGUgSVB2NiBzdWJuZXQgcHJlZml4OyBh bmQgdGhhdCBJUCBwYWNrZXRzIA0KYWRkcmVzc2VkIHRvIGEgbGluay1sb2NhbCBJUHY2IGFkZHJl c3MgcmVhY2hlcyBhbGwgbm9kZXMgaW4gdGhlIExvV1BBTiwgDQp3aXRob3V0IGJlaW5nICdJUC1m b3J3YXJkZWQnLg0KDQpJZiBzdWNoIExvV1BBTiBzdWJuZXQgc2l0IG9uIGEgODAyLjE1LjQgbGlu ayB0aGVuIHRoYXQgODAyLjE1LjQgbGluayANCnNob3VsZCBvZmZlciBsaW5rLWxheWVyIG11bHRp Y2FzdCBzdXBwb3J0IHRvIHRoZSBMb1dQQU4gc3VibmV0LCBzdWNoIA0KdGhhdCB0aGUgd29yZHMg ImxpbmstbG9jYWwgc2NvcGUiIHRvIGhhdmUgYSBtZWFuaW5nIGZvciBhIDgwMi4xNS40LWJhc2Vk IA0KTG9XUEFOLiAgVGhpcyBpcyBub3QgdGhlIGNhc2UgdG9kYXkuDQoNCj4gSXMgdGhlIGRlZmlu aXRpb24gaGVyZSAoc2luY2UgaXQgaXMgYSB3aXJlbGVzcyBjb250ZXh0KSBjb25zaWRlcmVkIA0K PiB1bmlkaXJlY3Rpb25hbCBvciBiaS1kaXJlY3Rpb25hbD8NCg0KVGhpcyBpcyBhIGdvb2QgIHF1 ZXN0aW9uLiAgSSBkbyBzdXBwb3NlIDZMb1dQQU4gV0cgdXNlcyBsaW5rcyB3aGljaCBhcmUgDQpi aWRpcmVjdGlvbmFsIGFuZCBzeW1tZXRyaWMuDQoNCkFsZXgNCg0KPiANCj4gIA0KPiANCj4gQWxz bywgdGhlIGRlZmluaXRpb24gZ2l2ZW4gaW4gUkZDNDg2MSBkb2VzIG5vdCByZWFsbHkgYXBwbHkg aGVyZS4NCj4gDQo+ICANCj4gDQo+ICBUaGFua3MgZm9yIGFueW9uZSB0aGF0IGNvdWxkIG9mZmVy IGEgY2xhcmlmaWNhdGlvbi4NCj4gDQo+ICANCj4gDQo+ICANCj4gDQo+ICANCj4gDQo+ICoiVGhl IG5pY2UgdGhpbmcgYWJvdXQgc3RhbmRhcmRzIGlzIHRoYXQgdGhlcmUgYXJlIHNvIG1hbnkgdG8g Y2hvb3NlIA0KPiBmcm9tLiIgLSBBbmRyZXcgUy4gVGFuZW5iYXVtICoNCj4gDQo+ICpSb2JlcnQg QXNzaW1pdGkqDQo+IA0KPiAqRXhlY3V0aXZlIFN0YWZmIEVuZ2luZWVyKg0KPiANCj4gKk9mZmlj ZTogWzY3OF0tMjAyLTY4NTkqDQo+IA0KPiAqTW9iaWxlOiBbNDA0XS01NzgtMDIwNSoNCj4gDQo+ ICpyb2JlcnQuYXNzaW1pdGlAbml2aXMuY29tKg0KPiANCj4gIA0KPiANCj4gIA0KPiANCj4gIA0K PiANCj4gIA0KPiANCj4gDQo+IFRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRz IHRvIGl0KSBpcyBjb25maWRlbnRpYWwsIA0KPiBwcm9wcmlldGFyeSwgbGVnYWxseSBwcml2aWxl Z2VkLCBzdWJqZWN0IHRvIGNvcHlyaWdodCBhbmQgaXMgc2VudCBmb3IgDQo+IHRoZSBwZXJzb25h bCBhdHRlbnRpb24gb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvbmx5LiBJZiB5b3UgaGF2ZSAN Cj4gcmVjZWl2ZWQgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSByZXBseSB0byBhZHZpc2Ug dXMgaW1tZWRpYXRlbHksIA0KPiBkZWxldGUgaXQgYW5kIGRlc3Ryb3kgYW55IHByaW50ZWQgY29w aWVzIG9mIGl0LiBZb3UgYXJlIG5vdGlmaWVkIHRoYXQgDQo+IHJlYWRpbmcsIGRpc2Nsb3Npbmcs IGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvciB0YWtpbmcgYW55IGFjdGlvbiBpbiANCj4gcmVsaWFu Y2Ugb24gdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4gTm8gDQo+IGVtcGxveWVlIGlzIGF1dGhvcml6ZWQgdG8gY29uY2x1ZGUgYW55IGJpbmRp bmcgYWdyZWVtZW50IG9uIGJlaGFsZiBvZiANCj4gTklWSVMgTExDIHdpdGggYW5vdGhlciBwYXJ0 eSBieSBlLW1haWwgd2l0aG91dCBleHByZXNzIHdyaXR0ZW4gDQo+IGNvbmZpcm1hdGlvbiBieSBh biBvZmZpY2VyIG9mIHRoZSBjb21wYW55LiBBbHRob3VnaCB3ZSBoYXZlIHRha2VuIA0KPiByZWFz b25hYmxlIHByZWNhdXRpb25zIHRvIGVuc3VyZSBubyB2aXJ1c2VzIGFyZSBwcmVzZW50IGluIHRo aXMgZS1tYWlsLCANCj4gd2UgY2Fubm90IGFjY2VwdCByZXNwb25zaWJpbGl0eSBmb3IgYW55IGxv c3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgDQo+IHZpcnVzZXMgaW4gdGhpcyBlLW1haWwg b3IgYXR0YWNobWVudHMuDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA2bG93cGFuIG1haWxp bmcgbGlzdA0KPiA2bG93cGFuQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vNmxvd3Bhbg0KDQoNCg0KDQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBh dHRhY2htZW50cyB0byBpdCkgaXMgY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSwgbGVnYWxseSBw cml2aWxlZ2VkLCBzdWJqZWN0IHRvIGNvcHlyaWdodCBhbmQgaXMgc2VudCBmb3IgdGhlIHBlcnNv bmFsIGF0dGVudGlvbiBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9ubHkuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2UgcmVwbHkgdG8gYWR2aXNlIHVz IGltbWVkaWF0ZWx5LCBkZWxldGUgaXQgYW5kIGRlc3Ryb3kgYW55IHByaW50ZWQgY29waWVzIG9m IGl0LiBZb3UgYXJlIG5vdGlmaWVkIHRoYXQgcmVhZGluZywgZGlzY2xvc2luZywgY29weWluZywg ZGlzdHJpYnV0aW5nIG9yIHRha2luZyBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIG9uIHRoZSBjb250 ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIE5vIGVtcGxv eWVlIGlzIGF1dGhvcml6ZWQgdG8gY29uY2x1ZGUgYW55IGJpbmRpbmcgYWdyZWVtZW50IG9uIGJl aGFsZiBvZiBOSVZJUyBMTEMgd2l0aCBhbm90aGVyIHBhcnR5IGJ5IGUtbWFpbCB3aXRob3V0IGV4 cHJlc3Mgd3JpdHRlbiBjb25maXJtYXRpb24gYnkgYW4gb2ZmaWNlciBvZiB0aGUgY29tcGFueS4g QWx0aG91Z2ggd2UgaGF2ZSB0YWtlbiByZWFzb25hYmxlIHByZWNhdXRpb25zIHRvIGVuc3VyZSBu byB2aXJ1c2VzIGFyZSBwcmVzZW50IGluIHRoaXMgZS1tYWlsLCB3ZSBjYW5ub3QgYWNjZXB0IHJl c3BvbnNpYmlsaXR5IGZvciBhbnkgbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB2aXJ1 c2VzIGluIHRoaXMgZS1tYWlsIG9yIGF0dGFjaG1lbnRzLg0K From alexandru.petrescu@gmail.com Thu Apr 23 06:51:26 2009 Return-Path: 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 F330F3A6AF4 for <6lowpan@core3.amsl.com>; Thu, 23 Apr 2009 06:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqaC+5Hs-Y8j for <6lowpan@core3.amsl.com>; Thu, 23 Apr 2009 06:51:24 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 70AB03A67F8 for <6lowpan@ietf.org>; Thu, 23 Apr 2009 06:51:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3NDqe0Q012712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Apr 2009 15:52:40 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3NDqe7G011086; Thu, 23 Apr 2009 15:52:40 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3NDqeLU023220; Thu, 23 Apr 2009 15:52:40 +0200 Message-ID: <49F072A8.1050706@gmail.com> Date: Thu, 23 Apr 2009 15:52:40 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Robert Assimiti References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com><49DFB1DB.3040602@gmail.com><49E04284.6000900@sensinode.com><49E0880E.1030803@gmail.com><49E08B3D.6030003@sensinode.com><200904111748.n3BHm8Sw002704@kelsey-ws.hq.ember.com><38532F0136A84A188E6A9ACCF03FF06D@RunningDog2> <7892795E1A87F04CADFCCF41FADD00FC0748F82F@xmb-ams-337.emea.cisco.com> <49EF33E7.50008@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [6loWPAN] 6loWPAN Design and Application Spaces for 6loWPANs - 02- 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: , X-List-Received-Date: Thu, 23 Apr 2009 13:51:26 -0000 Robert Assimiti a écrit : > Hello Alex. I think this definition needs to be revised in order to > accommodate not only the context of a 802.15.4 PAN but also the > context of wireless subnets in general. I agree. The definition in question is the following: > LoWPAN Link > > A low-power wireless link which is shared by a link-local scope in > a LoWPAN. In a LoWPAN, a link can be a very instable set of > nodes, for instance the set of nodes that can receive a packet > that is broadcast over the air in a route over LoWPAN, or the set > of nodes currently reachable in an L2 mesh in a mesh under LoWPAN. > Such a set may vary from one packet to the next as the nodes move > or as the radio propagation conditions change. At least the formulation "link shared by a link-local scope" is confusing. Maybe a "link connecting nodes which are part of the same link-local scope"(?) Then it says "broadcast over the air in a route over LoWPAN" which is less understandable again... Then there are more definitions which are less understandable. The Route Over is some of the less clear: > Mesh Under > > A LoWPAN configuration where the link-local scope is defined by > the boundaries of the LoWPAN and includes all nodes within. > Forwarding and multihop routing functions are achieved at L2 > between mesh nodes. > > Route Over > > A LoWPAN configuration where the link-local scope is defined by > those nodes reachable over a single radio transmission. What is a single radio transmission? Is it that non-link-local scope implies several radio transmissions? > Due to the time-varying characteristics of wireless communication, > the neighbor set may change over time even when nodes maintain the > same physical locations. Excuse-me but I really don't understand this: time-varying characteristics of wireless communications - do you mean TDD? > Route Over [...] Multihop is achieved using IP routing. Multihop with IP routing means also that the router forwards between two different links (each with its own link-local scope). However, the "Route Over" definition above uses a single link-local scope. I'll write separately about mesh under. Alex > > > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, April 22, 2009 > 11:13 AM To: Robert Assimiti Cc: 6lowpan@ietf.org Subject: Re: > [6loWPAN] 6loWPAN Design and Application Spaces for 6loWPANs - 02- > > Hi Robert, let me give my oppinion on this. > > Robert Assimiti a écrit : >> Hello, >> >> I was going over the second spin of Draft-IETF-6lowpan-usercases. >> >> I am a bit unclear on the definition of the LoWPAN link. A LoWPAN >> Link is coined as: >> >> /“//A low-power wireless link which is shared by a link-local scope >> in a LoWPAN. In a LoWPAN, a link can be a very instable set of >> nodes, for instance the set of nodes that can receive a packet/ >> /that is broadcast over the air in a route over LoWPAN, or the set >> of nodes currently reachable in an L2 mesh in a mesh under LoWPAN. >> Such a set may vary from one packet to the next / /as the nodes >> move or as the radio propagation conditions change.â€/ >> >> It is clear that we are targeting point-to-point and >> point-to-multipoint here, but there is nothing that indicates the >> directionality of the link. > > I am not sure what you mean being clear we're targetting ptp and > pt-to-mpt links... > > I am aware ROLL WG targets the point-to-multipoint types of traffic > (not the links). > > I think 802.15.4 link may be a point-to-point link, or a 'star' > topology, which one may interpret as being a point-to-multipoint > link. > > Whereas I understand very well running IP over a point-to-point link, > I don't see how would it run over a point-to-multipoint link, never > saw this before. > > As for the link-local scope mentioned in the paragraph above, I think > it comes from what a "link-local scope" is for link like an Ethernet > link. But, it is not clear at all what a link-local scope would be on > a 802.15.4 star topology made of a point-to-multipoint link: would a > packet sent by the center reach all edges? Or only one? Would a > packet from an edge to another have a dst address the center or the > edge? Two dst addresses? > > I prefer to think that a LoWPAN subnet is covered by an IP link-local > scope, has at least one single IPv6 subnet prefix; and that IP > packets addressed to a link-local IPv6 address reaches all nodes in > the LoWPAN, without being 'IP-forwarded'. > > If such LoWPAN subnet sit on a 802.15.4 link then that 802.15.4 link > should offer link-layer multicast support to the LoWPAN subnet, such > that the words "link-local scope" to have a meaning for a > 802.15.4-based LoWPAN. This is not the case today. > >> Is the definition here (since it is a wireless context) considered >> unidirectional or bi-directional? > > This is a good question. I do suppose 6LoWPAN WG uses links which > are bidirectional and symmetric. > > Alex > >> >> >> Also, the definition given in RFC4861 does not really apply here. >> >> >> >> Thanks for anyone that could offer a clarification. >> >> >> >> >> >> >> >> *"The nice thing about standards is that there are so many to >> choose from." - Andrew S. Tanenbaum * >> >> *Robert Assimiti* >> >> *Executive Staff Engineer* >> >> *Office: [678]-202-6859* >> >> *Mobile: [404]-578-0205* >> >> *robert.assimiti@nivis.com* >> >> >> >> >> >> >> >> >> >> >> This e-mail (including any attachments to it) is confidential, >> proprietary, legally privileged, subject to copyright and is sent >> for the personal attention of the intended recipient only. If you >> have received this e-mail in error, please reply to advise us >> immediately, delete it and destroy any printed copies of it. You >> are notified that reading, disclosing, copying, distributing or >> taking any action in reliance on the contents of this information >> is strictly prohibited. No employee is authorized to conclude any >> binding agreement on behalf of NIVIS LLC with another party by >> e-mail without express written confirmation by an officer of the >> company. Although we have taken reasonable precautions to ensure no >> viruses are present in this e-mail, we cannot accept responsibility >> for any loss or damage arising from the viruses in this e-mail or >> attachments. >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ 6lowpan mailing >> list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan >> > > > > > This e-mail (including any attachments to it) is confidential, > proprietary, legally privileged, subject to copyright and is sent for > the personal attention of the intended recipient only. If you have > received this e-mail in error, please reply to advise us immediately, > delete it and destroy any printed copies of it. You are notified that > reading, disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited. > No employee is authorized to conclude any binding agreement on behalf > of NIVIS LLC with another party by e-mail without express written > confirmation by an officer of the company. Although we have taken > reasonable precautions to ensure no viruses are present in this > e-mail, we cannot accept responsibility for any loss or damage > arising from the viruses in this e-mail or attachments. From jabeille@cisco.com Thu Apr 23 07:28:00 2009 Return-Path: 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 2402E3A6AED for <6lowpan@core3.amsl.com>; Thu, 23 Apr 2009 07:28:00 -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=[AWL=0.001, 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 EiiE6r+iTE7U for <6lowpan@core3.amsl.com>; Thu, 23 Apr 2009 07:27:58 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7BC163A7214 for <6lowpan@ietf.org>; Thu, 23 Apr 2009 07:27:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,235,1238976000"; d="scan'208";a="156111371" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-3.cisco.com with ESMTP; 23 Apr 2009 14:29:12 +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 n3NETCHA006265; Thu, 23 Apr 2009 16:29:12 +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 n3NETBLK004559; Thu, 23 Apr 2009 14:29:12 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); Thu, 23 Apr 2009 16:29:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Apr 2009 16:29:07 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A8602F90B89@xmb-ams-33d.emea.cisco.com> In-Reply-To: <49F072A8.1050706@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [6loWPAN] 6loWPAN Design and Application Spaces for 6loWPANs - 02- Thread-Index: AcnEGslwTqck1KMlSu6fxcJ+zFWxkgABJ7rA References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com><49DFB1DB.3040602@gmail.com><49E04284.6000900@sensinode.com><49E0880E.1030803@gmail.com><49E08B3D.6030003@sensinode.com><200904111748.n3BHm8Sw002704@kelsey-ws.hq.ember.com><38532F0136A84A188E6A9ACCF03FF06D@RunningDog2> <7892795E1A87F04CADFCCF41FADD00FC0748F82F@xmb-ams-337.emea.cisco.com><49EF33E7.50008@gmail.com> <49F072A8.1050706@gmail.com> From: "Julien Abeille (jabeille)" To: "Alexandru Petrescu" , "Robert Assimiti" X-OriginalArrivalTime: 23 Apr 2009 14:29:11.0994 (UTC) FILETIME=[DEEE01A0:01C9C41F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9099; t=1240496952; x=1241360952; 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]=20[6loWPAN]=206loWPAN=20Desig n=20and=20Application=20Spaces=20for=206loWPANs=20-=2002- |Sender:=20; bh=n5qp6bvFjO3iOr/FyFc0X/HP6RE6kwViq+VHkuKG6jk=; b=XAn79L5AjkCAAx3/3OKnbKo6OHoWoT74gbaaHoaDx8TYg2OuPqPG2TtOa+ dws4xlpxRErKqeG5gRxs2mg505yxWQ1vFEt8SCJxoVWVugEljZicy9DYGwR8 P3iG+IavEy; 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] [6loWPAN] 6loWPAN Design and Application Spaces for 6loWPANs - 02- 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: , X-List-Received-Date: Thu, 23 Apr 2009 14:28:00 -0000 Hi all, To be sure I understand: is the lowpan link concept different from the = link definition in IPv6? link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM networks as well as Internet-layer (or higher-layer) "tunnels", such as tunnels over IPv4 or IPv6 itself. Best, Julien -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Alexandru Petrescu Sent: jeudi 23 avril 2009 15:53 To: Robert Assimiti Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [6loWPAN] 6loWPAN Design and Application Spaces = for 6loWPANs - 02- Robert Assimiti a =E9crit : > Hello Alex. I think this definition needs to be revised in order to=20 > accommodate not only the context of a 802.15.4 PAN but also the=20 > context of wireless subnets in general. I agree. The definition in question is the following: > LoWPAN Link >=20 > A low-power wireless link which is shared by a link-local scope = in > a LoWPAN. In a LoWPAN, a link can be a very instable set of > nodes, for instance the set of nodes that can receive a packet > that is broadcast over the air in a route over LoWPAN, or the = set > of nodes currently reachable in an L2 mesh in a mesh under = LoWPAN. > Such a set may vary from one packet to the next as the nodes = move > or as the radio propagation conditions change. At least the formulation "link shared by a link-local scope" is = confusing. Maybe a "link connecting nodes which are part of the same = link-local scope"(?) Then it says "broadcast over the air in a route over LoWPAN" which is = less understandable again... Then there are more definitions which are less understandable. The = Route Over is some of the less clear: > Mesh Under >=20 > A LoWPAN configuration where the link-local scope is defined by > the boundaries of the LoWPAN and includes all nodes within. > Forwarding and multihop routing functions are achieved at L2 > between mesh nodes. >=20 > Route Over >=20 > A LoWPAN configuration where the link-local scope is defined by > those nodes reachable over a single radio transmission. What is a single radio transmission? Is it that non-link-local scope = implies several radio transmissions? > Due to the time-varying characteristics of wireless communication, the = > neighbor set may change over time even when nodes maintain the same=20 > physical locations. Excuse-me but I really don't understand this: time-varying = characteristics of wireless communications - do you mean TDD? > Route Over [...] Multihop is achieved using IP routing. Multihop with IP routing means also that the router forwards between two = different links (each with its own link-local scope). However, the = "Route Over" definition above uses a single link-local scope. I'll write separately about mesh under. Alex >=20 >=20 >=20 > -----Original Message----- From: Alexandru Petrescu=20 > [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, April 22, 2009 > 11:13 AM To: Robert Assimiti Cc: 6lowpan@ietf.org Subject: Re: > [6loWPAN] 6loWPAN Design and Application Spaces for 6loWPANs - 02- >=20 > Hi Robert, let me give my oppinion on this. >=20 > Robert Assimiti a =E9crit : >> Hello, >>=20 >> I was going over the second spin of Draft-IETF-6lowpan-usercases. >>=20 >> I am a bit unclear on the definition of the LoWPAN link. A LoWPAN=20 >> Link is coined as: >>=20 >> /"//A low-power wireless link which is shared by a link-local scope=20 >> in a LoWPAN. In a LoWPAN, a link can be a very instable set of nodes, = >> for instance the set of nodes that can receive a packet/ /that is=20 >> broadcast over the air in a route over LoWPAN, or the set of nodes=20 >> currently reachable in an L2 mesh in a mesh under LoWPAN. >> Such a set may vary from one packet to the next / /as the nodes move=20 >> or as the radio propagation conditions change."/ >>=20 >> It is clear that we are targeting point-to-point and=20 >> point-to-multipoint here, but there is nothing that indicates the=20 >> directionality of the link. >=20 > I am not sure what you mean being clear we're targetting ptp and=20 > pt-to-mpt links... >=20 > I am aware ROLL WG targets the point-to-multipoint types of traffic=20 > (not the links). >=20 > I think 802.15.4 link may be a point-to-point link, or a 'star'=20 > topology, which one may interpret as being a point-to-multipoint link. >=20 > Whereas I understand very well running IP over a point-to-point link,=20 > I don't see how would it run over a point-to-multipoint link, never=20 > saw this before. >=20 > As for the link-local scope mentioned in the paragraph above, I think=20 > it comes from what a "link-local scope" is for link like an Ethernet=20 > link. But, it is not clear at all what a link-local scope would be on=20 > a 802.15.4 star topology made of a point-to-multipoint link: would a =20 > packet sent by the center reach all edges? Or only one? Would a=20 > packet from an edge to another have a dst address the center or the=20 > edge? Two dst addresses? >=20 > I prefer to think that a LoWPAN subnet is covered by an IP link-local = > scope, has at least one single IPv6 subnet prefix; and that IP packets = > addressed to a link-local IPv6 address reaches all nodes in the=20 > LoWPAN, without being 'IP-forwarded'. >=20 > If such LoWPAN subnet sit on a 802.15.4 link then that 802.15.4 link =20 > should offer link-layer multicast support to the LoWPAN subnet, such =20 > that the words "link-local scope" to have a meaning for a=20 > 802.15.4-based LoWPAN. This is not the case today. >=20 >> Is the definition here (since it is a wireless context) considered =20 >> unidirectional or bi-directional? >=20 > This is a good question. I do suppose 6LoWPAN WG uses links which=20 > are bidirectional and symmetric. >=20 > Alex >=20 >>=20 >>=20 >> Also, the definition given in RFC4861 does not really apply here. >>=20 >>=20 >>=20 >> Thanks for anyone that could offer a clarification. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> *"The nice thing about standards is that there are so many to choose=20 >> from." - Andrew S. Tanenbaum * >>=20 >> *Robert Assimiti* >>=20 >> *Executive Staff Engineer* >>=20 >> *Office: [678]-202-6859* >>=20 >> *Mobile: [404]-578-0205* >>=20 >> *robert.assimiti@nivis.com* >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> This e-mail (including any attachments to it) is confidential,=20 >> proprietary, legally privileged, subject to copyright and is sent for = >> the personal attention of the intended recipient only. If you have=20 >> received this e-mail in error, please reply to advise us immediately, = >> delete it and destroy any printed copies of it. You are notified that = >> reading, disclosing, copying, distributing or taking any action in=20 >> reliance on the contents of this information is strictly prohibited.=20 >> No employee is authorized to conclude any binding agreement on behalf = >> of NIVIS LLC with another party by e-mail without express written=20 >> confirmation by an officer of the company. Although we have taken=20 >> reasonable precautions to ensure no viruses are present in this=20 >> e-mail, we cannot accept responsibility for any loss or damage=20 >> arising from the viruses in this e-mail or attachments. >>=20 >>=20 >> --------------------------------------------------------------------- >> --- >>=20 >>=20 >> _______________________________________________ 6lowpan mailing list=20 >> 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan >>=20 >=20 >=20 >=20 >=20 > This e-mail (including any attachments to it) is confidential,=20 > proprietary, legally privileged, subject to copyright and is sent for=20 > the personal attention of the intended recipient only. If you have=20 > received this e-mail in error, please reply to advise us immediately,=20 > delete it and destroy any printed copies of it. You are notified that=20 > reading, disclosing, copying, distributing or taking any action in=20 > reliance on the contents of this information is strictly prohibited. > No employee is authorized to conclude any binding agreement on behalf=20 > of NIVIS LLC with another party by e-mail without express written=20 > confirmation by an officer of the company. Although we have taken=20 > reasonable precautions to ensure no viruses are present in this=20 > e-mail, we cannot accept responsibility for any loss or damage arising = > from the viruses in this e-mail or attachments. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From alexandru.petrescu@gmail.com Thu Apr 23 09:13:22 2009 Return-Path: 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 5E01628C6BC for <6lowpan@core3.amsl.com>; Thu, 23 Apr 2009 09:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti1Vco1hbjoc for <6lowpan@core3.amsl.com>; Thu, 23 Apr 2009 09:13:21 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 2B41D28C330 for <6lowpan@ietf.org>; Thu, 23 Apr 2009 09:13:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3NGEcGd027911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <6lowpan@ietf.org>; Thu, 23 Apr 2009 18:14:38 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3NGEbTs001927 for <6lowpan@ietf.org>; Thu, 23 Apr 2009 18:14:38 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3NGEbD7004856 for <6lowpan@ietf.org>; Thu, 23 Apr 2009 18:14:37 +0200 Message-ID: <49F093ED.2050806@gmail.com> Date: Thu, 23 Apr 2009 18:14:37 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] About definitions in draft-ietf-6lowpan-usecases-02 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: , X-List-Received-Date: Thu, 23 Apr 2009 16:13:22 -0000 As I said previously, I have difficulty understanding some terms in the usecases draft. For example, it defines LoWPAN Host, LoWPAN Router and LoWPAN Node. However it doesn't say a LoWPAN Node may be a LoWPAN Host or a LoWPAN Router. (I think, commonly in IPv6, Nodes may be Host or Routers). It defines Mesh Under and Route Over; however I can't understand the following: does a "Route-Over" LoWPAN contain the same IP link-local scope or not? If yes then this is very difficult to udnerstand, next to impossible. Also, another problem is that it defines the Route-Over and Mesh-Under in apple-to-orange terms ("boundaries" vs "radio range"), whereas Route-Over and Mesh-Under have often been easily compared, ie redapples-to-greenapples. Then on the use of 'single radio transmission' to define "Route Over" - what is single radio transmission more precisely? One is tempted to believe all nodes reachable by a single radio transmission from a certain node are all within the same IP link-local scope... which is ok. > Route Over > > A LoWPAN configuration where the link-local scope is defined by > those nodes reachable over a single radio transmission. [...] But because it doesn't say from _where_ are those nodes reachable (from another single certain node) then one can easily also think this: B is within a single radio transmission of both C and A, yet it is in two different link-local scopes, which is of course not the intention. ----------------------- |radiorange|radiorange| A B C Knowing the above, I'm trying to offer my own definitions of terms in the way I'd have written it. Of course it may not fit all the views, but I thought I'd share: PHY repeating The act performed by a device repeating a packet at PHY level. It doesn't inspect any field in any packet header. It has one or several interfaces, they are all in the same IP link-local scope. MAC forwarding The act performed by a bridge - inspecting the dst MAC address of incoming packet, exact-matching it to the first field in a table of tuples [dst,nexthop] MAC addresses and transmitting it to the identified nexthop. In the process, the src and dst MAC address of the packet are potentially modified. The device may have one or more interfaces but they are all in the same IP link-local scope. IP routing The act performed by a router - inspecting the dst IP address of an incoming packet, longest-prefix matching it to the first field of each entry in a table of triolets [dst,prefixlength,nexthop] IP addresses and transmitting it to the identified nexthop. In the process, neither the src nor the dst IP addresses of the packet are ever modified. It has two ore more interfaces, each interface of the router has a different IP link-local scope. IP link-local scope The set of IP nodes reachable by an IP packet whose dst address starts with 0xff02. All nodes on a link are within the same IP link-local scope, and nodes outside the link are outside the scope. Transmitting packets in the same link-local scope doesn't involve IP routing but may involve MAC forwarding. Radio range of node The radio range of a node is the set of nodes reachable from it, at PHY layer. For example, the radio range of a WiFi node is 50m in a clear-sight atmospheric area, without physical obstacles and in good weather. Obviously, all nodes in same radio range of a node could be understood to be in the same IP link-local scope. However, a single-interface node can't be part of several IP link-local scopes even if sits at the intersection of the radio ranges of several other nodes. "Mesh-Under" LoWPAN A LoWPAN configuration where the IP link-local scope is extended to more nodes (beyond the radio range of a node) by means of MAC forwarding exclusively. All nodes in a "Mesh-Under" LoWPAN are within the same IP link-local scope, despite the probable presence of several PHY radio ranges - this alleviates the non-transitivity aspect. "Route-Over" LoWPAN A LoWPAN configuration where the IP link-local scope is extended to more nodes (beyond the radio range of a node) by means of transmitting IP packets, using a novel IP routing method. This novel method runs on a LoWPAN Router (uses a single interface, instead of the typical 2-interface router) and both interfaces are in the same IP link-local scope (instead of the typical router having a different IP link-local scope for each interface). "Routed" LoWPAN A LoWPAN configuration where the IP link-local scope is not extended beyond the radio range. Certain nodes are manually designated as special. The radio range of each special node contains the set of nodes in the same IP link-local scope, and each such range forms a unique link. Connecting two such links is performed by means of a typical IP router (multiple interfaces, different link-local scope). Comments anyone? Alex From alexandru.petrescu@gmail.com Thu Apr 23 09:33:27 2009 Return-Path: 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 0544528C6F4 for <6lowpan@core3.amsl.com>; Thu, 23 Apr 2009 09:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGGul7YgqNiN for <6lowpan@core3.amsl.com>; Thu, 23 Apr 2009 09:33:26 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 1922228C702 for <6lowpan@ietf.org>; Thu, 23 Apr 2009 09:33:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3NGWUCa004018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Apr 2009 18:32:31 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3NGYXI5003881; Thu, 23 Apr 2009 18:34:33 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3NGYXQB008637; Thu, 23 Apr 2009 18:34:33 +0200 Message-ID: <49F09899.1050603@gmail.com> Date: Thu, 23 Apr 2009 18:34:33 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Julien Abeille (jabeille)" References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com><49DFB1DB.3040602@gmail.com><49E04284.6000900@sensinode.com><49E0880E.1030803@gmail.com><49E08B3D.6030003@sensinode.com><200904111748.n3BHm8Sw002704@kelsey-ws.hq.ember.com><38532F0136A84A188E6A9ACCF03FF06D@RunningDog2> <7892795E1A87F04CADFCCF41FADD00FC0748F82F@xmb-ams-337.emea.cisco.com><49EF33E7.50008@gmail.com> <49F072A8.1050706@gmail.com> <38F26F36EAA981478A49D1F37F474A8602F90B89@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A8602F90B89@xmb-ams-33d.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6loWPAN Design and Application Spaces for 6loWPANs - 02- 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: , X-List-Received-Date: Thu, 23 Apr 2009 16:33:27 -0000 Julien Abeille (jabeille) a écrit : > Hi all, > > To be sure I understand: is the lowpan link concept different from the link definition in IPv6? > link - a communication facility or medium over which nodes can > communicate at the link layer, i.e., the layer > immediately below IP. Examples are Ethernets (simple > or bridged), PPP links, X.25, Frame Relay, or ATM > networks as well as Internet-layer (or higher-layer) > "tunnels", such as tunnels over IPv4 or IPv6 itself. Excellent point! I think no, the LoWPAN link shouldn't be any different from the IPv6 link definition listed above. Which RFC is that btw? However, the wireless quirk is this famous non-transitivity wireless problem (or 'hidden' terminal problem) which says that a set of nodes which can communicate at link-layer pairwise can't necessarily communicate at link-layer from any node to any node - i.e. there can be three nodes forming two different "linked" links. This effectively makes the above IPv6 link definition irrelevant to any wireless link. Were the above IPv6 link definition to say "a medium over which each node can communicate at the link layer to each other node", or similar, then the wireless quirk wouldn't apply and we'd be happily be using that IPv6 link definition, I think. Alex From alexandru.petrescu@gmail.com Thu Apr 23 12:23:09 2009 Return-Path: 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 5E2A13A7308 for <6lowpan@core3.amsl.com>; Thu, 23 Apr 2009 12:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBDmLvjS7Iao for <6lowpan@core3.amsl.com>; Thu, 23 Apr 2009 12:23:08 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 6A0A93A6F75 for <6lowpan@ietf.org>; Thu, 23 Apr 2009 12:23:00 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 23E534B0177 for <6lowpan@ietf.org>; Thu, 23 Apr 2009 21:24:15 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP id 2F6CF4B010B for <6lowpan@ietf.org>; Thu, 23 Apr 2009 21:24:13 +0200 (CEST) Message-ID: <49F0C05B.3020405@gmail.com> Date: Thu, 23 Apr 2009 21:24:11 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] link definition of rfc4861 to cover wireless non-transitive links as well 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: , X-List-Received-Date: Thu, 23 Apr 2009 19:23:09 -0000 Previous discussion indicated that link definition of RFC 4861 "Neighbor Discovery for IPv6" is pertinent to 6LoWPAN. I agree with it and suggest the following 6LoWPAN definition: link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP (each node can communicate to each other in this medium). Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, wireless links or ATM networks as well as Internet-layer (or higher-layer) "tunnels", such as tunnels over IPv4 or IPv6 itself. This is a slightly modified definition of the link defined in RFC4861, in order to cover also the wireless links. Wireless links may be non-transitive (node A communicates at link layer to both B and C yet B and C are not on the same link). Hidden terminal problem in wireless communications is described in [reference to individual draft in AUTOCONF] draft-baccelli-multi-hop-wireless-communication-02 What do people think about using this link definition in 6LoWPAN? Alex From jabeille@cisco.com Fri Apr 24 00:29:46 2009 Return-Path: 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 715E83A7392 for <6lowpan@core3.amsl.com>; Fri, 24 Apr 2009 00:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6qMIYhSzjpX for <6lowpan@core3.amsl.com>; Fri, 24 Apr 2009 00:29:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id ED0A63A68F5 for <6lowpan@ietf.org>; Fri, 24 Apr 2009 00:29:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,240,1238976000"; d="scan'208";a="39048791" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Apr 2009 07:30:57 +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 n3O7Uve8029540; Fri, 24 Apr 2009 09:30:57 +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 n3O7UvkE005048; Fri, 24 Apr 2009 07:30:57 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); Fri, 24 Apr 2009 09:30:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 09:30:53 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A8602F90DEC@xmb-ams-33d.emea.cisco.com> In-Reply-To: <49F0C05B.3020405@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] link definition of rfc4861 to cover wireless non-transitive links as well Thread-Index: AcnESSOqlYau+HK8RQuzQdX1/NxUgAAZLy4Q References: <49F0C05B.3020405@gmail.com> From: "Julien Abeille (jabeille)" To: "Alexandru Petrescu" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 24 Apr 2009 07:30:57.0632 (UTC) FILETIME=[9BEFFE00:01C9C4AE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2171; t=1240558257; x=1241422257; 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=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[6lowpan]=20link=20definition=20of=20rf c4861=20to=20cover=20wireless=20non-transitive=20links=20as= 20well |Sender:=20; bh=gPBrxW2B76bsNZnB62cOIRZ7YeZRqwlE6RG2Egr6/Eo=; b=sk6O3y5+6BxTyTFHSoJPZyKK/5SAk0x/l5SchLP5WFsIFyVByqx+DCISzZ aCagL4E4zdxoWP2kzqWDEpTgB0C4sVzeDwrRUBtC9OwE4IiHcvhc7aWAJdys xJAvT+M3kU; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [6lowpan] link definition of rfc4861 to cover wireless non-transitive links as well 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: , X-List-Received-Date: Fri, 24 Apr 2009 07:29:46 -0000 Hi Alex, To answer a previous question (which RFC does the definition come from), I think as you say the original one was from Neighbor discovery. The definition is also present in a number of others RFCs: RFC2460 IPv6 RFC4862 Autoconf RFC3315 DHCPv6=20 RFC4429 Optimistic DAD RFC4436 Detecting Network Attachment v4 RFC5121 IPv6 over Wimax ... Best, Julien -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: jeudi 23 avril 2009 21:24 To: 6lowpan Subject: [6lowpan] link definition of rfc4861 to cover wireless non-transitive links as well Previous discussion indicated that link definition of RFC 4861 "Neighbor Discovery for IPv6" is pertinent to 6LoWPAN. I agree with it and suggest the following 6LoWPAN definition: link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP (each node can communicate to each other in this medium). Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, wireless links or ATM networks as well as Internet-layer (or higher-layer) "tunnels", such as tunnels over IPv4 or IPv6 itself. This is a slightly modified definition of the link defined in RFC4861, in order to cover also the wireless links. Wireless links may be non-transitive (node A communicates at link layer to both B and C yet B and C are not on the same link). Hidden terminal problem in wireless communications is described in [reference to individual draft in AUTOCONF] draft-baccelli-multi-hop-wireless-communication-02 What do people think about using this link definition in 6LoWPAN? Alex _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From zach@sensinode.com Sat Apr 25 06:47:15 2009 Return-Path: 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 9B3CA3A6BCB for <6lowpan@core3.amsl.com>; Sat, 25 Apr 2009 06:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZeJbOTK9y0I for <6lowpan@core3.amsl.com>; Sat, 25 Apr 2009 06:47:14 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 72EFB3A6BC4 for <6lowpan@ietf.org>; Sat, 25 Apr 2009 06:47:13 -0700 (PDT) Received: from snl-zach.local ([194.197.255.10]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n3PDmHCI008797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Apr 2009 16:48:27 +0300 Message-ID: <49F30987.2080504@sensinode.com> Date: Sat, 25 Apr 2009 16:00:55 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <49F0C05B.3020405@gmail.com> In-Reply-To: <49F0C05B.3020405@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] link definition of rfc4861 to cover wireless non-transitive links as well 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: , X-List-Received-Date: Sat, 25 Apr 2009 13:47:15 -0000 Hi, I like this, taking the RFC4861 definition and just adding the wireless considerations. We should also mention as part of the wireless links part the following: - Wireless links considered by 6LoWPAN may not support native multicast. - Wireless links are not static, frequent changes are to be expected because of radio channel fading or node mobility. This link definition originates from the ND draft, and was just copied into the other drafts for consistency. I will make a ticket to update the link definition in nd-03. This was a good solution, thanks. - Zach Alexandru Petrescu wrote: > Previous discussion indicated that link definition of RFC 4861 "Neighbor > Discovery for IPv6" is pertinent to 6LoWPAN. I agree with it and > suggest the following 6LoWPAN definition: > > link - a communication facility or medium over which > nodes can communicate at the link layer, i.e., > the layer immediately below IP (each node can > communicate to each other in this medium). > > Examples are Ethernets (simple or bridged), PPP > links, X.25, Frame Relay, wireless links or ATM > networks as well as Internet-layer (or > higher-layer) "tunnels", such as tunnels over > IPv4 or IPv6 itself. > > This is a slightly modified definition of the link > defined in RFC4861, in order to cover also the wireless > links. Wireless links may be non-transitive (node A > communicates at link layer to both B and C yet B and C > are not on the same link). Hidden terminal problem in > wireless communications is described in [reference to > individual draft in AUTOCONF] > draft-baccelli-multi-hop-wireless-communication-02 > > What do people think about using this link definition in 6LoWPAN? > > Alex > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From alexandru.petrescu@gmail.com Sun Apr 26 12:20:17 2009 Return-Path: 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 E79C03A6D64 for <6lowpan@core3.amsl.com>; Sun, 26 Apr 2009 12:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvfqOvCmusHj for <6lowpan@core3.amsl.com>; Sun, 26 Apr 2009 12:20:17 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id BFF293A6837 for <6lowpan@ietf.org>; Sun, 26 Apr 2009 12:20:15 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 01AD84B00FA; Sun, 26 Apr 2009 21:21:31 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP id B6CD44B01AE; Sun, 26 Apr 2009 21:21:28 +0200 (CEST) Message-ID: <49F4B43C.2030807@gmail.com> Date: Sun, 26 Apr 2009 21:21:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <49F0C05B.3020405@gmail.com> <49F30987.2080504@sensinode.com> In-Reply-To: <49F30987.2080504@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] link definition of rfc4861 to cover wireless non-transitive links as well 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: , X-List-Received-Date: Sun, 26 Apr 2009 19:20:18 -0000 Zach Shelby a écrit : > Hi, > > I like this, taking the RFC4861 definition and just adding the wireless > considerations. We should also mention as part of the wireless links > part the following: > > - Wireless links considered by 6LoWPAN may not support native multicast. > - Wireless links are not static, frequent changes are to be expected > because of radio channel fading or node mobility. Hi Zach, But the definition from rfc4861 doesn't mean to ignore the non-static/frequent-change characteristic of the wireless links; because it says nodes communicate "at link layer". Link layers do cover the non-static/frequent changes/fading channels. Also the link definition from rfc4861 doesn't assume that link-layer offers or doesn't offer multicast. (link layers of wireless links do acknowledge however that A-B-C nodes may form two links instead of one). Alex > > This link definition originates from the ND draft, and was just copied > into the other drafts for consistency. I will make a ticket to update > the link definition in nd-03. This was a good solution, thanks. > > - Zach > > Alexandru Petrescu wrote: >> Previous discussion indicated that link definition of RFC 4861 "Neighbor >> Discovery for IPv6" is pertinent to 6LoWPAN. I agree with it and >> suggest the following 6LoWPAN definition: >> >> link - a communication facility or medium over which >> nodes can communicate at the link layer, i.e., >> the layer immediately below IP (each node can >> communicate to each other in this medium). >> >> Examples are Ethernets (simple or bridged), PPP >> links, X.25, Frame Relay, wireless links or ATM >> networks as well as Internet-layer (or >> higher-layer) "tunnels", such as tunnels over >> IPv4 or IPv6 itself. >> >> This is a slightly modified definition of the link >> defined in RFC4861, in order to cover also the wireless >> links. Wireless links may be non-transitive (node A >> communicates at link layer to both B and C yet B and C >> are not on the same link). Hidden terminal problem in >> wireless communications is described in [reference to >> individual draft in AUTOCONF] >> draft-baccelli-multi-hop-wireless-communication-02 >> >> What do people think about using this link definition in 6LoWPAN? >> >> Alex >> >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > From dokaspar.ietf@gmail.com Wed Apr 29 06:58:48 2009 Return-Path: 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 E63F03A67F3 for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 06:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 CGlwxR8z2pOh for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 06:58:47 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by core3.amsl.com (Postfix) with ESMTP id 0F2EE3A6C76 for <6lowpan@ietf.org>; Wed, 29 Apr 2009 06:58:46 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w1so532046mue.9 for <6lowpan@ietf.org>; Wed, 29 Apr 2009 07:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=b6slISLABkb9phrCXWdQAewxLT5oT+9dJ6C+RCb7a44=; b=JtFDeAFMWnL8J0IyabslMjPqOjR2/FsWwm892fnwWhursjg+5l/uchju4mVSf/PKwP CfzWfzYpySQZuOB5KkOl51jat3cXwH3c0cWGrkAdwkAtKWnLFbg02eucQJQlvEs+qIIN d/7zKzhj3gBBFvb6wX4F0/micj94Ax5Fc3D08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ta3bBKx/6XxbLzuwEHQjZhMmJRNEFltDBXo45iPHhmMzIRhSOgjFi09/pnsm9jGZkD 89Sy3UcaJWe199ZKYRRMktNZz9XoA60Cvx0H4Mz/j53QmRAD5WB20NVaIu5dFGJ1luOR 15eD5Wp6Kr75OCNWN9LWllNgcpYVHFMnL9fUY= MIME-Version: 1.0 Received: by 10.103.246.1 with SMTP id y1mr231220mur.120.1241013608440; Wed, 29 Apr 2009 07:00:08 -0700 (PDT) In-Reply-To: <49F093ED.2050806@gmail.com> References: <49F093ED.2050806@gmail.com> Date: Wed, 29 Apr 2009 16:00:08 +0200 Message-ID: <2a3692de0904290700o6236c1e8q23f08b97b1116e6c@mail.gmail.com> From: Dominik Kaspar To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] About definitions in draft-ietf-6lowpan-usecases-02 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: , X-List-Received-Date: Wed, 29 Apr 2009 13:58:49 -0000 Hi Alex, Thanks for sharing your definitions on LoWPAN terminology. I agree with you that the current definition of "LoWPAN Mesh Node" is incomplete. We must point out that it is a general term which includes both a LoWPAN Host or a LoWPAN Router. The link definition of RFC4861 is indeed useful. For the Use Cases draft, we will follow the changes in the ND draft on what a "LoWPAN Link" is. It might be nit-picky, but didn't you mean "IP forwarding" when you defined "IP routing"? And I disagree with your statement that "it has two or more interfaces, each interface of the router has a different IP link-local scope." I think that LoWPAN nodes mostly likely won't have more than a single physical network interface... Greetings, Dominik On Thu, Apr 23, 2009 at 6:14 PM, Alexandru Petrescu wrote: > As I said previously, I have difficulty understanding some terms in the > usecases draft. > > For example, it defines LoWPAN Host, LoWPAN Router and LoWPAN Node. Howev= er > it doesn't say a LoWPAN Node may be a LoWPAN Host or a LoWPAN Router. (I > think, commonly in IPv6, Nodes may be Host or Routers). > > It defines Mesh Under and Route Over; however I can't understand the > following: does a "Route-Over" LoWPAN contain the same IP link-local scop= e > or not? =A0If yes then this is very difficult to udnerstand, next to > impossible. > > Also, another problem is that it defines the Route-Over and Mesh-Under in > apple-to-orange terms ("boundaries" vs "radio range"), whereas Route-Over > and Mesh-Under have often been easily compared, ie redapples-to-greenappl= es. > > Then on the use of 'single radio transmission' to define "Route Over" - w= hat > is single radio transmission more precisely? =A0One is tempted to believe= all > nodes reachable by a single radio transmission from a certain node are al= l > within the same IP link-local scope... which is ok. > >> =A0 Route Over >> >> =A0 =A0 =A0A LoWPAN configuration where the link-local scope is defined = by >> =A0 =A0 =A0those nodes reachable over a single radio transmission. [...] > > But because it doesn't say from _where_ are those nodes reachable (from > another single certain node) then one can easily also think this: =A0B is > within a single radio transmission of both C and A, yet it is in two > different link-local scopes, which is of course not the intention. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ----------------------- > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |radiorange|radiorange| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A =A0 =A0 =A0 =A0 =A0B =A0 =A0 =A0 = =A0 =A0C > > Knowing the above, I'm trying to offer my own definitions of terms in the > way I'd have written it. =A0Of course it may not fit all the views, but I > thought I'd share: > > PHY repeating > > =A0The act performed by a device repeating a packet at PHY level. =A0It > =A0doesn't inspect any field in any packet header. =A0It has one or sever= al > =A0interfaces, they are all in the same IP link-local scope. > > MAC forwarding > > =A0The act performed by a bridge - inspecting the dst MAC address of > =A0incoming packet, exact-matching it to the first field in a table of > =A0tuples [dst,nexthop] > =A0MAC addresses and transmitting it to the identified nexthop. =A0In the > =A0process, the src and dst MAC address of the packet are potentially > =A0modified. =A0The device may have one or more interfaces but they are a= ll > =A0in the same IP link-local scope. > > IP routing > > =A0The act performed by a router - inspecting the dst > =A0IP address of an incoming packet, > =A0longest-prefix matching it to the first field of each entry > =A0in a table of triolets > =A0[dst,prefixlength,nexthop] IP addresses and transmitting it to the > =A0identified nexthop. =A0In the process, neither the src nor the dst IP > =A0addresses of the packet are ever modified. =A0It has two ore more > =A0interfaces, each interface of the router has a different IP link-local > =A0scope. > > IP link-local scope > > =A0The set of IP nodes reachable by an IP packet whose dst address starts > =A0with 0xff02. =A0All nodes on a link are within the same IP link-local > =A0scope, and nodes outside the link are outside the scope. =A0Transmitti= ng > =A0packets in the same link-local scope doesn't involve IP routing but > =A0may involve MAC forwarding. > > Radio range of node > > =A0The radio range of a node is the set of nodes reachable from it, at > =A0PHY layer. =A0For example, the radio range of a WiFi node is 50m in a > =A0clear-sight atmospheric area, without physical obstacles and in good > =A0weather. > > =A0Obviously, all nodes in same radio range of a node could be understood > =A0to be in the same IP link-local scope. > > =A0However, a single-interface node can't be part of several IP > =A0link-local scopes even if sits at the intersection of the radio ranges > =A0of several other nodes. > > "Mesh-Under" LoWPAN > > =A0A LoWPAN configuration where the IP link-local scope is extended to > =A0more nodes (beyond the radio range of a node) by means of MAC > =A0forwarding exclusively. =A0All nodes in a "Mesh-Under" LoWPAN are with= in > =A0the same IP link-local scope, despite the probable presence of several > =A0PHY radio ranges - this alleviates the non-transitivity aspect. > > "Route-Over" LoWPAN > > =A0A LoWPAN configuration where the IP link-local scope is extended to > =A0more nodes (beyond the radio range of a node) by means of transmitting > =A0IP packets, using a novel IP routing method. =A0This novel method > =A0runs on a LoWPAN Router (uses a single interface, instead of the > =A0typical 2-interface router) and both interfaces are in the same IP > =A0link-local scope (instead of the typical router having a different IP > =A0link-local scope for each interface). > > "Routed" LoWPAN > > =A0A LoWPAN configuration where the IP link-local scope is not extended > =A0beyond the radio range. =A0Certain nodes are manually designated as > =A0special. =A0The radio range of each special node contains the set of > =A0nodes in the same IP link-local scope, and each such range forms a > =A0unique link. =A0Connecting two such links is performed by means of a > =A0typical IP router (multiple interfaces, different link-local scope). > > Comments anyone? > > Alex > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From alexandru.petrescu@gmail.com Wed Apr 29 07:08:50 2009 Return-Path: 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 435353A6E6A for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 07:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7f5pMf+U52sW for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 07:08:49 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 43EC928C1CA for <6lowpan@ietf.org>; Wed, 29 Apr 2009 07:08:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3TEA9NR031190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Apr 2009 16:10:10 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3TEA9rO031168; Wed, 29 Apr 2009 16:10:09 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3TEA9ec021903; Wed, 29 Apr 2009 16:10:09 +0200 Message-ID: <49F85FC1.7050307@gmail.com> Date: Wed, 29 Apr 2009 16:10:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dominik Kaspar References: <49F093ED.2050806@gmail.com> <2a3692de0904290700o6236c1e8q23f08b97b1116e6c@mail.gmail.com> In-Reply-To: <2a3692de0904290700o6236c1e8q23f08b97b1116e6c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] About definitions in draft-ietf-6lowpan-usecases-02 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: , X-List-Received-Date: Wed, 29 Apr 2009 14:08:50 -0000 Dominik Kaspar a écrit : > Hi Alex, > > Thanks for sharing your definitions on LoWPAN terminology. I agree > with you that the current definition of "LoWPAN Mesh Node" is > incomplete. We must point out that it is a general term which includes > both a LoWPAN Host or a LoWPAN Router. Ok. > The link definition of RFC4861 is indeed useful. For the Use Cases > draft, we will follow the changes in the ND draft on what a "LoWPAN > Link" is. Which is? > It might be nit-picky, but didn't you mean "IP forwarding" when you > defined "IP routing"? I was thinking of it being both forwarding and routing. ("IP routing The act performed by a router - inspecting the dst IP address of an incoming packet, longest-prefix matching it to the first field of each entry in a table of triolets [dst,prefixlength,nexthop] IP addresses and transmitting it to the identified nexthop. In the process, neither the src nor the dst IP addresses of the packet are ever modified. It has two ore more interfaces, each interface of the router has a different IP link-local scope.") I wrote IP "routing" more to distinguish it from the immediately previous "MAC forwarding" because I think some people said here that MAC forwarding is different than IP routing... but I don't think anybody said how is it different. > And I disagree with your statement that "it has > two or more interfaces, each interface of the router has a different > IP link-local scope." I think that LoWPAN nodes mostly likely won't > have more than a single physical network interface... I agree that LoWPAN nodes seem likely to have a single interface. But this is new and different! A typical router doing IP routing, has more than one interface. Alex From jabeille@cisco.com Wed Apr 29 07:21:41 2009 Return-Path: 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 1C4A93A70A2 for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 07:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.265 X-Spam-Level: X-Spam-Status: No, score=-9.265 tagged_above=-999 required=5 tests=[AWL=1.334, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOU99IekmmEB for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 07:21:40 -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 D437128C28D for <6lowpan@ietf.org>; Wed, 29 Apr 2009 07:20:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,266,1238976000"; d="scan'208";a="39427149" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2009 14:22:12 +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 n3TEMC0o003043; Wed, 29 Apr 2009 16:22:12 +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 n3TEMCwC017729; Wed, 29 Apr 2009 14:22:12 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); Wed, 29 Apr 2009 16:22:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 16:22:10 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A860302C722@xmb-ams-33d.emea.cisco.com> In-Reply-To: <49F85FC1.7050307@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] About definitions in draft-ietf-6lowpan-usecases-02 Thread-Index: AcnI1EeX+aL5PFjiSfyodmoAqZLX9QAAFVqw References: <49F093ED.2050806@gmail.com><2a3692de0904290700o6236c1e8q23f08b97b1116e6c@mail.gmail.com> <49F85FC1.7050307@gmail.com> From: "Julien Abeille (jabeille)" To: "Alexandru Petrescu" , "Dominik Kaspar" X-OriginalArrivalTime: 29 Apr 2009 14:22:12.0543 (UTC) FILETIME=[E3655CF0:01C9C8D5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2829; t=1241014932; x=1241878932; 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=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[6lowpan]=20About=20definitions=20in=20 draft-ietf-6lowpan-usecases-02 |Sender:=20; bh=tDl20KtDcHUqRnLIp1ei1R0B20UDJhdf1uf627JmV/4=; b=g15VWNzdO/Z9mCv97vDnAP232cMs6KBdt9aTQEqAYzs+s/bI8BcUkOZIVp k1t3kj+vJkBP2hF0CNTmzBmEDWZC6jb3n8O16rvrPOUA3rEFGC9p94aTitqN QTsP+Ykce9; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] About definitions in draft-ietf-6lowpan-usecases-02 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: , X-List-Received-Date: Wed, 29 Apr 2009 14:21:41 -0000 Hi Alex, Regarding routers with one interface, it is true that regarding usual = practice and deployments, it is new. However conceptually, a router is = usually defined as "a node that forwards IP packets not explicitly = addressed to itself". To the best of my knowledge, this is what RFCs = assume when they use the router concept. Hence we should not run into = problems nor need to modify standards to support the one interface = scenario. Do you see scenarios / implementations where having one = interface will break something? Best, Julien -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Alexandru Petrescu Sent: mercredi 29 avril 2009 16:10 To: Dominik Kaspar Cc: 6lowpan Subject: Re: [6lowpan] About definitions in = draft-ietf-6lowpan-usecases-02 Dominik Kaspar a =E9crit : > Hi Alex, >=20 > Thanks for sharing your definitions on LoWPAN terminology. I agree=20 > with you that the current definition of "LoWPAN Mesh Node" is=20 > incomplete. We must point out that it is a general term which includes = > both a LoWPAN Host or a LoWPAN Router. Ok. > The link definition of RFC4861 is indeed useful. For the Use Cases=20 > draft, we will follow the changes in the ND draft on what a "LoWPAN=20 > Link" is. Which is? > It might be nit-picky, but didn't you mean "IP forwarding" when you=20 > defined "IP routing"? I was thinking of it being both forwarding and routing. ("IP routing The act performed by a router - inspecting the dst IP address of an incoming packet, longest-prefix matching it to the first field of each entry in a table of triolets [dst,prefixlength,nexthop] IP addresses and transmitting it to the identified nexthop. In the process, neither the src nor the dst IP addresses of the packet are ever modified. It has two ore more interfaces, each interface of the router has a different IP = link-local scope.") I wrote IP "routing" more to distinguish it from the immediately = previous "MAC forwarding" because I think some people said here that MAC = forwarding is different than IP routing... but I don't think anybody = said how is it different. > And I disagree with your statement that "it has two or more=20 > interfaces, each interface of the router has a different IP link-local = > scope." I think that LoWPAN nodes mostly likely won't have more than a = > single physical network interface... I agree that LoWPAN nodes seem likely to have a single interface. But = this is new and different! A typical router doing IP routing, has more than one interface. Alex _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From alexandru.petrescu@gmail.com Wed Apr 29 09:25:12 2009 Return-Path: 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 B0CFB3A6C5E for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 09:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RUe2TF-ABLF for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 09:25:11 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 6681E3A6AE9 for <6lowpan@ietf.org>; Wed, 29 Apr 2009 09:25:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3TGOMQG020557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Apr 2009 18:24:22 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3TGQRAi029744; Wed, 29 Apr 2009 18:26:27 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3TGQRTA029432; Wed, 29 Apr 2009 18:26:27 +0200 Message-ID: <49F87FB3.8030604@gmail.com> Date: Wed, 29 Apr 2009 18:26:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Julien Abeille (jabeille)" References: <49F093ED.2050806@gmail.com><2a3692de0904290700o6236c1e8q23f08b97b1116e6c@mail.gmail.com> <49F85FC1.7050307@gmail.com> <38F26F36EAA981478A49D1F37F474A860302C722@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A860302C722@xmb-ams-33d.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] About definitions in draft-ietf-6lowpan-usecases-02 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: , X-List-Received-Date: Wed, 29 Apr 2009 16:25:12 -0000 Julien Abeille (jabeille) a écrit : > Hi Alex, > > Regarding routers with one interface, it is true that regarding usual > practice and deployments, it is new. I agree. > However conceptually, a router is usually defined as "a node that > forwards IP packets not explicitly addressed to itself". Silence on the assumed number of interfaces isn't a favoring argument for one-interface routers either. A router putting a packet back on the same interface it came from sounds bad routing problem in the first place... > To the best of my knowledge, this is what RFCs assume when they use > the router concept. But many RFCs specify behaviour with respect to a particular interface. > Hence we should not run into problems nor need to modify standards to > support the one interface scenario. Do you see scenarios / > implementations where having one interface will break something? I'm not sure what detail is needed to support the view that one-interface routers are particularly new beasts... IP-repeating packets on the same interface is noise in the air. It breaks the availability of free timeslots to neighboring nodes. Waste of memory; common routing tables (and ND-related structures too) have a field "interface"; if all entries had the same content in that field then why would the field be needed at all? I will try to make a separate topic (again) on this... Alex From alexandru.petrescu@gmail.com Wed Apr 29 09:42:14 2009 Return-Path: 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 3B3D13A680E for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 09:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfupILejmh0h for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 09:42:10 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 987003A70AB for <6lowpan@ietf.org>; Wed, 29 Apr 2009 09:42:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3TGhSTn009787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <6lowpan@ietf.org>; Wed, 29 Apr 2009 18:43:28 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3TGhSbE031851 for <6lowpan@ietf.org>; Wed, 29 Apr 2009 18:43:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3TGhRxA022285 for <6lowpan@ietf.org>; Wed, 29 Apr 2009 18:43:28 +0200 Message-ID: <49F883AF.7060007@gmail.com> Date: Wed, 29 Apr 2009 18:43:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] one-interface routers and links (again) 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: , X-List-Received-Date: Wed, 29 Apr 2009 16:42:14 -0000 one-interface routers and links (again) Let me first describe one-interface routers as I understand are proposed in 6LoWPAN: +------------------------+---------------+ | | | 2001:db8:1::1/128 2001:db8:1::2/128 2001:db8:1::3/128 _|eth0 _|eth0 _|eth0 |R1 | |R2 | |R3 | --- --- --- R1 sends an IP packet to R3 but this reaches only R2. R2 picks the packet, looks at the dst address, finds it's not for self, consults routing table, finds a host-based route and sends it to R3. This can work ok. Now let me picture the same thing, but with The Link: The Link +------------------------+---------------+ | | | 2001:db8:1::1/128 2001:db8:1::2/128 2001:db8:1::3/128 _|eth0 _|eth0 _|eth0 |R1 | |R2 | |R3 | --- --- --- If there is a such link which links together all nodes then R1 would communicate directly to R3, by definition, no need to IP route. Could you please clarify why do IP routing then? And picture the same with 2 links: link1 link2 +------------------------+---------------+ | | | 2001:db8:1::1/128 2001:db8:1::2/128 2001:db8:1::3/128 _|eth0 _|eth0 _|eth0 |R1 | |R2 | |R3 | --- --- --- But in this figure R2 would need to have two MAC addresses on the same interface, because it is in two different links. I'm not aware of such interfaces with two MAC addresses. Could you please clarify? Alex From zach@sensinode.com Wed Apr 29 12:49:59 2009 Return-Path: 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 A84533A6A4D for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 12:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgoDrjDEqAN0 for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 12:49:58 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 059C33A680A for <6lowpan@ietf.org>; Wed, 29 Apr 2009 12:49:57 -0700 (PDT) Received: from snl-zach.local (line-17932.dyn.kponet.fi [85.29.116.124]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n3TJpDkv029444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2009 22:51:14 +0300 Message-ID: <49F8AFB6.5080607@sensinode.com> Date: Wed, 29 Apr 2009 22:51:18 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <49F883AF.7060007@gmail.com> In-Reply-To: <49F883AF.7060007@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] one-interface routers and links (again) 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: , X-List-Received-Date: Wed, 29 Apr 2009 19:50:00 -0000 Alex, Alexandru Petrescu wrote: > one-interface routers and links (again) > > Let me first describe one-interface routers as I understand are proposed > in 6LoWPAN: > > +------------------------+---------------+ > | | | > 2001:db8:1::1/128 2001:db8:1::2/128 2001:db8:1::3/128 > _|eth0 _|eth0 _|eth0 > |R1 | |R2 | |R3 | > --- --- --- > > R1 sends an IP packet to R3 but this reaches only R2. R2 picks the > packet, looks at the dst address, finds it's not for self, consults > routing table, finds a host-based route and sends it to R3. This can > work ok. Exactly, you pictured this nicely. This is how LoWPAN Routing works. I'll get back to the definition of that in your other thread. > Now let me picture the same thing, but with The Link: > > The Link > +------------------------+---------------+ > | | | > 2001:db8:1::1/128 2001:db8:1::2/128 2001:db8:1::3/128 > _|eth0 _|eth0 _|eth0 > |R1 | |R2 | |R3 | > --- --- --- > > If there is a such link which links together all nodes then R1 would > communicate directly to R3, by definition, no need to IP route. Could > you please clarify why do IP routing then? Then obviously, you don't need to perform LoWPAN Routing. This kind of (transitive) link occurs when all nodes are in radio range of each-other, or if the link technology is forming some kind of mesh underneath IP. In the ND draft this is really all that "mesh-under" means. It means we don't need to do LoWPAN Routing, nor do we even need nodes playing a Router roll. > And picture the same with 2 links: > link1 link2 > +------------------------+---------------+ > | | | > 2001:db8:1::1/128 2001:db8:1::2/128 2001:db8:1::3/128 > _|eth0 _|eth0 _|eth0 > |R1 | |R2 | |R3 | > --- --- --- > > But in this figure R2 would need to have two MAC addresses on the same > interface, because it is in two different links. I'm not aware of such > interfaces with two MAC addresses. Could you please clarify? This doesn't exist if links are defined as you have. > Alex > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From alexandru.petrescu@gmail.com Wed Apr 29 14:11:10 2009 Return-Path: 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 1590428C296 for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 14:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36HdEeIbx4rq for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 14:11:09 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 2C5163A67CC for <6lowpan@ietf.org>; Wed, 29 Apr 2009 14:10:53 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 9705EE08137; Wed, 29 Apr 2009 23:12:12 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 8EE55E0813F; Wed, 29 Apr 2009 23:12:09 +0200 (CEST) Message-ID: <49F8C2A8.4030509@gmail.com> Date: Wed, 29 Apr 2009 23:12:08 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <49F883AF.7060007@gmail.com> <49F8AFB6.5080607@sensinode.com> In-Reply-To: <49F8AFB6.5080607@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] one-interface routers and links (again) 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: , X-List-Received-Date: Wed, 29 Apr 2009 21:11:10 -0000 Zach Shelby a écrit : > Alex, > > Alexandru Petrescu wrote: >> one-interface routers and links (again) >> >> Let me first describe one-interface routers as I understand are >> proposed in 6LoWPAN: >> >> +------------------------+---------------+ >> | | | >> 2001:db8:1::1/128 2001:db8:1::2/128 2001:db8:1::3/128 >> _|eth0 _|eth0 _|eth0 >> |R1 | |R2 | |R3 | >> --- --- --- >> >> R1 sends an IP packet to R3 but this reaches only R2. R2 picks the >> packet, looks at the dst address, finds it's not for self, consults >> routing table, finds a host-based route and sends it to R3. This can >> work ok. > > Exactly, you pictured this nicely. This is how LoWPAN Routing works. > I'll get back to the definition of that in your other thread. Ok... If we say the dashed line is The Link then we're in the ND case, any node can talk to any other node at link-layer, no IP routing throughout. But if it is not The Link, and it is not two times The Link - then what is it? What is the link definition needing a LoWPAN single-interface IP router? Alex From zach@sensinode.com Wed Apr 29 23:24:45 2009 Return-Path: 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 8FB243A6A41 for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 23:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1c+P0D-APAkT for <6lowpan@core3.amsl.com>; Wed, 29 Apr 2009 23:24:44 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3E2B43A6BBA for <6lowpan@ietf.org>; Wed, 29 Apr 2009 23:24:43 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n3U6Q2jw008101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2009 09:26:02 +0300 Message-ID: <49F9447F.1060903@sensinode.com> Date: Thu, 30 Apr 2009 09:26:07 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <49F883AF.7060007@gmail.com> <49F8AFB6.5080607@sensinode.com> <49F8C2A8.4030509@gmail.com> In-Reply-To: <49F8C2A8.4030509@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] one-interface routers and links (again) 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: , X-List-Received-Date: Thu, 30 Apr 2009 06:24:45 -0000 Hi, Alexandru Petrescu wrote: > Zach Shelby a écrit : >> Alex, >> >> Alexandru Petrescu wrote: >>> one-interface routers and links (again) >>> >>> Let me first describe one-interface routers as I understand are >>> proposed in 6LoWPAN: >>> >>> +------------------------+---------------+ >>> | | | >>> 2001:db8:1::1/128 2001:db8:1::2/128 2001:db8:1::3/128 >>> _|eth0 _|eth0 _|eth0 >>> |R1 | |R2 | |R3 | >>> --- --- --- >>> >>> R1 sends an IP packet to R3 but this reaches only R2. R2 picks the >>> packet, looks at the dst address, finds it's not for self, consults >>> routing table, finds a host-based route and sends it to R3. This can >>> work ok. >> >> Exactly, you pictured this nicely. This is how LoWPAN Routing works. >> I'll get back to the definition of that in your other thread. > > Ok... > > If we say the dashed line is The Link then we're in the ND case, any > node can talk to any other node at link-layer, no IP routing throughout. > > But if it is not The Link, and it is not two times The Link - then what > is it? > > What is the link definition needing a LoWPAN single-interface IP router? The definition used in the other thread for a LoWPAN link, which in a wireless network may be non-transient, I think covers this case. Because the link is non-transient R1 and R2 can communicate, R2 and R3 can communicate, but R1 and R3 can't. So for non-transient wireless links you need LoWPAN routing. Let's get back to this in the terminology thread. - Zach > Alex > > -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From pthubert@cisco.com Thu Apr 30 06:32:43 2009 Return-Path: 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 7722B3A6CEE for <6lowpan@core3.amsl.com>; Thu, 30 Apr 2009 06:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.983 X-Spam-Level: X-Spam-Status: No, score=-9.983 tagged_above=-999 required=5 tests=[AWL=0.616, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl0qcgTmWOR0 for <6lowpan@core3.amsl.com>; Thu, 30 Apr 2009 06:32:38 -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 24C4828C346 for <6lowpan@ietf.org>; Thu, 30 Apr 2009 06:32:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,273,1238976000"; d="scan'208";a="39528938" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Apr 2009 13:33:54 +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 n3UDXspI018996; Thu, 30 Apr 2009 15:33:54 +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 n3UDXqLs027314; Thu, 30 Apr 2009 13:33:54 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 15:33:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 15:33:48 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0762B746@xmb-ams-337.emea.cisco.com> In-Reply-To: <49F8AFB6.5080607@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] one-interface routers and links (again) Thread-Index: AcnJA+QafN89dgeqQeybsr7bNTZqhgAk2MnA References: <49F883AF.7060007@gmail.com> <49F8AFB6.5080607@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "Alexandru Petrescu" X-OriginalArrivalTime: 30 Apr 2009 13:33:53.0358 (UTC) FILETIME=[4DC296E0:01C9C998] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1257; t=1241098434; x=1241962434; 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]=20one-interface=20routers=20a nd=20links=20=20(again) |Sender:=20; bh=+BrFJGMZpMoF1r/jjDcg6mDQkeVH4Lqa6uGTTSiUBcw=; b=qX4rX1GHf+uTkI8E4jJQZFnA1zbYOU1CRxk+vVgJNNOnL6kiFmEldQpICy NSsYBKXKjl70oVRVWTcpdOjXSkUmD2igHJ2Zpt6b721W3v0SQK1BL4DoV9cL /fAjEreRMw; 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] one-interface routers and links (again) 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: , X-List-Received-Date: Thu, 30 Apr 2009 13:32:43 -0000 >> >> Let me first describe one-interface routers as I understand are proposed >> in 6LoWPAN: >> >> +------------------------+---------------+ >> | | | >> 2001:db8:1::1/128 2001:db8:1::2/128 2001:db8:1::3/128 >> _|eth0 _|eth0 _|eth0 >> |R1 | |R2 | |R3 | >> --- --- --- >> >> R1 sends an IP packet to R3 but this reaches only R2. R2 picks the >> packet, looks at the dst address, finds it's not for self, consults >> routing table, finds a host-based route and sends it to R3. This can >> work ok. > >Exactly, you pictured this nicely. This is how LoWPAN Routing works. >I'll get back to the definition of that in your other thread. Note that over the Ethernet backbone shown here, if R1 and R3 are edge routers then R1 will reach R3 directly. This will happen because R1 still has a connected route 2001:db8:1::/64 over the backbone, and it will use RFC 4861 to locate R3 there. The binding table will be consulted first but that will fail because R3 is not a 6LoWPAN node registered to R1. Very much like a Home Agent operation on a Home link if you wish. Pascal From alexandru.petrescu@gmail.com Thu Apr 30 17:16:38 2009 Return-Path: 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 1C7AC3A6FC3 for <6lowpan@core3.amsl.com>; Thu, 30 Apr 2009 17:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XM-LhOr0qZiP for <6lowpan@core3.amsl.com>; Thu, 30 Apr 2009 17:16:37 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id BB2AF3A6E3E for <6lowpan@ietf.org>; Thu, 30 Apr 2009 17:15:51 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 64E21E08002; Fri, 1 May 2009 02:17:09 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 1FCE2E08024; Fri, 1 May 2009 02:17:07 +0200 (CEST) Message-ID: <49FA3F81.6070701@gmail.com> Date: Fri, 01 May 2009 02:17:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <49F883AF.7060007@gmail.com> <49F8AFB6.5080607@sensinode.com> <7892795E1A87F04CADFCCF41FADD00FC0762B746@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0762B746@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] one-interface routers and links (again) 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: , X-List-Received-Date: Fri, 01 May 2009 00:16:38 -0000 Pascal Thubert (pthubert) a écrit : >>> Let me first describe one-interface routers as I understand are > proposed >>> in 6LoWPAN: >>> >>> +------------------------+---------------+ | >>> | | 2001:db8:1::1/128 2001:db8:1::2/128 >>> 2001:db8:1::3/128 _|eth0 _|eth0 _|eth0 >>> |R1 | |R2 | |R3 | --- >>> --- --- >>> >>> R1 sends an IP packet to R3 but this reaches only R2. R2 picks >>> the packet, looks at the dst address, finds it's not for self, >>> consults routing table, finds a host-based route and sends it to >>> R3. This can work ok. >> Exactly, you pictured this nicely. This is how LoWPAN Routing >> works. I'll get back to the definition of that in your other >> thread. > > Note that over the Ethernet backbone shown here, if R1 and R3 are > edge routers then R1 will reach R3 directly. The dashed lines are actually the wireless link(s) not the backbone wired link... > This will happen because R1 still has a connected route > 2001:db8:1::/64 over the backbone, and it will use RFC 4861 to locate > R3 there. The binding table will be consulted first but that will > fail because R3 is not a 6LoWPAN node registered to R1. Very much > like a Home Agent operation on a Home link if you wish. Seems as a distinguishing point which should be mentioned in the Edge Router discussion... if I udnerstand it correctly. Alex From alexandru.petrescu@gmail.com Thu Apr 30 17:29:55 2009 Return-Path: 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 0B81D3A6B42 for <6lowpan@core3.amsl.com>; Thu, 30 Apr 2009 17:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTpkZuAZD6Vt for <6lowpan@core3.amsl.com>; Thu, 30 Apr 2009 17:29:54 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 01C6D3A6A4E for <6lowpan@ietf.org>; Thu, 30 Apr 2009 17:29:52 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 89DAFE08024; Fri, 1 May 2009 02:31:11 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 4C6E8E08058; Fri, 1 May 2009 02:31:09 +0200 (CEST) Message-ID: <49FA42CD.2020204@gmail.com> Date: Fri, 01 May 2009 02:31:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <49F883AF.7060007@gmail.com> <49F8AFB6.5080607@sensinode.com> <49F8C2A8.4030509@gmail.com> <49F9447F.1060903@sensinode.com> In-Reply-To: <49F9447F.1060903@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] non-transitive links and one-interface routers 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: , X-List-Received-Date: Fri, 01 May 2009 00:29:55 -0000 Zach Shelby a écrit : > Hi, > > Alexandru Petrescu wrote: >> Zach Shelby a écrit : >>> Alex, >>> >>> Alexandru Petrescu wrote: >>>> one-interface routers and links (again) >>>> >>>> Let me first describe one-interface routers as I understand are >>>> proposed in 6LoWPAN: >>>> >>>> +------------------------+---------------+ | >>>> | | 2001:db8:1::1/128 2001:db8:1::2/128 >>>> 2001:db8:1::3/128 _|eth0 _|eth0 >>>> _|eth0 |R1 | |R2 | |R3 | --- >>>> --- --- >>>> >>>> R1 sends an IP packet to R3 but this reaches only R2. R2 picks >>>> the packet, looks at the dst address, finds it's not for self, >>>> consults routing table, finds a host-based route and sends it >>>> to R3. This can work ok. >>> >>> Exactly, you pictured this nicely. This is how LoWPAN Routing >>> works. I'll get back to the definition of that in your other >>> thread. >> >> Ok... >> >> If we say the dashed line is The Link then we're in the ND case, >> any node can talk to any other node at link-layer, no IP routing >> throughout. >> >> But if it is not The Link, and it is not two times The Link - then >> what is it? >> >> What is the link definition needing a LoWPAN single-interface IP >> router? > > The definition used in the other thread for a LoWPAN link, which in a > wireless network may be non-transient, I think covers this case. The definition in the thread, inheriting from rfc4861 and other rfcs, is _not_ a non-transitive link. That link is clearly defined as linking all nodes in the medium: all nodes communicate at link-layer, one-by-one, any node to any node: > link - a communication facility or medium over which > nodes can communicate at the link layer, i.e., > the layer immediately below IP (each node can > communicate to each other in this medium). > > Examples are Ethernets (simple or bridged), PPP > links, X.25, Frame Relay, wireless links or ATM > networks as well as Internet-layer (or > higher-layer) "tunnels", such as tunnels over > IPv4 or IPv6 itself. > > This is a slightly modified definition of the link > defined in RFC4861, in order to cover also the wireless > links. Wireless links may be non-transitive (node A > communicates at link layer to both B and C yet B and C > are not on the same link). Hidden terminal problem in > wireless communications is described in [reference to > individual draft in AUTOCONF] > draft-baccelli-multi-hop-wireless-communication-02 This says that a wireless link is also a link. The fact that "wireless link_s_ may be non-transitive" is alleviated by the fact that "link - ... each node can communicate to each other in this medium". Maybe we shouldn't use "Wireless links" above but "Wireless media" because "link" is the term being defined. > Because the link is non-transient R1 and R2 can communicate, R2 and > R3 can communicate, but R1 and R3 can't. A 'non-transitive' link is different from the Link definition we mentioned above, because nodes on that link can all communicate to each other at link-layer. That Link is not non-transitive, it is transitive. How would one define a 'non-transitive' link? As two serially connected Links? This implies the middle router has two interfaces - which we don't want. So, what is the definition of a 'non-transitive' Link? (I'm not sure how to explain this better, but we don't seem to agree). Alex